Le document traite de l'agilité et de la gestion du changement, en expliquant diverses méthodes agiles telles que Scrum et Lean. Il souligne l'importance de répondre aux besoins des clients rapidement tout en améliorant la qualité et la productivité des projets. Enfin, il aborde les défis de l'adoption des approches agiles dans les organisations et propose des stratégies pour surmonter les obstacles.

1. L’agilité
et
la
ges,on
du
changement
Mathieu
Boisvert
Pyxis
Technologies
Événement
Université
de
Sherbrooke
–
Campus
Longueuil
15
octobre
2013
Copyright
©
2012,
Pyxis
Technologies
inc.
Tous
droits
réservés

2. Qui
je
suis
et
pourquoi
ce
sujet?
• Expert
de
méthodes
agiles
à
Pyxis
depuis
2004
Différents
rôles:
Conseiller,
formateur,
auteur,
chargé
de
cours
• Une
ques,on
qui
revient
de
temps
à
autre
Est-­‐ce
que
tu
connais
des
exemples
Agiles
qui
ne
sont
pas
des
projets
de
développement
logiciel?

3. Sondage
à
main
levée
• Qui
est
familier
avec
la
ges,on
du
changement?
• Qui
connaît
peu
ou
pas
Agile?
Les
autres,
qu’est-­‐ce
que
vous
faites
ici?

4. Agenda
• 50
minutes
–
Introduc,on
au
manifeste
à
l’Agilité
• 50
minutes
–
Mener
un
projet
de
ges,on
du
changement
avec
les
méthodes
Agiles
• 50
minutes
–
La
ges,on
du
changement
lors
d’une
transi,on
vers
l’Agilité
10
minutes
de
pause
entre
les
sec,ons
pour
permeZre
les
déplacements
de
masse

5. INTRODUCTION
AUX
APPROCHES
AGILES

6. Symptômes
des
projets
de
développement
logiciel
Les
sta,s,ques
de
Garthner:
Des
solu,ons
peu
ou
pas
u,lisées;
Une
mauvaise
qualité
de
produit:
les
anomalies;
les
régressions;
le
temps
de
stabilisa,on;
Le
temps
trop
long
entre
une
idée
et
sa
mise
en
produc,on;
Le
dépassement
de
temps
et
de
budget.

7. Le
manifeste
Agile
Les
individus
et
leurs
interac,ons
plus
que
les
processus
et
les
ou,ls
Des
soluCons
opéra,onnelles
plus
qu’une
documenta,on
exhaus,ve
La
collabora,on
avec
les
clients
plus
que
la
négocia,on
contractuelle
L’adapta,on
au
changement
plus
que
le
suivi
d’un
plan
Source:
hZp://agilemanifesto.org/iso/fr/

8. Les
12
principes
Agiles
1.
Notre
plus
haute
priorité
est
de
sa,sfaire
le
client
en
livrant
rapidement
et
régulièrement
des
fonc,onnalités
à
grande
valeur
ajoutée.
2.
Accueillez
posi,vement
les
changements
de
besoins,
même
tard
dans
le
projet.
Les
processus
agiles
exploitent
le
changement
pour
donner
un
avantage
compé,,f
au
client.
3.
Livrez
fréquemment
un
logiciel
opéra,onnel
avec
des
cycles
de
quelques
semaines
à
quelques
mois
et
une
préférence
pour
les
plus
courts.
4.
Les
u,lisateurs
ou
leurs
représentants
et
les
développeurs
doivent
travailler
ensemble
quo,diennement
tout
au
long
du
projet.
5.
Réalisez
les
projets
avec
des
personnes
mo,vées.
Fournissez-­‐leur
l’environnement
et
le
sou,en
dont
ils
ont
besoin
et
faites-­‐leur
confiance
pour
aZeindre
les
objec,fs
fixés.
6.
La
méthode
la
plus
simple
et
la
plus
efficace
pour
transmeZre
de
l’informa,on
à
l'équipe
de
développement
et
à
l’intérieur
de
celle-­‐ci
est
le
dialogue
en
face
à
face.
Source:
hZp://agilemanifesto.org/iso/fr/

