PMI - Auvergne

AGILITE : HISTOIRE D’UN CHEF DE PROJET
QUI ADOPTE L’AGILITE
Personnages

Jacques       Le directeur des études de l'entreprise Y

Paul          Un chef de projet informatique de l'entreprise Y


Nicolas       Un scrum master au sein de l’entreprise Z, ami de
              Paul

Pierre        Un coach agile

L’équipe      Les membres de l’équipe du projet X



La            Les chefs de projet de l’entreprise Y
communauté
DANS LE BUREAU DE JACQUES
Les meilleures
    décisions sont                    L’IT et les équipes
      prises, les                      métier travaillent
   conceptions les                    main dans la main
  plus simples sont
      adoptées.


                      Mon rêve pour
                        l’avenir



                                          Le processus de
 Mes projets me                           développement
  rapportent un                             autorise une
bénéfice plus tôt.                             quantité
                                           raisonnable de
                                            changements
Motif du recours à l'agilité
                                    French Scrum User Group 2011


                  Réduire les risques




           Accélérer le time to market




Motiver les équipes de développement




            Intégrer les changements




                  Améliorer la qualité



                                         0%   10%   20%   30%   40%   50%   60%   70%   80%   90%   100%
Ancienneté de l'adoption
     French Scrum User Group 2011




Plus de 3
ans, 28%                     Moins de 1
                             ans, 34%




    Entre 1 ans et 3
       ans, 38%
Profondeur de l'adoption
          French Scrum User Group 2011




                             Ne sait pas, 18%
    Généralisée, 19%




                                        A titre
  En cours de                      expérimental, 15
généralisation, 22                        %
        %


                         Sur un projet
                             pilote
                       stratégique, 26%
Impact constaté de l'adoption de l'agilité
                                                  French Scrum User Group 2009

             Respect des budgets


Fréquence des mises en production
                                                                                                        Ne sait pas

               Respect des délais                                                                       Dégradation

                                                                                                        Pas de changement
         Augmenter la productivité
                                                                                                        Légère amélioration

       Satisfaction des utilisateurs                                                                    Amélioration
                                                                                                        sensible

         Amélioration de la qualité


                                       0%   10%    20%   30%   40%   50%   60%   70%   80%   90% 100%
SUR LE WEB
Manifeste pour le développement Agile de logiciels
2001
Nous découvrons comment mieux développer des logiciels par la pratique et
en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

Les individus et leurs interactions plus que les processus et
les outils
Des logiciels opérationnels plus qu’une documentation
exhaustive
La collaboration avec les clients plus que la négociation
contractuelle
L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments,
mais privilégions les premiers.
   Notre plus haute priorité est de satisfaire le client
    en livrant rapidement et régulièrement des
    fonctionnalités à grande valeur ajoutée.
   Livrez fréquemment un logiciel opérationnel
    avec des cycles de quelques semaines à
    quelques mois et une préférence pour les plus
    courts.
   Un logiciel opérationnel est la principale mesure
    d’avancement.
 Accueillez positivement les changements de
  besoins, même tard dans le projet. Les
  processus Agiles exploitent le changement
  pour donner un avantage compétitif au client.
 Les utilisateurs ou leurs représentants et les
  développeurs doivent travailler ensemble
  quotidiennement tout au long du projet.
 La méthode la plus simple et la plus efficace
  pour transmettre de l’information à l'équipe
  de développement et à l’intérieur de celle-ci
  est le dialogue en face à face.
 Réalisez les projets avec des personnes
  motivées. Fournissez-leur l’environnement
  et le soutien dont ils ont besoin et faites-
  leur confiance pour atteindre les objectifs
  fixés.
 Les processus Agiles encouragent un
  rythme de développement soutenable.
  Ensemble, les commanditaires, les
  développeurs et les utilisateurs devraient
  être capables de maintenir indéfiniment un
  rythme constant.
 Une attention continue à l'excellence
  technique et à une bonne conception
  renforce l’Agilité.
 La simplicité – c’est-à-dire l’art de minimiser
  la quantité de travail inutile – est essentielle.
 Les meilleures architectures, spécifications et
  conceptions émergent d'équipes auto-
  organisées.
 À intervalles réguliers, l'équipe réfléchit aux
  moyens de devenir plus efficace, puis règle
  et modifie son comportement en
  conséquence.
