Jouons avec l’agilité Partie 1

Sommaire Qu’est-ce que l’agilité Ball point game Chiffrages et poker planning

1. Introduction Les notions de base

Faiblesses de cycles classiques Définition du périmètre complexe Peu claire Incomplète Changeante Augmentation des conflits Effet tunnel Peu de visibilité client Manque de confiance et de collaboration Time to market élevé Faible qualité

Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey) Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995)

Réponse Agile Effet tunnel ➔ Cycles courts et validation continue Définition du périmètre complexe ➔ Adaptation au changement Faible qualité ➔ Fail Fast Augmentation des conflits ➔ Echanges réguliers avec le client

Scrum Une méthode empirique : basée sur l’expérience Un cadre de travail Simple à comprendre Dur à maitriser Prévu pour des réalisations complexes

Sprint Le sprint est une phase de réalisation Chaque Sprint apporte un incrément au produit Leur durée est fixe (1 mois max) Tous les Sprints aboutissent à une production : Fail Fast - Réaliser quelque chose de testable à chaque sprint -Même un échec apprend quelque chose 3 rendez vous importants : Sprint planning Daily Scrum Sprint review + Rétrospective (Après le sprint)

Ball Point Game

Règles du jeu Faire transiter le plus de balles entre tous les membres de votre équipe Chaque itération dure 2mn. Avant chaque tentative donner une estimation du nombre de balles Après chaque tentative, 1mn de débrief pour améliorer votre score Les règles: la balle ne doit pas être passée au joueur le plus proche de vous la balle doit absolument être lancée, et NE PAS TOMBER la personne qui effectue le premier lancer doit être celle qui place la balle dans le sac les autres membres touchent une seule fois la balle

Après quelques essais les scores se stabilisent : c’est la vélocité Que s’est il passé ? Les questions du debrief A la fin du jeu naturellement on debrief. Que s’est-il passé ? Quelle a été votre meilleure itération ? L’amélioration est venue de quoi? On a travaillé plus dur ? plus vite ? L’auto-organisation de l’équipe a-t-elle bien fonctionnée ? D’où est venule "leadership" ? avec quel style ? Application chez vous ? Autres thèmes : Vélocité naturelle, inspection & adaptation (amélioration continue), théorie des contraintes, sécuriser l’échec, éliminer le gaspillage, "pull & push", protection de l’itération, héros ?, équipe & leadership, planification & estimation, etc. Les apprentissages et les observations On parle de système : on observera une performance dépendante du système et non "des individualités", ou d’une volonté d’aller plus vite, plus fort. C’est en changeant le système que la performance change. On peut aller plus vite ou plus fort, on peut devenir expert d’un système mais celui-ci a des limites assez rapidement. Ainsi le "héros" n’a qu’un impact limité. C’est plutôt au maillon faible qu’il faut faire attention. En rapport avec la théorie des contraintes de Goldratt : cherchez à d’abord régler le plus gros problème du système, pas tous à la fois car les autres problèmes se remodèleront suite à la résolution du principal. Les estimations initiales sont souvent catastrophiques (dans un sens comme dans l’autre : trop bas, trop haut). Surtout la première (qui me permet de replacer ma citation fétiche : "aucun plan ne survit au premier contact avec l’ennemi" —Von Moltke). Mais peu à peu la vélocité, la performance liée au système mis en place est rendue visible. Comme les équipes réussissent à améliorer ce système on observe ainsi facilement des scores en 5 itérations allant de 0 à la première itération à 60 à la cinquième. Bel écart qu’il faudra noter. Quand on observera une performance qui se stabilisera on pourra planifier (normalement cela oscille autour de 3 itérations si le système ne change pas trop). Ces améliorations viennent de la pratique et d’une phase d’introspection vouée à l’amélioration. Cette amélioration est possible car on opère par cycle court : 2mn, 5 fois. Et que l’erreur, nécessaire à l’expérimentation elle même nécessaire à l’amélioration, est d’autant plus acceptée que le cycle est court car ainsi l’échec n’est pas un drame. On observera comment cette introspection et ces axes d’amélioration sont discutés au sein de l’équipe (leadership naturel, accord partagé de type "decider" de Jim McCarthy, etc.) : c’est généralement une bonne mise en pratique de l’auto-organisation (vraiment pas si dur) et d’où émerge une intelligence collective. Vous observerez malheureusement la résistance des gens à vouloir changer un système ("on pourrait se rapprocher…"), vous observerez la crainte à transgresser des règles qui n’existent pas ("on peut lancer plusieurs balles dans la système à la fois ???"), à penser différemment ("j’ai le droit d’accrocher ce sac à mon cou ?"), etc. C’est la mémoire du muscle… Vous observerez pourquoi le management aime tant Scrum : cette capacité à se mettre à fond, en sprint, dans la réalisation, et vous interrogerez vos équipes sur un rythme soutenable. C’est généralement rarement le cas spontanément. Que ce serait il passé si on avait fait un seul sprint de 15 minutes avec 3 minutes de préparation? Après quelques essais les scores se stabilisent : c’est la vélocité

Que va-t-on faire ce mois ci? 3. Sprint Planning Que va-t-on faire ce mois ci?

Première action du sprint Time box: Une Journée Matin : Présentation des Items Le Product owner vient présenter les items et leur priorité Il décrit en détail leur contenu et leur ‘Definition of done’ Après midi : Poker Planning L’équipe estime le coût de chaque item On sélectionne autant d’item que le permet la vélocité de l’équipe L’équipe présente le sprint backlog et s’engage sur la réalisation de celui ci

Poker Planning Réalisation d’estimations Engagement de l’equipe de developpement Expression de chaque acteur Estimation relative entre items Ajustement eventuel de la vélocité

Poker Planning Acteurs autour d’une table ronde Product Owner explique la Story Echange de questions/réponses entre developpeurs et product owner Vote de chaque developpeur via un jeu de Poker Planning (carte, site web…) Révélation des votes En cas de difference, discussions jusqu’au consensus En cas d’accord, passage à la story suivante Site utilisé par le projet Assurance : https://www.pointingpoker.com

Points Important Le PO a la décision finale L’équipe s’engage sur le backlog Ne pas utiliser des jours/hommes

Poker planning

Merci! Des questions? Nous retrouver: Lync, Yammer, github http://goo.gl/forms/nLESl0gjRo

Credits Special thanks to all the people who made and released these awesome resources for free: Presentation template by SlidesCarnival Photographs by Unsplash Backgrounds by Pixeden