Il était une fois, un Consultant Agile Xebia à qui l’on avait donné pour mission d’accompagner la transformation Agile de l’ensemble des acteurs d’un projet IT, du Product Owner à l’équipe de Recette, en passant par l’équipe de développement.
Tout lien avec des personnes ou projets ayant existé n’est absolument pas fortuit, car cette histoire est celle que je vis actuellement au sein d’un grand groupe, dans le cadre d’une transformation Agile à grande échelle.
Je vous propose de partager avec vous cette aventure, au travers d’une série de billets décrivant toutes les étapes de la mise en œuvre d’un projet IT, associant le cadre Scrum aux pratiques Kanban.
Au début de chaque billet, je rappellerai le contexte du projet, ainsi qu’un rapide résumé des épisodes précédents :
- Le projet : Evolution d’une application IT existante, ayant pour objectif l’intégration d’une nouvelle gamme de produit
- L’équipe Agile :
- Un Product Owner et un Proxy Product Owner basés en région Parisienne
- Une équipe de développement, dont un ScrumMaster basé en Province
- Une personne en charge des tests et de la Recette, basée en Province
- Une ergonome basée en Province.
- Le Plan de Release : 5 Itérations de 3 semaines chacune
- Méthodes Agiles mises en oeuvre : Cadre Scrum (rôles, cérémonials) associé aux pratiques de gestion de flux et d’amélioration continue Kanban.
Le Story Mapping
30 Mai 2013 : Notre histoire commence, j’aurais tendance à dire comme il se doit dans un projet Agile, par une séance de Story Mapping. Le Story Mapping, introduit par Jeff Patton, est un élément essentiel dans l’étape de préparation du Release Planning d’un projet Agile. Il permet d’identifier les Macro-Fonctionnalités (communément appelées Features) que le Métier, représenté par le Product Owner, souhaite voir développées. À partir des Features identifiées, le Product Owner isole les Minimal Marketable Features (MMF) représentant les fonctionnalités minimales et prioritaires à réaliser dans la Release.
Le principe de mise en oeuvre d’un Story Mapping est assez simple (enfin, en théorie 
) :
- Trouver un mur, des post-it de différentes couleurs, des feutres, un Product Owner et toute personne pouvant apporter les informations nécessaires à la bonne compréhension du besoin ;
- Identifier toutes les activités de votre produit et les afficher au mur afin de rendre l’exercice visuel, sous la forme d’une cinématique d’activités ;
- Définir les acteurs impactés par le produit. On parle souvent de Personas, représentant un utilisateur fictif au travers duquel nous pourrons mieux appréhender les besoins ;
- Pour un persona, définir sous chaque activité les Features ou Epic à réaliser ;
- Isolez Les Features représentant le MMF à réaliser dans la première Release.
Je ne rentrerai pas dans le détail de la réalisation d’un Story Mapping, de nombreux blogs décrivent cela d’une meilleure façon que moi.
Pour ce qui est du projet qui nous concerne, voici le résultat du Story Mapping :
Nous avons donc identifié 2 Releases. Notre histoire portera sur la Release 1.
Pour information, cette séance de Story Mapping a duré environ 3 heures et a été suivie par un atelier de validation avec le Métier de 2 heures, le 05 juin 2013.
Le Kanban des PO (Product Owner)
07 Juin 2013 : Le MMF de la Release 1 ayant été identifié, via notre Story Mapping, les travaux d’écriture des Users Stories peuvent commencer….enfin non, pas encore. Nous devons d’abord identifier les flux d’activités à réaliser, afin de mettre en place notre Kanban à destination des PO.
En accord avec Le PO et le Proxy PO, nous identifions les flux d’activités suivants :
|
|
|---|
Après réflexion, nous décidons de ne pas retenir l’activité « Ready » et de la remplacer par la Roadmap des Itérations, contenant les activités suivantes :
- Planifié
- En cours
- Fini
Pour chaque activité, en dehors des Itérations, nous définissons 2 états : En cours et Fini. Dernière étape, mettre une limite basse et/ou haute sur chacune des activités ou chacun des états. Comment je sais quelle limite appliquer sur chaque colonne ? … et bien je n’en ai aucune idée. Nous partons sur une hypothèse basée sur le nombre d’intervenants (Product Owner, Proxy Product Owner, Recetteur) et leur disponibilité.
Voici donc le résultat de notre Kanban :
Les chiffres entre parenthèses représentent la limite basse appliquée à une activité (Critères d’Acceptation) ou à un état (Estimer – Fini). Les autres chiffres représentent la limite haute. Le principe des limites basses et hautes permet de réguler le travail des différents acteurs du projet, en fonction de leur capacité à faire. Ce principe est également un élément primordial dans la mise en oeuvre d’un Kanban en système « Tiré » (Pull) ou ce sont les activités les plus à droite qui « Tirent » de nouvelles cartes dès que leur limite le permet. Par exemple sur l’image du Kanban des PO, aucune carte ne peut passer de « Critères Acceptation » vers « Comportements », car la limite de 5 est atteinte. Lorsque la personne en charge de l’écriture des comportements aura terminé une carte, celle-ci se tire vers la colonne « Fini », dont la limite n’est pas atteinte, et elle pourra ensuite tirer une nouvelle carte de la colonne « Critères Acceptation ».
Voici comment les limites ont été définies sur notre Kanban :
- Critères d’Acceptation => Application d’une limite basse de 2 cartes sur un PO et un Proxy PO. Vous remarquerez qu’aucune limite haute n’a été affectée à cette activité et qu’un goulet d’étranglement est en train de se constituer. Cela n’est pas gênant pour le moment (enfin j’espère), nous souhaitons avant tout commencer à alimenter le pipe en démarrage de Release.
- Comportements => Une limite haute de 5 cartes a été appliquée. Cette limite se base sur l’intervention d’une Recetteuse et d’un Proxy PO, soit (2*2) + 1
- Estimer => Application d’une limite basse de 3 cartes, ayant pour objectif d’assurer une alimentation de l’équipe de développement, actuellement composée de 2 développeurs et d’un Scrum Master.
- Sprint 1 => L’équipe est composée de 2 développeurs et d’un Scrum Maste nous appliquons une limite basse de 2 cartes (2 développeurs) et une limite haute de 5 cartes ((2 développeurs *2)+1).
À ce Kanban s’ajoute la Definition of Done, sur chacune des activités, définissant les conditions pour qu’une carte soit considérée comme « Finie » au sein de l’activité et donc éligible à être « Tirée » par l’activité suivante (si la limite haute le permet ou la limite basse l’exige).
Chaque carte est représentée par un code couleur (Jaune : User Story ; Vert : Technical Story ; Orange : Impediment – À l’exception des cartes de la colonne « Proposer » qui correspondent aux activités du Story Mapping) et par les informations suivantes :
- Un identifiant unique ;
- La description de la Story ou de l’impediment ;
- La date d’entrée dans la cinématique d’activités, c’est-à-dire dès l’entrée dans la colonne « Accepter » ;
- La date d’entrée en phase de réalisation, c’est-à-dire dès l’entrée dans la colonne « En cours » d’une Itération ;
- La date de sortie de la cinématique, c’est-à-dire dès l’entrée dans la colonne « Fini » d’une Itération ;
Les dates d’entrée et de sortie nous permettront, par la suite, de mesurer le Lead Time et le Cycle Time de vie de nos cartes. Je reviendrai sur ce sujet dans le billet consacré aux mesures et indicateurs.
Comme vous pouvez le constater, notre Kanban des PO contient également les 5 prochaines Itérations de notre Release et permet ainsi aux PO une visibilité sur l’Itération en cours, ainsi que sur la planification des cartes dans les autres Itérations.
Ce Kanban, bien que représentant notre flux d’activités, n’est pas complet et doit être associé à d’autres éléments, dont :
- Un tableau de suivi des actions et des obstacles
- Les indicateurs de suivi de la Release
- Le calendrier des PO, permettant de suivre le temps passé dans les différentes réunions, par semaine.
- Le Release Planning
| Tableau des Obstacles/Actions | Indicateurs/Calendrier PO |
|---|---|
|
|
Concernant le Kanban des Obstacles/Actions, vous pouvez constater qu’aucune limite n’a été fixée sur le WIP, mais alors « ce n’est pas un Kanban !!! » me direz-vous ? Et bien en fait si, sauf qu’ici ce qui est important ce n’est pas tant une limite du nombre de cartes qu’une résolution rapide des obstacles. C’est pour cela que nous avons remplacé la limite en nombre par une date limite de résolution de l’obstacle ou de l’action. Nous suivons également le temps de passage d’une résolution.
Nous reviendrons plus en détail sur chacun de ces éléments dans un prochain épisode.
Le Kanban de l’équipe de Développement et de Test
12 Juin 2013 : 10 jours après notre Story Mapping, a lieu le Sprint Planning 1, en présence du PO, du Proxy PO et de l’équipe Agile, qui je le rappelle est localisée en Province. Les Stories à réaliser dans cette première Itération sont présentées à l’équipe Agile, qui procède à une estimation de l’effort à fournir, basé sur une règle simple : Seules les Stories ayant un poids de 5 maximum sont éligibles à l’Itération.
À ce stade de l’histoire, si vous avez bien suivi la description du flux d’activités du Kanban des PO, vous allez me dire « Mais s’il y a une activité Estimer, pourquoi un Sprint Planning avec une estimation de l’effort des Stories ? » Eh oui, pas très logique tout cela. La raison est simple : nous sommes sur une phase de lancement où l’ensemble des Stories à réaliser sur l’Itération 1 n’a pas pu être estimé en avance de phase. Dans la suite, l’estimation sera effectuée selon un flux continu, tenant compte des limites, et alimentera « Juste à Temps » l’Itération.
Mais revenons à notre équipe Agile. La distance avec le Kanban des PO rend indispensable la mise en place d’un Kanban de suivi des activités de l’Itération. Ce Kanban est constitué des éléments suivants :
- L’objectif de L’Itération, ainsi que les dates des cérémonies
- Le flux d’activités dans l’Itération, avec les limites basses et hautes :
- Backlog d’Itération
- Développement (En cours ; Fini) => Limite basse de 2 cartes ; Limite haute de 5 cartes
- Test => Limite haute de 5 cartes. L’objectif de cette limite haute est que lorsqu’elle est atteinte, l’équipe de développement arrête ses travaux de coding et assiste la personne en charge de la Recette dans le passage des BDD et dans la correction des anomalies identifiées. Cette activité est limitée dans le temps, à 30 minutes. Au-delà, l’équipe de développement reprend ses travaux et les anomalies non corrigées font l’objet d’une carte Impediment entrant dans le Backlog d’Itération et à corriger d’ici la fin de l’Itération.
- Fini
- La Definition of Done permettant de définir les pré-requis pour qu’une carte soit considérée comme « Done » à l’issue des développements et « Done » à l’issue de la phase de tests.
- Le tableau de suivi des obstacles
- Le tableau de suivi des actions
- Le calendrier de l’équipe, permettant de mesurer, par semaine, le temps passé dans les différentes réunions et impactant leur capacité à faire sur l’Itération.
- L’identification de l’équipe, via leurs avatars.
|
|
|---|
Le Daily Meeting quotidien permet une synchronisation entre le Kanban de l’équipe Agile et celui des PO, ainsi que la mise à jour des mesures et indicateurs que nous verrons dans le prochain billet.
Conclusion
- Le Story Mapping nous a permis de prioriser le besoin du Métier, défini lors de l’atelier de vision.
- Nous avons identifié le MMF à réaliser et notre Plan de Release, nous permettant de planifier nos travaux.
- Nous avons mis en place un Système Kanban, nous permettant de suivre tout le cycle de vie des Cartes représentant les éléments fonctionnels, techniques, mais également les anomalies, à réaliser sur notre projet et cela au travers de l’identification des activités de notre flux.
- Nous avons appliqué des limites (basses et hautes) sur chacune des activités, afin de permettre une alimentation en continu des équipes de développements et de tests, tout en évitant les goulets d’étranglement et les baisses d’activité (en tout cas c’est l’objectif
![wink]()
). - Enfin, nous commençons à prendre des mesures sur notre flux d’activité, mais ça, ce sera l’objet d’un prochain billet.
- Pour résumer, voici un petit schéma synthétique de notre activité :
