Présentation de l'Agilité au breakfast "Devops" organisé par l'IDC le 18 septembre à Paris

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. Pourquoi
l’Agilité
?

4. POURQUOI
L’AGILE
AUJOURD’HUI
?

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. Enjeux
de
l’agilité

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. QUELLE
APPROCHE
AGILE
ADOPTER
?

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. DEVOPS

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