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%    Dépassement   53%   33%   46%   49%   51%   53%   46%   44%    Échec   31%   40%   28%   23%   15%   18%   19%   24%  

0%  

10%  

20%  

30%  

40%  

50%  

60%  

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  

14%  

57%  

29%  

2012  –  Cycle  en  V  

42%  

49%  

9%  

2012  -­‐  Agile  

Succès  

Hors  délai  ou  budget  Échec  

Généra^on  Y    ou  la  soif  de  collaborer  !    

COMMENT  PASSER  À  UNE  POSTURE  AGILE  ?  

Un  état  d’esprit  

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

Exigences   Concep^on   Code   Test  

Ac^vités  séquen^elles  vs.  parallèles  

Décider  le  plus  tard  possible  

                                                   

Palo  IT  2012  ©                                            16  

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  

Processus  et  ou^ls  Personnes  et  interac^ons   >  

Suivre  un  plan  S'adapter  au  changement   >  

Source  :  www.agilemanifesto.org  

Documenta^on  Logiciel  qui  fonc^onne   >  

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

FLOW Avg lead time: days 12

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  

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  ©                                

Développer  

Mesurer  

Apprendre  /Améliorer  

Idées  

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