Agile smells – Management visuel

Dans cette série d’articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d’horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Commençons par le management visuel…

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

• Agile smells – Sprint planning
• Agile smells – Sprint daily stand-up meeting
• Agile smells – Sprint review
• Agile smells – Sprint retrospective
• Agile smells – Backlog et user stories
• Agile smells – Pratiques de développement et de test
• Agile smells – Rôles et motivation

« J’aime les monochromes de Whiteman »

La situation

La première chose que je regarde lorsque je rentre dans le bureau d’une équipe agile, ce sont les murs. Ce lieu, champs de bataille de nos post-it préférés, est parfois étrangement délaissé par certaines équipes. Si vous n’utilisez vos murs que pour exhiber les affiches de vos films préférés ou les publicités de votre société alors il y a certainement une légère odeur dans votre bureau…

Pourquoi ça sent mauvais ?

Trois principales causes peuvent expliquer cette situation :

• Pression externe

Une personne externe à l’équipe avec une capacité de décision forte est un peu trop présente, elle vient régulièrement mettre un coup de pression à l’équipe en grimaçant devant le burndown chart, ou simplement vient chercher des coupables lors de situations de crise. Pour se protéger, l’équipe a alors le réflexe d’afficher moins d’information.

• Pas de vision produit

Lorsque l’équipe n’a pas de vision du travail à effectuer au-delà de deux semaines, il lui est difficile d’anticiper les risques ou de prendre des actions d’amélioration. Sans une vision long terme, le travail n’a plus vraiment de sens et la motivation en est grandement affectée. Dans la plupart des cas, l’équipe se contentera alors de tenir à jour le taskboard de l’itération en cours.

• Le tout numérique

Si l’on met de côté le cas des équipes non co-localisées, le choix du tout numérique, bien que parfois apprécié, n’est pas idéal dans la majorité des contextes. Via un assemblage d’outils, il est impossible de voir en un coup d’oeil l’état d’avancement sur le court, moyen et long terme, de capter les ressentis, de savoir quels sont les risques levés ou encore les plans pour s’améliorer.

Concrètement on fait quoi ?

Bon nombre de problèmes que l’on tente d’éviter se résolvent naturellement quand on agit en totale transparence au quotidien. Le visuel doit être là pour vous aider mais aussi pour faire ressortir les manquements et les améliorations qu’il vous reste encore à accomplir.

Voici selon mon expérience les éléments indispensables d’un bon management visuel :

• Le Taskboard : Suivre le travail quotidien et donc avoir une vision à très court terme. C’est assurément celui que l’on retrouve dans la majorité des équipes agiles. Petit conseil : ajoutez des photos ou avatar des personnes en face des tâches qu’ils effectuent. Cela rend le taskboard davantage vivant, et sur les projets avec plusieurs feature teams, la photo avec prénom est utile pour connaître les gens.

• La Story Map : Donner une vision produit à moyen ou long terme. Sert de base au travail du Product Owner.

• Les Definition of Ready (DoR) et Definition of Done (DoD) : Afficher les règles du jeu clairement et s’y référer lorsque quelqu’un essaie de s’en détourner.

• Le Burndown chart de la Release : Donner une vision d’avancement sur le moyen terme.

• Les éléments prêts à être pris en compte par l’équipe : Donner une vision à court terme. Evidemment lié au DoR, ceci est le minimum pour savoir quels sont les prochains éléments prêts à être développés.

• La dette technique : Mettre en évidence les sujets techniques qui entraînent un coût supplémentaire dans le développement des fonctionnalités. Pratique si quelqu’un s’étonne des temps d’implémentation en augmentation.

• Les risques : Afficher clairement les risques qui peuvent mettre en péril n’importe quel aspect du projet. Comme la dette technique, ils doivent vous servir de support pour être pédagogue vis-à-vis des pressions externes.

• Le résultat de la dernière rétrospective : Afficher ce qu’il s’est dit et les actions qui en sont ressorties. C’est le meilleur moyen d’être totalement transparent sur la vie de l’équipe.

Vous avez des idées supplémentaires ? Expérimentez-les ! N’oubliez pas cependant que chaque élément composant votre management visuel doit être le plus épuré possible.

« Le taskboard et JIRA ne sont pas synchro, je dois croire lequel ? »

La situation