9. Les
12
principes
agiles
(suite)
7.
Un
logiciel
opéra,onnel
est
la
principale
mesure
d’avancement.
8.
Les
processus
agiles
encouragent
un
rythme
de
développement
soutenable.
Ensemble,
les
commanditaires,
les
développeurs
et
les
u,lisateurs
devraient
être
capables
de
maintenir
indéfiniment
un
rythme
constant.
9.
Une
aZen,on
con,nue
à
l'excellence
technique
et
à
une
bonne
concep,on
renforce
l’agilité.
10.
La
simplicité
–
c’est-­‐à-­‐dire
l’art
de
minimiser
la
quan,té
de
travail
inu,le
–
est
essen,elle.
11.
Les
meilleures
architectures,
spécifica,ons
et
concep,ons
émergent
d'équipes
autoorganisées.
12.
À
intervalles
réguliers,
l'équipe
réfléchit
aux
moyens
de
devenir
plus
efficace,
puis
règle
et
modifie
son
comportement
en
conséquence.
Source:
hZp://agilemanifesto.org/iso/fr/

10. Pourquoi
adopter
l’agilité?
• Sa,sfaire
rapidement
le
client
avec
des
solu,ons
logicielles
u,les;
• Augmenter
la
qualité;
• Augmenter
la
produc,vité
et
réduire
les
coûts;
• Faire
face
à
la
complexité;
• Réduire
le
temps
de
mise
en
marché;
– Réduire
les
inefficacités;
– Éviter
les
longues
périodes
de
stabilisa,on
en
fin
de
projet;
• Augmenter
la
mo,va,on,
la
collabora,on
et
l’engagement
des
individus.
Devenir
agile
pour
suivre
le
courant,
c’est
une
mauvaise
idée!

11. Limites
et
défis
des
approches
agiles
• C’est
une
approche,
pas
une
méthode:
demande
de
changer
le
savoir-­‐être
• Révèle
les
inefficacités
d’une
organisa,on,
qui
sont
parfois
majeures:
–
–
–
–
–
–
L’exercice
du
leadership
La
reconnaissance
de
l’exper,se
La
descrip,on
de
poste
La
culture
d’entreprise
La
rela,on
avec
le
client
Les
processus
et
procédures
de
travail
Même
combat,
peu
importe
le
domaine
d’affaires

12. Limites
et
défis
des
approches
agiles
• Intégra,on
difficile
avec
les
méthodes
tradi,onnelles:
– Pas
toujours
bien
adaptées
avec
les
méthodes
de
ges,on
de
projet
tradi,onnelles;
– Source
poten,elle
de
conflit
de
nature
contractuelle;
• Implica,on
exigeante
pour
le
client
et
les
équipes
de
projet;
• Elles
demandent
de
la
rigueur,
de
la
maturité,
de
la
confiance
et
de
la
transparence
pour
réussir.

13. Lean
en
quelques
mots
Principes
• Éliminer
le
gaspillage
• Améliorer
la
rétroac,on
• Prendre
les
décisions
au
dernier
moment
responsable
• La
livraison
la
plus
rapide
possible
• La
prise
de
recul
et
le
regard
global
Un
système
de
flux
Cré
Source:
hZp://cdi-­‐usa.biz/mission-­‐directed-­‐work-­‐
teams/5-­‐lean-­‐workflow/
Bonne
méthode
pour
améliorer
un
processus
de
travail

14. Lean:
le
tableau
Kanban
Pile de
travail
Réalisation
Acceptation
Déploiement
3
3
1
D2
D3
1
D4
D5
D6
3
D7
D8
D9
D10
D11
D12
Source:
Choisir
l’Agilité
de
Mathieu
Boisvert
et
Sylvie
Trudel
Terminé
1
D1