AVEC NICOLAS, SUR LE PLATEAU DE SON
                             PROJET
LES RÔLES DANS SCRUM




                 http://emmanuelchenu.blogspot.com/
LES RITUELS & ARTEFACTS SCRUM


                  Daily
                 Meeting




       Sprint
      Planning
      Meeting
                                  Rétrospecti
                           Démo
                                      ve
LES ACTIVITÉS DES ITÉRATIONS SE CHEVAUCHENT
Version N-1




                                Acceptance au fil de l’eau
               Construction      Correction des defects
Version N




                                                             Acceptance au fil de
              Préparation des                                       l’eau
                                    Construction               Correction des
                user stories
                                                                  defects
Version N+1




                                Préparation des user
                                                              Construction
                                      stories

               Itération N -1          Itération N              Itération N+1
USER STORIES

 En  tant que responsable marketing
 Je peux avoir une vue sur l’origine des
  connections au site
 Afin de mieux cibler mes campagnes de
  publicité
DÉCOUPAGE EN USER STORIES
Un découpage vertical, de bout en bout
 I(ndependant)
 N(egociable)
 V(aluable)
 E(stimatable)
 S(mall)
 T(estable)
+ Des user stories homogènes en terme de
  priorité
CRITÈRES D’ACCEPTANCE

 Si je suis responsable marketing, j’ai accès à
  l’origine des connections
  (pays, entreprise, CSP)
 Si je ne suis pas responsable marketing, je
  n’ai pas accès à cette information
 Cette information est conservée par jour sur
  les 12 derniers mois, par semaine sur les 24
  mois antérieurs, par mois ensuite
 Je peux l’exporter sous excel
Reste à faire du Sprint
280




230

                                                              Idéal


                                                              Réel
180




130




 80




 30




      1   2   3   4   5   6   7   8   9   10   11   12   13   14      15   16
-20
Projections
400




300




200




100




  0




-100




-200

       moyenne des 3 pires sprints       moyennes des 3 dernièrs sprints
       moyenne des 3 meilleurs sprints   Suppr - Ajouts
Indicateurs d'avancement du projet
120




100




 80




 60




 40


                                    % Story Points

                                    % Valeur métier
 20




  0
      1   2    3    4     5    6    7            8
SUR LE PLATEAU DE SON PROJET, AVEC SON
                                COACH
Qu'est-ce  qui vous fait dire que
 votre projet marchera mieux s'il
 est fait en agile ?
Disons   que l'on pense arriver à
 faire seulement les 2/3 de ce que
 vous demandez. Qu'est-ce que
 l'on fait et qu'est-ce que l'on ne
 fait pas ?
L'équipe ne doit pas ne parler
 qu’au Scrum Master mais se
 parler.

Le Scrum Master n’affecte pas les
 tâches, l’équipe s’affecte les
 tâches.
Avec  votre management visuel je
 n'y vois rien. Trop de tâches. Des
 tâches répétant toujours le même
 pattern, sans information
 spécifique.
Le burndown est plat, vous êtes
 clairement en retard par rapport
 à ce que vous aviez prévu en
 début de sprint. Qu'est-ce que
 vous faites ?
Indépendamment de ce que nous
découvrons, nous comprenons et nous
croyons sincèrement que chacun a fait
du mieux qu'il pouvait, compte tenu de
ce qu'il savait à l'époque, de ses
compétences et de ses
prérogatives, des ressources
disponibles et de la situation du
moment.
(The Prime Directive, Norman Kerth)
Il ne se passe rien dans votre
  rétrospective, les problèmes
  racine ne sont pas évoqués, les
  tensions ne sont pas résolues.
