Vous avez dit « agile » ? 
18 
septembre 
2014 
-­‐ 
Xavier 
Warzee 
Breakfast 
IDC 
« 
Devops 
»
Xavier Warzee 
• Web : http://www.scrumconseil.fr 
• Twitter : @xwarzee 
• LinkedIn : http://www.linkedin.com/in/xwarzee 
• Email : xwarzee@scrumconseil.fr
Pourquoi 
l’Agilité 
?
POURQUOI 
L’AGILE 
AUJOURD’HUI 
?
Etude 
« 
Chaos 
Report 
» 
du 
Standish 
Group 
1994 
1996 
1998 
2000 
2002 
2004 
2006 
2008 
Succès 
16% 
27% 
26% 
28% 
34% 
29% 
35% 
32% 
60% 
50% 
40% 
30% 
20% 
10% 
Dépassement 
53% 
33% 
46% 
49% 
51% 
53% 
46% 
44% 
Échec 
31% 
40% 
28% 
23% 
15% 
18% 
19% 
24% 
0%
Quelques 
chiffres… 
18% 
53% 
29% 
Réussite 
des 
projets 
informa@ques 
Echec 
Hors 
délai 
ou 
budget 
Succès 
7% 
13% 
16% 
19% 
45% 
Fonc@onnalités 
u@lisées 
dans 
les 
produits 
Fréquemment 
Souvent 
Parfois 
Rarement 
Jamais 
Source: Standish Group 2004
Constat 
en 
2012 
! 
16% 
53% 
31% 
1994 
2012 
– 
Cycle 
en 
V 
14% 
57% 
29% 
2012 
-­‐ 
Agile 
42% 
9% 
49% 
Succès 
Hors 
délai 
ou 
budget 
Échec
Généra^on 
Y 
ou 
la 
soif 
de 
collaborer 
!
Un 
état 
d’esprit 
COMMENT 
PASSER 
À 
UNE 
POSTURE 
AGILE 
?
Ac^vités 
séquen^elles 
vs. 
parallèles 
Exigences 
Concep^on 
Code 
Test 
Source 
: 
“The 
New 
New 
Product 
Development 
Game” 
par 
Takeuchi 
et 
Nonaka. 
Harvard 
Business 
Review, 
Janvier 
1986. 
...Les 
équipes 
agile 
font 
un 
peu 
de 
tout, 
tout 
le 
temps 
Plutôt 
que 
de 
faire 
toute 
une 
discipline 
d'un 
coup...
Décider 
le 
plus 
tard 
possible 
Livraisons 
incrémentales 
Livraisons 
itéra@ves
Enjeux 
de 
l’agilité
Critères 
de 
succès 
> 
agile 
vs 
classique 
Critères 
de 
succès 
classique 
: 
Aleindre 
l’état 
souhaité 
• Essayer 
de 
prévoir 
à 
chaque 
étape 
toutes 
les 
possibilités 
• Planifier 
dans 
les 
détails 
• Définir 
un 
processus 
prédic^f 
Critères 
de 
succès 
agile 
: 
Aleindre 
un 
bon 
niveau 
d’adapta^on 
au 
contexte 
• Considérer 
les 
changements 
dans 
un 
projet 
comme 
naturels 
• Inspecter, 
à 
chaque 
étape, 
l’état 
d’un 
projet 
et 
s’adapter 
• Pas 
de 
leaders, 
tout 
membre 
de 
l’équipe 
contribue 
! 
• Facilitateurs, 
supporteurs 
plutôt 
qu’experts 
ou 
autorités 
!
Améliora^on 
con^nue 
-­‐ 
Rétrospec^ves 
• Inspecter 
les 
résultats 
d’une 
itéra^on 
• Adapter 
les 
pra^ques 
en 
fonc^on 
des 
objec^fs 
de 
la 
prochaine 
itéra^on, 
de 
la 
composi^on 
de 
l’équipe, 
… 
Figer 
des 
bonnes 
pra^ques 
? 
Dangereux 
! 
• Focus 
sur 
des 
tâches 
à 
faire 
• moins 
d’an^cipa^on 
sur 
l’impact 
de 
nos 
ac^ons 
!!! 
• Perte 
de 
vue 
globale 
Figer 
un 
processus 
? 
Risqué 
! 
• Demander 
aux 
équipes 
de 
développement 
de 
définir 
les 
pra^ques 
adaptées 
à 
une 
itéra^on 
donnée 
Solu^on 
: 
Équipe 
auto-­‐ 
organisée
L’Agilité 
> 
un 
changement 
de 
perspec^ve 
! 
Approche 
Traditionnell 
e orientée 
plan 
Approche 
Agile orientée 
vision 
Fixes 
: 
Fonc@onnalités 
Coûts 
Délais 
Variables 
: 
Coûts 
Délais 
Fon@onnalités
Partager 
les 
valeurs 
du 
Manifeste 
Agile 
Personnes 
et 
Processus 
et 
ou^ls 
interac^ons 
> 
Logiciel 
qui 
fonc^onne 
S'adapter 
au 
Suivre 
un 
plan 
changement 
> 
Source 
: 
www.agilemanifesto.org 
> 
Documenta^on 
Négocia^on 
à 
par^r 
d'un 
contrat 
Collabora^on 
avec 
le 
client 
>
QUELLE 
APPROCHE 
AGILE 
ADOPTER 
?
Kanban 
dans 
le 
logiciel 
Ø 
Workflow 
visuel 
– Limita^on 
du 
TAF 
(Travail 
A 
FAIRE) 
– Flot 
mesuré 
et 
op^misé 
– Règles 
explicites 
(défini^on 
de 
”Done”, 
TAF 
limités, 
etc) 
Introduc^on 
par 
David 
Anderson 
en 
2004 
Backlog Dev Done 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
UAT Deploy 
5 3 2 3 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
FLOW Avg lead time:1 2 days 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur 
orem 
ipsum 
dolor 
sit 
amet, 
co 
nse 
ctetur
Scrum 
: 
la 
mêlée 
et 
les 
3 
piliers 
• La 
transparence 
– Honnêteté 
sur 
l'avancement 
et 
les 
problèmes 
– Une 
défini^on 
claire 
et 
partagée 
de 
« 
Done 
» 
• L'inspec^on 
– Tests 
fréquents 
de 
solu^ons 
par 
le 
biais 
de 
feedback 
– Les 
feedback 
sont 
fournis 
par 
des 
vrais 
u^lisateurs 
et 
clients 
• L'adapta^on 
– Finalisa^on 
du 
produit 
basée 
sur 
les 
feedback 
et 
les 
buts 
à 
aleindre 
– Ajustement 
du 
process 
de 
Scrum 
dès 
que 
nécessaire
Lean 
startup 
& 
Agilité 
Palo 
IT 
2012 
©
La 
démarche 
« 
Lean 
Startup 
» 
Palo 
IT 
2012 
© 
Idées 
Développer 
Apprendre 
/ 
Améliorer 
Mesurer 
Données 
Produit
DEVOPS
L’agilité 
au 
niveau 
management 
Le 
travail 
est 
organisé 
en 
cycle 
court 
Le 
management 
n’interrompt 
pas 
l’équipe 
pendant 
un 
cycle 
L’équipe 
rend 
des 
comptes 
au 
client, 
pas 
au 
manager 
L’équipe 
es^mes 
le 
temps 
qu’il 
lui 
faut 
L’équipe 
décide 
du 
travail 
qu’elle 
peut 
faire 
en 
un 
cycle 
L’équipe 
décide 
comment 
faire 
le 
travail 
pendant 
un 
cycle 
L’équipe 
mesure 
ses 
propres 
performance 
Les 
objec^fs 
à 
aleindre 
sont 
définis 
avant 
le 
départ 
de 
chaque 
cycle 
Les 
objec^fs 
sont 
définis 
par 
des 
usages 
du 
produit 
: 
‘user 
stories’ 
Chercher 
à 
systéma^quement 
lever 
les 
obstacles
Références 
• Organisa^ons 
: 
– L’Agile 
Alliance 
: 
hlp://www.agilealliance.org 
– La 
Scrum 
Alliance 
: 
hlp://www.scrumalliance.org 
– L’Ins^tut 
Agile 
: 
hlp://www.ins^tut-­‐agile.fr 
– Le 
French 
Scrum 
User 
Group 
: 
hlp://www.frenchsug.org 
• Conférences 
– Le 
Scrum 
Day 
: 
hlp://www.scrumday.fr 
– Agile 
France 
: 
hlp://www.conference-­‐agile.fr 
– Lean 
Kanban 
France 
: 
hlp://www.leankanban.fr 
– Agile 
Games 
France 
: 
hlp://www.agilegamesfrance.fr
L'Agilité  - breakfast IDC devops, 18 septembre 2014