15. Scrum
en
quelques
mots
Product
Owner
(le
client)
Product
Backlog
ou
carnet
de
produit
Dev
Team
(l’équipe
de
travail)
Sprint
Planning
ou
Planifica,on
Daily
Scrum
ou
mêlée
quo,dienne
Sprint
ou
Itéra,on
Sprint
review:
inspec,on
du
produit
Sprint
Retrospec,ve:
inspec,on
des
pra,ques
Source:
Wikipedia
Bonne
méthode
pour
gérer
le
développement
complexe
d’un
produit

16. Scrum:
les
rôles
Product
Owner
(le
client)
• La
vision
du
produit;
• Le
carnet
de
produit
• Évalue
le
résultat
des
itéra,ons
• Communique
l’état
d’avancement
• Collaborer
avec
l’équipe
Scrum
• Collaborer
avec
les
par,es
prenantes
Dev
Team
(l’équipe
de
travail)
• Choisit
le
contenu
du
Sprint
Backlog
• Auto-­‐gérée
et
auto-­‐
organisée;
• Collabore
avec
le
Product
Owner;
• Mul,disciplinaire:
Compétences
pour
livrer
un
incrément
complet.
Scrum
Master
(coach
d’équipe)
• Bonne
applica,on
du
processus
• S’assurer
que
l’équipe
est
fonc,onnelle,
produc,ve
et
améliore
sa
qualité
• Protéger
l’équipe
des
interven,ons
externes
• Servant
Leader

17. Agile
dans
sa
forme
la
plus
simple
Terminer
ce
que
l’on
commence
Inspecter
le
résultat

18. Agile
en
famille
Seulement
avec
une
mêlée
quo,dienne
et
une
liste
de
tâches,
Bruce
Feiler
a
modifié
la
rou,ne
du
ma,n
de
sa
pe,te
famille.

19. Quelques
inspira,ons:
Des
ques,ons?

20. MENER
UN
PROJET
DE
GESTION
DU
CHANGEMENT
AVEC
LES
MÉTHODES
AGILES

21. N’oubliez
pas,
votre
approche
peut
être
très
simple
Terminer
ce
que
l’on
commence
Inspecter
le
résultat

22. Comment
choisir
entre
le
Scrum
et
le
Lean?

23. Le
choix
entre…
Lean:
pour
améliorer
un
processus
Source:
hZp://www.contrepoints.org/2011/09/04/44030-­‐
gains-­‐de-­‐produc,vite/chaine-­‐de-­‐montage-­‐robo,se
Scrum:
pour
le
développement
de
produit
et/ou
gérer
la
complexité
Wikispeed:
hZp://www.youtube.com/watch?v=x8jdx-­‐lf2Dw

24. ou
Lean?
Scrum?
• Améliorer
le
temps
de
traitement
d’une
demande
de
réclama,on?
Réponse:
Probablement
Lean
• Construire
un
programme
de
ges,on
du
changement?
Réponse:
Probablement
Scrum
• Construire
une
maison?
Réponse:
Hum,
pas
facile…
regardons
ensemble
la
livraison
incrémentale
et
itéra,ve
pour
nous
aider
à
répondre.

25. Incrément
versus
Itéra,on
Incrément
(porCon
complète
à
chaque
fois)
ItéraCon
(vérifie
fréquemment
que
l’on
approche
de
la
vision)

26. Scrum
propose
une
approche
itéra,ve
et
incrémentale
Déroulement
du
projet
Lean
n’impose
pas
d’approche
par,culière
Tiré
du
matériel
de
forma,on
de
Pyxis
Technologies
Basé
sur
:
hZp://www.agileproductdesign.com/blog/dont_know_what_i_want.html