L’équipe dispose de deux taskboards : un physique et un numérique. Lors des stand-up, l’équipe se place devant le taskboard physique et le met à jour. C’est celui qui sert de support pour n’importe quelle discussion d’équipe. La version numérique, qui est identique à la version physique en terme de colonne, est mise à jour n’importe quand dans la journée. Elle est utilisée par l’équipe pour voir le détail des stories (critères d’acceptation, exemples) et par le Scrum Master pour suivre les métriques (vélocité, burndown chart). Régulièrement, les deux taskboards sont désynchronisés.

Pourquoi ça sent mauvais ?

Avoir un outillage numérique qui reprend des informations du management visuel n’est pas un smell en soi. C’est même assez courant, car le taskboard physique a des limites en termes de nombre d’informations qu’il peut apporter. Leur mise à jour en revanche est vécue la plupart du temps comme un travail administratif par l’équipe. La cérémonie du stand-up permet de rendre cette mise à jour plus vivante en la ramenant comme simple support d’une annonce faite à l’équipe entière. La mise à jour de la version numérique par contre, est celle qui est le plus souvent oubliée, tout simplement car elle ne sert à rien pour les membres de l’équipe. Du moins pas directement…

Concrètement on fait quoi ?

Le contexte est évidemment important, on ne gère pas un projet de trois personnes de la même manière qu’un projet de quatre-vingts personnes réparties en feature team. Pourtant, le recours à un outillage numérique est systématique mais pas forcément adapté pour la grande majorité des cas.

Il faut donc se questionner sur les intentions de chacun des deux taskboards. Dans la plupart des équipes, cela devrait être :

• Taskboard physique : donne la visibilité du travail sur lequel l’équipe est focalisée. Sa mise à jour est du ressort des membres de l’équipe lors du stand-up meeting par exemple.

• Taskboard numérique : donne accès au détail des items de travail et génère des métriques d’itération et de release. Sa mise à jour doit être du ressort des Product Owner et Scrum Master uniquement.

Mais nous pourrions aller un peu plus loin en estimant finalement que le taskboard numérique pourrait tout simplement être abandonné au regard de sa plus-value par rapport à son prix. Voici quelques raisons :

• le détail des items : s’il s’agit uniquement d’écrire des critères d’acceptation ou des exemples, un outil comme Excel peut être suffisant.

• les métriques : la plupart des outils (si ce n’est tous) ne sont pas optimaux sur la génération de graphe. Au moindre changement non prévu, l’outil est vite dépassé. C’est pourquoi d’ailleurs, énormément de Scrum Master reprennent manuellement les données pour générer leurs propres graphiques.

• Gestion des releases : une story map bien établie doit amplement suffire au suivi des releases et des mises en production.

• Suivi des épics : Lorsqu’il y a un vrai suivi des épics et que celle-ci sont découpées en nombreuses stories, un outillage adapté peut se justifier. Cependant bon nombre de projets n’ont pas ces problématiques et une story map peut une nouvelle fois être suffisante.

« Et si on ajoutait une autre colonne au taskboard ? »

La situation

L’équipe a un taskboard Scrum de 7 colonnes. On y retrouve : « A faire », « En cours », « A reviewer », « A tester », « A déployer », « A valider », « Terminé ».

Pourquoi ça sent mauvais ?

Dans la grande majorité des cas, l’ajout d’une colonne dans le taskboard s’apparente surtout à une fausse bonne idée. La nouvelle colonne va servir à cacher des problèmes d’organisation en devenant la plupart du temps une file d’attente et en autorisant les développeurs au travail en parallèle.

Revoyons chacunes des colonnes de notre situation :

• « A reviewer » : marquer l’étape de revue de code signifie qu’il n’y a clairement pas de pair programming et qu’une revue de code ne se fait jamais sur demande. Les personnes ne sont donc pas intéressées dans l’apport d’une aide à un coéquipier.

• « A tester » : les tests sont totalement décorrélés du développement puisqu’ils sont effectués une fois l’implémentation terminée. Le développement d’une story semble donc suivre le schéma d’un cycle en V, qui plus est si une personne différente est dédiée à la réalisation des tests. S’il y a des manquements graves détectés dans cette phase, la story va certainement revenir en arrière dans la colonne « En cours ».

• « A déployer » : le déploiement d’un composant sur un environnement est fastidieux. Cela nécessite l’intervention d’une personne pour une durée non négligeable.