On n’ajuste plus la qualité pour
 garantir le délai, le budget, le
 périmètre.

 On ajuste maintenant le
 périmètre pour garantir la
 qualité, le délai, le budget.
La confiance repose sur la
 transparence (annoncer les
 mauvaises nouvelles) et l'atteinte
 continuelle d'objectifs à court
 termes (annoncer les bonnes
 nouvelles)
LORS DE LA PRESENTATION DE SON RETOUR
                         D’EXPERIENCE
POUR FAIRE ÉMERGER L’ÉQUIPE

 Elle prend forme progressivement, au début
  on la guide beaucoup, ensuite elle devient
  autonome : s’effacer progressivement
 Leadership pour animer en entrainant plutôt
  que « command and control »
 Laisser trouver l’équipe, même si parfois cela
  semble plus lent.
QUAND L’ÉQUIPE A ÉMERGÉ

   L’équipe est autonome
     Responsable, prend les problèmes à bras le
      corps.
     Prend des initiatives
     Soudée, joue collectif.

 Il suffit alors de lui rappeler les enjeux et les
  contraintes, elle s’optimise pour tenir ses
  engagements
 Du coup j’ai senti une espèce de manque : à
  quoi je sers ?
A QUOI JE SERVAIS ?
 J’ai protégé l’équipe des interventions
  extérieures.
 J’ai protégé le périmètre de chaque itération.
 Une fois les problèmes identifiés, j’ai facilité leur
  résolution par les uns et les autres.
 J’ai notamment facilité les relations avec
  l’extérieur du projet et avec le management.
 J’ai enfin impulsé de l’énergie dans la
  transformation agile de l’équipe (et son
  maintien)
ET PUIS LE MÉTIER…
 La participation du métier n’est pas une
  conséquence de la méthode mais un pré-requis.
  Il faut donc l’impliquer, et c’est un effort continu.
  Participation au réunion, manipuler l’application
  au fil de l’eau, …
 Heureusement, nous tenions nos
  engagement, et nous démontrions. La confiance
  est la clef de la participation du métier, et de la
  possibilité d’avoir des arbitrages sereins.
 Et puis, si on « accepte le changement », on ne
  n’accepte pas tout tout le temps.
PAS DE TOUT REPOS

 Amélioration continue veut dire changement
  continu.
 Remise en question potentielle de tout (pas
  tout à la fois).
 Toujours aller de l’avant.

 Des idées parfois surprenantes.

 Des divergences d’opinion, des conflits
  naissants à résoudre.
ET…




      Oui, ca marche !
POUR ALLER PLUS LOIN
   Agile manifesto : http://agilemanifesto.org/iso/fr/
   Scrum Guide : http://www.scrum.org/scrumguides/

   Scrum : Le guide pratique de la méthode agile la plus populaire - 2ème édition –
    Claude Aubry. ISBN : 2100563203

   Gestion de projet agile – Veronique Messager Rota. ISBN: 2212127502

   Agile Project Management with Scrum - Ken Schwaber. ISBN:073561993X;

   Lean Software Development: An Agile Toolkit for Software Development
    Managers - Mary Poppendieck, Tom Poppendieck. ISBN:0321150783

   http://henrik-kniberg.developpez.com/livre/scrum-xp/

   Référentiel Agile : http://referentiel.institut-agile.fr/index_type.html
   http://www.aubryconseil.com/
   http://www.qualitystreet.fr/
RETURN ON TIME INVESTED



1 doigt = J’ai complêtement perdu mon temps.

2 doigts = Un peu mieux que 1 doigt

3 doigts = Je n’ai pas perdu mon temps mais j’aurais fait aussi bien
tout seul.