27. Comment
planifier
un
incrément?
• Quelle
grosseur
cons,tuera
un
incrément
suffisant?
• Combien
de
points
d’inspec,on
ceZe
grosseur
permeZra-­‐t-­‐elle?
• En
combien
de
temps
est-­‐il
possible
de
construire
cet
incrément?

28. Mauvais
incrément:
Le
cas
de
la
construc,on
d’une
maison

29. Meilleurs
exemples
de
la
construc,on
incrémentale
Empire
State
Building
hZp://www.fastcodesign.com/1671701/micro-­‐
apartments-­‐give-­‐a-­‐hint-­‐of-­‐city-­‐livings-­‐future

30. Pourquoi
c’est
important
de
livrer
par
incrément,
périodiquement?
Parce
que
l’évalua,on
de
l’incrément
est
au
cœur
de
la
ges,on
de
projet
agile
– Ges,on
du
risque
– Ges,on
des
demandes
de
changement
– Mesurer
la
progression
du
projet
– Réduit
le
travail
en
parallèle
(on
termine
ce
que
l’on
commence)

31. Que
faire
si
c’est
impossible
de
livrer
un
incrément
en
un
mois
et
moins
?
• Ne
le
faites
pas!
(avons-­‐nous
affaire
à
un
processus?)
• Sachez
cependant
que
plusieurs
entreprises
en
développement
logiciel
affirmait
la
même
chose
et
qu’avec
l’évolu,on
de
nos
pra,ques,
c’est
maintenant
possible!
• Exemple
de
Wikispeed,
qui
a
changé
ses
pra,ques
pour
réussir
à
livrer
des
pièces
en
1
mois.

32. Comment
choisir
le
contenu
de
l’incrément?
Les
objec,fs
La
valeur
d’affaires
Les
risques
Capitaliser
sur
ce
qui
est
prêt

33. «
Ben
voyons!
Je
t’écoute
depuis
tout
à
l’heure,
ça
marche
pas
ton
affaire.
»
Cas
de
Louis
dont
le
projet
est
de
répondre
à
un
appel
d’offre
sur
invita,on

34. Est-­‐ce
que
le
projet
de
Louis
peut
être
fait
avec
Scrum?
• Méthode:
Scrum
• Valeur
d’affaires:
les
sec,ons
sensibles,
risquant
de
causer
le
refus
de
la
proposi,on
• Incrément:
Sec,on
du
document
• Itéra,on:
2
semaines
• Organisa,on
du
travail:
une
équipe
d’architectes
et
rédacteurs
techniques

35. «
As-­‐tu
un
autre
exemple?
»
Cas
de
Mathieu
qui
conçoit
un
cours
universitaire
à
propos
des
méthodes
agiles

36. Est-­‐ce
que
le
projet
de
Mathieu
peut
être
fait
avec
Scrum?
• Méthode:
Scrum
• Valeur
d’affaires:
Objec,fs
d’appren,ssage
aZeints?
(concevoir
les
devoirs
en
conséquence)
• Incrément:
Un
cours
de
3
heures
(matériel,
atelier,
exemple,
etc.)
• Itéra,on:
1
semaine
• Organisa,on
du
travail:
les
deux
chargés
de
cours

37. Un
projet
de
ges,on
du
changement
pour
un
nouveau
logiciel
de
mission
Source:
hZp://www.manutri,onniste.com/les-­‐etapes-­‐de-­‐changement/

38. La
valeur
d’affaires
d’un
projet
de
ges,on
du
changement?
Les
livrables
(Incrément)
•
•
•
•
•
•
•
Forma,on
Aide
en
ligne
Aide
à
la
tâche
Capsules
vidéo
Documenta,on
/
références
Bulle,n
de
nouvelles
[…]
Incidences
(Valeur
d’affaires)
Factura,on
Inscrire
un
bâ,ment
Planifier
un
projet
Consulter
un
rapport
Évaluer
un
projet
de
rénova,on
• […]
•
•
•
•
•