L'Agilité - breakfast IDC devops, 18 septembre 2014

  • 1.
    Vous avez dit« agile » ? 18 septembre 2014 -­‐ Xavier Warzee Breakfast IDC « Devops »
  • 2.
    Xavier Warzee •Web : http://www.scrumconseil.fr • Twitter : @xwarzee • LinkedIn : http://www.linkedin.com/in/xwarzee • Email : xwarzee@scrumconseil.fr
  • 3.
  • 4.
  • 6.
    Etude « Chaos Report » du Standish Group 1994 1996 1998 2000 2002 2004 2006 2008 Succès 16% 27% 26% 28% 34% 29% 35% 32% 60% 50% 40% 30% 20% 10% Dépassement 53% 33% 46% 49% 51% 53% 46% 44% Échec 31% 40% 28% 23% 15% 18% 19% 24% 0%
  • 7.
    Quelques chiffres… 18% 53% 29% Réussite des projets informa@ques Echec Hors délai ou budget Succès 7% 13% 16% 19% 45% Fonc@onnalités u@lisées dans les produits Fréquemment Souvent Parfois Rarement Jamais Source: Standish Group 2004
  • 8.
    Constat en 2012 ! 16% 53% 31% 1994 2012 – Cycle en V 14% 57% 29% 2012 -­‐ Agile 42% 9% 49% Succès Hors délai ou budget Échec
  • 12.
    Généra^on Y ou la soif de collaborer !
  • 13.
    Un état d’esprit COMMENT PASSER À UNE POSTURE AGILE ?
  • 15.
    Ac^vités séquen^elles vs. parallèles Exigences Concep^on Code Test Source : “The New New Product Development Game” par Takeuchi et Nonaka. Harvard Business Review, Janvier 1986. ...Les équipes agile font un peu de tout, tout le temps Plutôt que de faire toute une discipline d'un coup...
  • 16.
    Décider le plus tard possible Livraisons incrémentales Livraisons itéra@ves
  • 17.
  • 18.
    Critères de succès > agile vs classique Critères de succès classique : Aleindre l’état souhaité • Essayer de prévoir à chaque étape toutes les possibilités • Planifier dans les détails • Définir un processus prédic^f Critères de succès agile : Aleindre un bon niveau d’adapta^on au contexte • Considérer les changements dans un projet comme naturels • Inspecter, à chaque étape, l’état d’un projet et s’adapter • Pas de leaders, tout membre de l’équipe contribue ! • Facilitateurs, supporteurs plutôt qu’experts ou autorités !
  • 19.
    Améliora^on con^nue -­‐ Rétrospec^ves • Inspecter les résultats d’une itéra^on • Adapter les pra^ques en fonc^on des objec^fs de la prochaine itéra^on, de la composi^on de l’équipe, … Figer des bonnes pra^ques ? Dangereux ! • Focus sur des tâches à faire • moins d’an^cipa^on sur l’impact de nos ac^ons !!! • Perte de vue globale Figer un processus ? Risqué ! • Demander aux équipes de développement de définir les pra^ques adaptées à une itéra^on donnée Solu^on : Équipe auto-­‐ organisée
  • 20.
    L’Agilité > un changement de perspec^ve ! Approche Traditionnell e orientée plan Approche Agile orientée vision Fixes : Fonc@onnalités Coûts Délais Variables : Coûts Délais Fon@onnalités
  • 21.
    Partager les valeurs du Manifeste Agile Personnes et Processus et ou^ls interac^ons > Logiciel qui fonc^onne S'adapter au Suivre un plan changement > Source : www.agilemanifesto.org > Documenta^on Négocia^on à par^r d'un contrat Collabora^on avec le client >
  • 22.
  • 23.
    Kanban dans le logiciel Ø Workflow visuel – Limita^on du TAF (Travail A FAIRE) – Flot mesuré et op^misé – Règles explicites (défini^on de ”Done”, TAF limités, etc) Introduc^on par David Anderson en 2004 Backlog Dev Done orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur UAT Deploy 5 3 2 3 orem ipsum dolor sit amet, co nse ctetur FLOW Avg lead time:1 2 days orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur
  • 24.
    Scrum : la mêlée et les 3 piliers • La transparence – Honnêteté sur l'avancement et les problèmes – Une défini^on claire et partagée de « Done » • L'inspec^on – Tests fréquents de solu^ons par le biais de feedback – Les feedback sont fournis par des vrais u^lisateurs et clients • L'adapta^on – Finalisa^on du produit basée sur les feedback et les buts à aleindre – Ajustement du process de Scrum dès que nécessaire
  • 25.
    Lean startup & Agilité Palo IT 2012 ©
  • 26.
    La démarche « Lean Startup » Palo IT 2012 © Idées Développer Apprendre / Améliorer Mesurer Données Produit
  • 27.
  • 28.
    L’agilité au niveau management Le travail est organisé en cycle court Le management n’interrompt pas l’équipe pendant un cycle L’équipe rend des comptes au client, pas au manager L’équipe es^mes le temps qu’il lui faut L’équipe décide du travail qu’elle peut faire en un cycle L’équipe décide comment faire le travail pendant un cycle L’équipe mesure ses propres performance Les objec^fs à aleindre sont définis avant le départ de chaque cycle Les objec^fs sont définis par des usages du produit : ‘user stories’ Chercher à systéma^quement lever les obstacles
  • 29.
    Références • Organisa^ons : – L’Agile Alliance : hlp://www.agilealliance.org – La Scrum Alliance : hlp://www.scrumalliance.org – L’Ins^tut Agile : hlp://www.ins^tut-­‐agile.fr – Le French Scrum User Group : hlp://www.frenchsug.org • Conférences – Le Scrum Day : hlp://www.scrumday.fr – Agile France : hlp://www.conference-­‐agile.fr – Lean Kanban France : hlp://www.leankanban.fr – Agile Games France : hlp://www.agilegamesfrance.fr