• « A valider » : ici intervient le Product Owner. Comme il n’est pas toujours disponible, les stories s’amassent dans cette colonne en attendant qu’il puisse se libérer. Comme pour les tests, si des manquements sont constatés, la story va revenir dans la colonne « En cours » et va devoir reprendre tout le processus avant d’atterrir de nouvau dans « A valider ».

En résumé, les stories se baladent continuellement de gauche à droite et inversement, les développeurs ne sont pas encouragés à trouver des solutions pour amener le plus rapidement possible la story vers le « Terminé ». Chaque passage de story dans la colonne qui suit va leur permettre de démarrer une nouvelle story étant donné que la nouvelle colonne n’est pas de leur ressort. La résultante est une équipe composée uniquement d’individualités et un WIP (Work In Progress) trop élevé.

Concrètement on fait quoi ?

Rester simple en se contentant des colonnes « A faire », « En cours » et « Terminé », doit suffire à répondre aux besoins de 99% des équipes.

Si vous souhaitez marquer ce genre d’étape, un post-it comme tâche de la story doit suffire. De plus, les développeurs qui prennent en charge une story ne doivent pas pouvoir changer de story tant qu’elle n’est pas terminée. Les ralentisseurs, s’ils existent toujours, seront alors vraiment ressentis et pourront donner lieu à de vraies améliorations comme :

• définir des user stories propices au pair programming en amont de l’itération. Pour les autres, étant donné que les développeurs ne peuvent pas changer de story, cela les forcera à harceler leurs camarades pour qu’ils se libèrent le temps de la revue de code. En dehors d’un bug urgent de production, les membres de l’équipe devraient prioriser la revue de code plus qu’une tâche de développement (la revue de code signifiant qu’une user story est plus proche du « terminé » et donc qu’une partie des objectifs de l’itération sera plus rapidement atteinte).

• Mettre en place des pratiques comme le TDD, l’ATDD ou le BDD, avec ou sans un rôle dédié de testeur, qui rendront l’écriture des tests et de l’implémentation complémentaires.

• Automatiser certains traitements manuels et mettre en place des outils pour viser un déploiement simplifié sur un simple clic bouton.

• Améliorer la collaboration avec le PO tout au long de l’itération avec plusieurs créneaux de disponibilité chaque jour pour l’équipe.

Sur le même thème je vous invite à lire également l’article de Grégory Fontaine sur Scrum ou Kanban : Je hais les colonnes.

« Non mais on n’est jamais au courant de rien dans ce bureau ! »

La situation

L’équipe est répartie dans deux bureaux distincts. Le management visuel est installé dans un des deux bureaux.

Pourquoi ça sent mauvais ?

L’aspect géographique est très important pour une équipe agile. Parfois des espaces mal agencés peuvent empêcher de réunir dans un même bureau toute l’équipe. Il est alors étonnant de voir comment des frustrations et des problèmes de communication peuvent apparaître alors même que les deux bureaux sont en face l’un de l’autre.

Installer l’ensemble du management visuel dans un seul bureau aura pour conséquence d’indiquer à tout le monde que la vie de l’équipe se passe ici. La moindre activité, discussion ou prise de décision avec des éléments extérieurs se passera dans ce bureau, laissant une partie de l’équipe à l’écart.

Concrètement on fait quoi ?

Il n’y a pas de remède miracle. Essayer d’appeler toute l’équipe, dès qu’une conversation semble utile, est impossible. Faire un rapport de ce qu’il s’est dit est également une solution mais le nombre d’oublis devient important avec le temps.

Certaines frustrations seront impossibles à supprimer, par contre certaines actions concrètes peuvent aider :

• Répartir le management visuel sur l’ensemble des deux bureaux : par exemple, le taskboard dans un bureau et tout le reste dans l’autre. La somme des conversations sera mieux répartie sur l’ensemble des bureaux et enlèvera une partie des frustrations générées.
• Eviter également de rassembler des rôles clés de l’équipe dans le même bureau : un bureau avec Product Owner, Scrum Master et Leader technique réunis est évidemment une mauvaise idée même si cela paraît pratique.

Conclusion

Au travers de quatre situations, nous avons découvert comment le management visuel pouvait révéler des pratiques contre productives, mais également, comment il pouvait être une aide d’une grande efficacité pour améliorer de nombreux aspects de la vie d’une équipe. Ne jetez pas votre désodorisant tout de suite, nous revenons bientôt avec de nouveaux agile smells dédiés cette fois-ci au sprint planning meeting.