39. Le
meilleur
programme
de
ges,on
du
changement
dans
les
ressources
disponibles
1. Choisir
une
méthode
de
travail:
Scrum
2. Iden,fier
la
valeur
d’affaires:
les
incidences
3. Planifier
un
incrément:
aide
à
la
tâche,
module
de
forma,on
4. Vérifier
les
résultats:
est-­‐ce
que
les
employés
ont
compris?
5. Recommencer:
corriger
et/ou
poursuivre
le
programme?

40. Dernier
point
important:
l’améliora,on
con,nue
des
pra,ques
• Principe
#9
Une
aZen,on
con,nue
à
l'excellence
technique
et
à
la
qualité
de
la
concep,on.
• Principe
#10
La
simplicité
et
l'art
de
minimiser
les
tâches
parasites,
sont
appliqués
comme
principes
essen,els.
• Principe
#12
À
intervalles
réguliers,
l'équipe
réfléchit
aux
moyens
de
devenir
plus
efficace,
puis
règle
et
modifie
son
comportement
en
conséquence.
extremeProgramming:
une
inspira,on!

41. Quelques
inspira,ons:
• La
famille
agile
de
Bruce
Feiler:
hZp://www.youtube.com/watch?v=J6oMG7u9HGE
• La
voiture
Scrum
de
Joe
JusCce
(Wikispeed):
hZp://www.youtube.com/watch?v=x8jdx-­‐lf2Dw
• Mon
expérience
de
chargé
de
cours:
hZp://pyxis-­‐tech.com/blog/2013/02/14/revela,on-­‐dun-­‐
jeune-­‐charge-­‐de-­‐cours/
Des
ques,ons?

42. La
ges,on
du
changement
lors
d’une
transi,on
vers
l’Agilité
LA
STRUCTURE
ORGANISATIONNELLE

43. L’agilité
comme
élément
de
la
stratégie
d’entreprise
• Requiert
au
préalable
un
consensus
sur
les
raisons
ayant
introduit
l’agilité;
• Il
est
important
que
tous
ceux
ayant
un
rôle
à
jouer
dans
le
sou,en
de
ceZe
ini,a,ve
en
deviennent
les
promoteurs:
le
seul
financement
de
la
transi,on
est
insuffisant;
• L’agilité
est
une
philosophie
de
travail:
il
est
possible
que
l’organisa,on
doive
:
– réunir
certaines
condi,ons
gagnantes;
– accepter
de
se
faire
bousculer;
– être
récep,ve
aux
raisons
et
aux
objec,fs
du
manifeste,
aux
méthodes
et
aux
pra,ques
agiles.

44. An,ciper
les
objec,ons
Les
dirigeants
peuvent
craindre
de
perdre
leurs
acquis
:
contrôle,
pouvoir
et
avantages
liés
à
leur
,tre:
«
Avec
l’agilité,
je
vais
perdre
le
contrôle
puisque
les
équipes
seront
autogérées
!
»
«
Mais
comment
va-­‐t-­‐on
y
arriver
?
Nous
manquons
déjà
de
temps
pour
tout
faire…
»
«
Mais
pourquoi
l’agilité
?
Le
statu
quo
n’est
pas
si
mal
que
ça…
»
«
Ah
mais
c’est
que
j’ai
des
intérêts
personnels
et
l’agilité
ne
me
sert
absolument
pas
!
»
«
Là,
on
me
demande
de
faire
appliquer
une
nouvelle
méthodologie
à
mes
équipes
et
personne
ne
m’a
impliqué
dans
la
décision.
»