4 doigts = Un peu moins que 5 doigts

5 doigts = J’ai vraiment découvert et appris beaucoup de choses.
Scrum, Kanban, Lean

Objectifs : la promotion et la diffusion
des méthodes agiles dans la région
Rhône-Alpes par tous moyens de
communication et d’intervention :
conférence, séminaire, rencontre, accom
pagnement, consulting, formation.

                  http://www.clubagilerhonealpes.org
Des rendez-vous réguliers
Chaque printemps à Lyon       Chaque automne à Grenoble




 Agile Innovation
 une au printemps à Lyon et une à
 l’automne à Grenoble.


                          http://www.clubagilerhonealpes.org
Des rendez-vous réguliers
Et 1 session participative mensuelle à
Lyon
pour vous aider dans votre transition vers
                                       l'agilité
 • pratiquer l'agilité (pour tous les profils)
 • échanger sur les retours d'expériences




                      http://www.clubagilerhonealpes.org
POUR POURSUIVRE

   Email : pierre.fauvel@alcyonix.com

   Twitter : pierre_fauvel

   Blog : pierrefauvel.wordpress.com

Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilité

  • 1.
    PMI - Auvergne AGILITE: HISTOIRE D’UN CHEF DE PROJET QUI ADOPTE L’AGILITE
  • 2.
    Personnages Jacques Le directeur des études de l'entreprise Y Paul Un chef de projet informatique de l'entreprise Y Nicolas Un scrum master au sein de l’entreprise Z, ami de Paul Pierre Un coach agile L’équipe Les membres de l’équipe du projet X La Les chefs de projet de l’entreprise Y communauté
  • 3.
    DANS LE BUREAUDE JACQUES
  • 5.
    Les meilleures décisions sont L’IT et les équipes prises, les métier travaillent conceptions les main dans la main plus simples sont adoptées. Mon rêve pour l’avenir Le processus de Mes projets me développement rapportent un autorise une bénéfice plus tôt. quantité raisonnable de changements
  • 6.
    Motif du recoursà l'agilité French Scrum User Group 2011 Réduire les risques Accélérer le time to market Motiver les équipes de développement Intégrer les changements Améliorer la qualité 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
  • 7.
    Ancienneté de l'adoption French Scrum User Group 2011 Plus de 3 ans, 28% Moins de 1 ans, 34% Entre 1 ans et 3 ans, 38%
  • 8.
    Profondeur de l'adoption French Scrum User Group 2011 Ne sait pas, 18% Généralisée, 19% A titre En cours de expérimental, 15 généralisation, 22 % % Sur un projet pilote stratégique, 26%
  • 9.
    Impact constaté del'adoption de l'agilité French Scrum User Group 2009 Respect des budgets Fréquence des mises en production Ne sait pas Respect des délais Dégradation Pas de changement Augmenter la productivité Légère amélioration Satisfaction des utilisateurs Amélioration sensible Amélioration de la qualité 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
  • 10.
  • 11.
    Manifeste pour ledéveloppement Agile de logiciels 2001 Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu’une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L’adaptation au changement plus que le suivi d’un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
  • 12.
    Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.  Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.  Un logiciel opérationnel est la principale mesure d’avancement.
  • 13.
     Accueillez positivementles changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.  Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.  La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • 14.
     Réalisez lesprojets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites- leur confiance pour atteindre les objectifs fixés.  Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • 15.
     Une attentioncontinue à l'excellence technique et à une bonne conception renforce l’Agilité.  La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.  Les meilleures architectures, spécifications et conceptions émergent d'équipes auto- organisées.  À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
  • 16.
    AVEC NICOLAS, SURLE PLATEAU DE SON PROJET
  • 18.
    LES RÔLES DANSSCRUM http://emmanuelchenu.blogspot.com/
  • 19.
    LES RITUELS &ARTEFACTS SCRUM Daily Meeting Sprint Planning Meeting Rétrospecti Démo ve
  • 20.
    LES ACTIVITÉS DESITÉRATIONS SE CHEVAUCHENT Version N-1 Acceptance au fil de l’eau Construction Correction des defects Version N Acceptance au fil de Préparation des l’eau Construction Correction des user stories defects Version N+1 Préparation des user Construction stories Itération N -1 Itération N Itération N+1
  • 21.
    USER STORIES  En tant que responsable marketing  Je peux avoir une vue sur l’origine des connections au site  Afin de mieux cibler mes campagnes de publicité
  • 22.
    DÉCOUPAGE EN USERSTORIES Un découpage vertical, de bout en bout  I(ndependant)  N(egociable)  V(aluable)  E(stimatable)  S(mall)  T(estable) + Des user stories homogènes en terme de priorité
  • 23.
    CRITÈRES D’ACCEPTANCE  Sije suis responsable marketing, j’ai accès à l’origine des connections (pays, entreprise, CSP)  Si je ne suis pas responsable marketing, je n’ai pas accès à cette information  Cette information est conservée par jour sur les 12 derniers mois, par semaine sur les 24 mois antérieurs, par mois ensuite  Je peux l’exporter sous excel
  • 24.
    Reste à fairedu Sprint 280 230 Idéal Réel 180 130 80 30 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 -20
  • 25.
    Projections 400 300 200 100 0 -100 -200 moyenne des 3 pires sprints moyennes des 3 dernièrs sprints moyenne des 3 meilleurs sprints Suppr - Ajouts
  • 26.
    Indicateurs d'avancement duprojet 120 100 80 60 40 % Story Points % Valeur métier 20 0 1 2 3 4 5 6 7 8
  • 27.
    SUR LE PLATEAUDE SON PROJET, AVEC SON COACH
  • 28.
    Qu'est-ce quivous fait dire que votre projet marchera mieux s'il est fait en agile ?
  • 29.
    Disons que l'on pense arriver à faire seulement les 2/3 de ce que vous demandez. Qu'est-ce que l'on fait et qu'est-ce que l'on ne fait pas ?
  • 30.
    L'équipe ne doitpas ne parler qu’au Scrum Master mais se parler. Le Scrum Master n’affecte pas les tâches, l’équipe s’affecte les tâches.
  • 31.
    Avec votremanagement visuel je n'y vois rien. Trop de tâches. Des tâches répétant toujours le même pattern, sans information spécifique.
  • 32.
    Le burndown estplat, vous êtes clairement en retard par rapport à ce que vous aviez prévu en début de sprint. Qu'est-ce que vous faites ?
  • 33.
    Indépendamment de ceque nous découvrons, nous comprenons et nous croyons sincèrement que chacun a fait du mieux qu'il pouvait, compte tenu de ce qu'il savait à l'époque, de ses compétences et de ses prérogatives, des ressources disponibles et de la situation du moment. (The Prime Directive, Norman Kerth)
  • 34.
    Il ne sepasse rien dans votre rétrospective, les problèmes racine ne sont pas évoqués, les tensions ne sont pas résolues.
  • 35.
    On n’ajuste plusla qualité pour garantir le délai, le budget, le périmètre. On ajuste maintenant le périmètre pour garantir la qualité, le délai, le budget.
  • 36.
    La confiance reposesur la transparence (annoncer les mauvaises nouvelles) et l'atteinte continuelle d'objectifs à court termes (annoncer les bonnes nouvelles)
  • 37.
    LORS DE LAPRESENTATION DE SON RETOUR D’EXPERIENCE
  • 38.
    POUR FAIRE ÉMERGERL’ÉQUIPE  Elle prend forme progressivement, au début on la guide beaucoup, ensuite elle devient autonome : s’effacer progressivement  Leadership pour animer en entrainant plutôt que « command and control »  Laisser trouver l’équipe, même si parfois cela semble plus lent.
  • 39.
    QUAND L’ÉQUIPE AÉMERGÉ  L’équipe est autonome  Responsable, prend les problèmes à bras le corps.  Prend des initiatives  Soudée, joue collectif.  Il suffit alors de lui rappeler les enjeux et les contraintes, elle s’optimise pour tenir ses engagements  Du coup j’ai senti une espèce de manque : à quoi je sers ?
  • 40.
    A QUOI JESERVAIS ?  J’ai protégé l’équipe des interventions extérieures.  J’ai protégé le périmètre de chaque itération.  Une fois les problèmes identifiés, j’ai facilité leur résolution par les uns et les autres.  J’ai notamment facilité les relations avec l’extérieur du projet et avec le management.  J’ai enfin impulsé de l’énergie dans la transformation agile de l’équipe (et son maintien)
  • 41.
    ET PUIS LEMÉTIER…  La participation du métier n’est pas une conséquence de la méthode mais un pré-requis. Il faut donc l’impliquer, et c’est un effort continu. Participation au réunion, manipuler l’application au fil de l’eau, …  Heureusement, nous tenions nos engagement, et nous démontrions. La confiance est la clef de la participation du métier, et de la possibilité d’avoir des arbitrages sereins.  Et puis, si on « accepte le changement », on ne n’accepte pas tout tout le temps.
  • 42.
    PAS DE TOUTREPOS  Amélioration continue veut dire changement continu.  Remise en question potentielle de tout (pas tout à la fois).  Toujours aller de l’avant.  Des idées parfois surprenantes.  Des divergences d’opinion, des conflits naissants à résoudre.
  • 43.
    ET… Oui, ca marche !
  • 44.
    POUR ALLER PLUSLOIN  Agile manifesto : http://agilemanifesto.org/iso/fr/  Scrum Guide : http://www.scrum.org/scrumguides/  Scrum : Le guide pratique de la méthode agile la plus populaire - 2ème édition – Claude Aubry. ISBN : 2100563203  Gestion de projet agile – Veronique Messager Rota. ISBN: 2212127502  Agile Project Management with Scrum - Ken Schwaber. ISBN:073561993X;  Lean Software Development: An Agile Toolkit for Software Development Managers - Mary Poppendieck, Tom Poppendieck. ISBN:0321150783  http://henrik-kniberg.developpez.com/livre/scrum-xp/  Référentiel Agile : http://referentiel.institut-agile.fr/index_type.html  http://www.aubryconseil.com/  http://www.qualitystreet.fr/
  • 46.
    RETURN ON TIMEINVESTED 1 doigt = J’ai complêtement perdu mon temps. 2 doigts = Un peu mieux que 1 doigt 3 doigts = Je n’ai pas perdu mon temps mais j’aurais fait aussi bien tout seul. 4 doigts = Un peu moins que 5 doigts 5 doigts = J’ai vraiment découvert et appris beaucoup de choses.
  • 47.
    Scrum, Kanban, Lean Objectifs: la promotion et la diffusion des méthodes agiles dans la région Rhône-Alpes par tous moyens de communication et d’intervention : conférence, séminaire, rencontre, accom pagnement, consulting, formation. http://www.clubagilerhonealpes.org
  • 48.
    Des rendez-vous réguliers Chaqueprintemps à Lyon Chaque automne à Grenoble Agile Innovation une au printemps à Lyon et une à l’automne à Grenoble. http://www.clubagilerhonealpes.org
  • 49.
    Des rendez-vous réguliers Et1 session participative mensuelle à Lyon pour vous aider dans votre transition vers l'agilité • pratiquer l'agilité (pour tous les profils) • échanger sur les retours d'expériences http://www.clubagilerhonealpes.org
  • 50.
    POUR POURSUIVRE  Email : pierre.fauvel@alcyonix.com  Twitter : pierre_fauvel  Blog : pierrefauvel.wordpress.com