45. Compréhension
commune
À
quoi
s’aZendre
:
• Un
processus
empirique
• Un
carnet
de
commande
priorisé
• La
livraison
d’incréments
de
produits
terminés
• Une
équipe
auto-­‐organisée
Les
appréhensions/interpréta,ons
fréquentes
:
• L’abandon
de
la
ges,on
de
projet
• La
fin
de
la
documenta,on
• L’anarchie
des
équipes
• Une
excuse
pour
le
laxisme
• La
solu,on
à
tous
les
problèmes
Bien
qu’elles
soient
dites
légères,
les
méthodes
agiles
requièrent
de
la
rigueur
et
de
la
discipline.

46. L’imputabilité
Direc,on
Affaires
• soutenir
les
ini,a,ves
du
responsable
de
produit
;
• éliminer
les
obstacles
rencontrés
par
les
équipes
;
• orchestrer
les
ac,vités
autour
de
la
livraison
:
déploiement,
forma,on,
marke,ng,
etc.
;
• assurer
le
succès
de
chacun
des
projets
d’affaires
impliquant
du
développement
logiciel.
Direc,on
des
TI
• qualité
des
logiciels
livrés
;
• améliora,on
con,nue
des
processus,
méthodes
et
ou,ls
de
développement
sur
les
axes
de
coûts,
de
délais
et
de
qualité
;
• améliora,on
de
la
cohésion
des
équipes
;
• montée
en
compétence
des
membres
d’équipes
;
• accompagnement
des
affaires
dans
la
ges,on
de
produit
logiciel.

47. Structure
d'équipe
Agile
L’équipe
Scrum
se
compose…
du
Scrum
Master
,
Des
Équipiers,
Ges,onnaires
Du
Responsable
de
produit,
de
l’ensemble
des
individus
ayant
les
compétences
pour
produire
un
incrément
de
produit.
Et
moi
?
Les
collaborateurs
et
les
contributeurs
sou,ennent
l’équipe
Source:
Rôle
de
l’architecte
agile,
présenté
par
Jean-­‐René
Rousseau
et
Mathieu
Boisvert,
Pyxis
Clients
Experts

48. Le
client
Choisir
le
bon
candidat:
• Est-­‐il
disponible?
• Est-­‐il
crédible?
• Connaît-­‐il
la
vision
du
produit?
• Est-­‐ce
un
bon
communicateur?
Probable
que
le
candidat
doive
apprendre
le
mé,er
de
Product
Owner

49. Les
spécialistes:
Être
ou
ne
pas
être
dans
l’équipe
?
• Être
dans
l’équipe
est
sans
doute
la
meilleure
posture
pour
accomplir
vos
objec,fs
• Mais…
Aurez-­‐vous
la
disponibilité
nécessaire?
– Plus
souvent
qu’autrement,
les
spécialistes
se
posi,onnent
comme
un
collaborateur
• Vous
avez
donc
un
défi
supplémentaire
– Ne
pas
être
un
goulot!
Rôle de l’architecte agile,
présenté par Jean-René Rousseau et Mathieu Boisvert, Pyxis

50. Le
défi
du
collaborateur
• Il
faut
à
tout
prix
éviter
les
situa,ons
suivantes:
– L’équipe
abend
après
une
décision
– L’équipe
se
fait
systéma,quement
reprendre
ses
ini,a,ves
et
perd
ainsi
confiance
– L’équipe
n’a
pas
accès
à
l’informaCon
qui
lui
permeZrait
de
décider
– Bref…
l’équipe
a
constamment
besoin
de
son
architecte…
qui
n’est
pas
toujours
disponible!

51. Les
ges,onnaires
Répercussions
sur
le
rôle
de
la
direc,on
/
vice-­‐présidence
• Définir
les
objec,fs
de
leurs
équipes
ou
leurs
départements
au
lieu
de
meZre
l’accent
sur
leurs
tâches;
• Prioriser
les
objec,fs
au
lieu
de
prioriser
les
ac,vités;
• Suivre
la
progression
vers
l’aZeinte
de
ces
objec,fs;
• Con,nuer
de
protéger
les
ressources
des
équipes
afin
d’augmenter
leur
cohésion
et,
par
conséquent,
leur
performance;
• Soutenir
les
employés
dans
leur
développement
de
carrière;
• Construire
et
entretenir
des
rela,ons
avec
les
autres
départements
et
équipes.

52. Impacts
sur
la
structure
organisa,on
Exemple de matrice
RACI dans un
contexte non agile.
Exemple de
matrice RACI dans
un contexte agile.

53. Leadership
situa,onnel
1.
Imposer
(Tell)
Imposer
une
décision
à
l’équipe
2.
Vendre
(Sell)
Décider
et
convaincre
l’équipe
3.
Consulter
(Consult)
Consulter
l’équipe
avant
de
décider
4.
Collaborer
(Agree)
Décider
en
collabora,on
avec
l’équipe
5.
Aviser
(Advise)
Influencer
la
décision
prise
par
l’équipe
6.
Demander
(Inquire)
S’informer
d’une
décision
prise
par
l’équipe
7.
Déléguer
(Delegate)
Laisser
l’équipe
prendre
ses
propres
décisions
Tiré
du
matériel
de
forma,on
de
Pyxis
Technologies
Source
:
Jurgen
Appelo,
Management
3.0
–
leading
agile
developers,
developing
agile
leaders

54. La
ges,on
du
changement
lors
d’une
transi,on
vers
l’Agilité
LA
CULTURE

55. Selon
vous,
quelles
sont
les
causes
principales
d’échecs
des
projets
agiles?

56. Percep,on
des
causes
principales
d’échecs
des
projets
agiles.
La
culture
est
impliquée
dans
au
moins
19%
des
cas,
soit
la
«
culture
organisa,onnelle
à
l’encontre
des
valeurs
et
principes
agiles
»
(11%)
et
le
«
manque
de
transi,on
culturelle
»
(8%).
Source:
VersionOne,
State
of
Agile
Survey
2010.
Données
recueillies
auprès
de
4
770
par,cipants
dans
91
pays,
entre
le
11
août
et
le
31
octobre
2010.

57. Types
de
cultures
Tiré
de
l’ouvrage
The
Reengineering
Alterna,ve
de
William
E.
Schneider

58. Caractéris,ques
des
cultures

59. Caractéris,ques
des
cultures
Caractéris,que
des
cultures

60. La
culture
de
préférence
de
l’agilité
Sondage
mené
auprès
d’environ
120
personnes
qui
appliquent
l’agilité
et
provenant
de
cultures
différentes,
par
Michael
Spayd,
en
mai
2010

61. Prédisposi,ons
et
indisposi,ons
Collabora'on
• prédisposé
au
travail
d’équipe
• de
bons
généralistes
s’aZribuant
la
prochaine
tâche
d’équipe
à
pied
levé
• individus
veulent
tout
décider
par
consensus
• s’embourbent
dans
des
réunions
où
tous
doivent
être
présents
• cherchent
l’avis
de
tous
et
de
chacun
avant
de
prendre
une
décision
Accomplissement
• la
croissance
concerne
à
la
fois
les
individus
et
les
équipes
• les
inspec,ons
et
les
rétrospec,ves
sont
menées
avec
un
souci
d’apprendre,
de
,rer
des
leçons
et
de
s’améliorer
• manque
de
canalisa,on
envers
les
résultats
• nouvelles
idées
provoquent
de
l’éparpillement
• manque
de
rigueur

62. Prédisposi,ons
et
endisposi,ons
Prédisposi,ons
i t
indisposi,ons
Compétence
• font
preuve
de
rigueur
et
de
discipline
à
propos
de
la
collecte,
l’analyse
et
la
présenta,on
des
données
d’avancement
ainsi
que
du
calcul
de
l’effort
restant
et
de
la
vélocité
• cul,ve
les
secrets,
et
la
poli,que
finit
par
prendre
le
dessus
sur
l’efficacité
• transparence
est
permise
seulement
lorsque
que
les
résultats
plaisent
• le
concept
d’équipe
auto-­‐organisée
passe
mal
Contrôle
• propension
à
livrer
des
produits
de
qualité
supérieure
à
ceux
de
la
compé,,on
demande
la
contribu,on
d’individus
spécialisés,
ayant
de
très
grandes
compétences
techniques
• réduit
la
possibilité
de
prendre
des
engagements
collec,fs
• l’engagement
d’équipe
est
absent
ou
chao,que

63. La
ges,on
du
changement
lors
d’une
transi,on
vers
l’Agilité
LE
PLAN
DE
TRANSITION

64. Ges,on
de
la
transi,on
agile
• Un
sen,ment
d’urgence
La
situa,on
actuelle
est
intolérable
et
il
est
impéra,f
de
changer
rapidement.
La
souffrance
étant
grande,
l’organisa,on
devient
prête
à
essayer
n’importe
quelle
alterna,ve
pour
changer
sa
situa,on.
• Un
facteur
volontaire
posi,f
L’organisa,on
a
eu
quelques
résultats
mi,gés
et
les
équipes
de
développement
désirent
améliorer
la
situa,on,
bien
que
la
souffrance
soit
faible.
• Un
facteur
néga,f
ou
involontaire
La
haute
direc,on
impose
un
changement
n’étant
pas
perçu
comme
nécessaire.
Cela
crée
un
inconfort
et
une
souffrance,
comme
si
soudainement
une
solu,on
se
cherchait
un
problème.

65. La
ges,on
du
changement

66. Ges,on
des
risques
de
l’adop,on
Évaluer
les
impacts
d’une
transi,on
agile
en
tenant
compte
de
la
culture,
de
la
structure
de
gouvernance,
des
projets
en
cours
et
à
venir
et
des
technologies
u,lisées.
Adopter
une
stratégie
de
transiCon
agile
tenant
compte
de
la
culture,
des
risques
et
des
impacts
sur
l’organisa,on.
Planifier
et
faire
le
suivi
du
projet
de
transi,on
agile
qui
doit
être
traité
comme
un
projet
organisa,onnel.
Choisir
les
méthodes
agiles
qui
conviennent
aux
besoins
et
au
contexte
organisa,onnel.
Adapter
les
processus
ou
définir
un
cadre
méthodologique
dans
lequel
les
méthodes
agiles
choisies
sont
mises
en
œuvre
avec
des
principes
directeurs.
Se
doter
d’ouCls
adéquats
pour
opéra,onnaliser
les
processus
et
donner
de
la
visibilité
à
tous.
Former
et
accompagner
les
ges,onnaires,
les
membres
d’équipes
et
les
clients
impliqués
dans
les
projets
de
développement.
Évaluer
l’applicaCon
des
praCques
agiles
à
intervalles
réguliers
pour
s’assurer
que
l’organisa,on
ob,endra
le
rendement
escompté
et
appliquer
les
adapta,ons
requises
pour
y
arriver.

67. Stratégie
de
mise
en
œuvre
• Par
les
ges'onnaires
l’adop,on
de
l’agilité
provient
d’un
ges,onnaire
important
qui
sait
communiquer
et
partager
sa
vision
de
l’agilité.
• Par
les
équipes
(par
le
bas)
des
équipes
de
développement
logiciel
qui
sont
à
l’origine
de
la
mise
en
œuvre
des
pra,ques
agiles
• En
sandwich
combinaison
des
approches
«
par
les
ges,onnaires
»
et
«
par
les
équipes
»
• Progressiste
commencer
avec
un
projet
et
contaminer
de
plus
en
plus
de
projets
• Big
Bang
tabula
rasa
sur
les
méthodologies
qui
existent
et
tout
démarrer
ou
redémarrer
en
mode
agile

68. Des
ques,ons?