Press "Enter" to skip to content

Lecture : “96 Visualization Examples” par Jimmy Janlén

Lecture : “96 Visualization Examples” par Jimmy Janlén

Un petit livret plein de fantastiques conseils sur le management visuel d’une équipe Scrum ou Kanban !

Au détour d’un article LinkedIn j’ai découvert l’existence du livre 96 Visualization Examples de Jimmy Janlén, dans la collection Toolbox for the Agile Coach. Pour situer un peu, le livre est publié par Crisp, une boîte de consulting assez connue notamment pour l’accompagnement de Spotify, et dont Jimmy fait partie ainsi que pas mal de grandes pontes du paysage Agile, Henrik Kniberg par exemple !

Ce livre est une perle

L’article m’a immédiatement donné envie de lire le livre en question. Qu’à cela ne tienne, je me rend illico-presto chez mon libraire favori : Amazon. Malheureusement, l’article n’est pas disponible en France… Mais je le trouve sur Amazon UK ! Je passe commande, après ajout des frais de port et conversion en Euros (merci Amazon !), je m’en sors pour 17,41€.

À la lecture, j’enchaine les moments “mais c’est bien sûr !” et les “il faut trop qu’on fasse ça !”

J'ai le livre de Jimmy Jalén
Non je n’exagère pas, je suis vraiment content

Une fois reçu, aucun regret ! Je tombe immédiatement en amour pour ce petit livret rempli de conseils fantastiques sur le management visuels d’une équipe Scrum ou Kanban. Les idées fusent, j’enchaine les moments “mais c’est bien sûr !” et les “il faut trop qu’on fasse ça !” Petit format oblige, en quelques heures à peine, tout le livre est lu et digéré. Reste à faire son marché et à voir qu’est-ce qu’on essaie, avec quelle équipe, quand. Un super energizer de Scrum Master ou de Coach Agile, ça, moi j’vous l’dis !!!

Il y a quoi dans ce livre ?

Pour vous donner une idée d’à quoi ressemble ce super livre, voici un petit florilège d’extraits, de pourquoi ces exemples ont attiré mon attention et de ce que je compte en faire. Vous allez voir, c’est vraiment super.

Thème : quotidien de l’équipe, Stand-up et tâches techniques

Today’s Headlines

Noter la liste des infos à communiquer à l’équipe est une chose que je fais déjà tout seul en tant que Scrum Master, mais ça gagnerait à être écrit sur un board, car parfois j’oublie mes propres notes ! Il arrive aussi que d’autres personnes ont des choses à dire.

C’est ce que propose l’exemple Today’s Headlines :

Today's Headlines
Exemple : Today’s Healines

Task Estimation Boxes

L’équipe note déjà le temps passé sur les tâches, avec plus ou moins de rigueur. Task Estimation Boxes propose de le faire avec des cases à cocher. Cela devrait aider à ce que la pratique devienne naturelle pour l’équipe.

Task Estimation Boxes
Exemple : Task Estimation Boxes

Inbox

Nous avons parfois ce soucis : des tâches techniques sont ajoutées en cours de route, mais parfois l’équipe va un peu trop loin par rapport au périmètre de la User Story. Inbox avance une bonne trouvaille : se dire, OK on ajoute des tâches, mais on ne les intègre et démarre effectivement qu’après discussion en stand-up.

Inbox
Exemple : Inbox

Daily Goals

Daily Goals propose de définir en stand-up un but d’équipe, pour la journée.

Daily Goals
Exemple : Daily Goals

C’est un excellent moyen de faire travailler l’équipe ensemble, de s’assurer que le Sprint avance dans la bonne direction, de garder tout le monde focus et plein d’énergie !

Thème : évènements récurrents

Ready for demo

Un peu d’historique : Ces derniers temps nous nous sommes posé beaucoup de questions concernant nos Revue de Sprint. Nous avons finalement décidé de séparer en deux nos Revues de Sprint, directement inspiré d’une recommandation de Jeff Patton dans l’excellent livre User Story Mapping :

  • D’un côté une Revue Technique, très informelle, l’équipe fait le tour du board, échange sur ce qui s’est bien et mal passé, démo si quelqu’un en ressent le besoin, etc.
  • De l’autre une Revue Produit, qui s’adresse à un public beaucoup plus large, et dans laquelle les démonstrations sont à un niveau beaucoup plus fonctionnel.

Les deux Revues ne sont pas synchronisées. La Revue Technique correspond à la fin de l’itération (avant la Rétrospective) et est en lien direct avec le fonctionnement Scrum.

La Revue Produit, par contre, suit un autre rythme — un rythme qui reste à définir car les sujets de haut niveau ne sortent pas toujours à la même vitesse.

Ready for demo propose d’adresser un problème similaire lorsque l’équipe fonctionne en Kanban, via un board qu’on remplit au fil de l’eau avec les sujets à démontrer. L’utilisation de ce board sera peut-être la solution à notre question de rythme des Revues Produit !

Ready for demo
Exemple : Ready for demo

Team Rhythm/Cycle

Parfois l’équipe me demande où on en est dans l’itération. Les derniers jours d’itération en tant que Scrum Master je précise bien “attention, la fin de l’itération approche.” Plus globalement, l’équipe ne devrait pas avoir besoin de calendrier Outlook, car toutes les réunions qui les concernent devraient être récurrentes et bien connues. Mais à l’inverse, ils devraient être présent d’eux-mêmes à ces réunions récurrentes et bien connues !

Team Rhythm/Cycle propose un board qui reprécise tout cela. Bonne idée pour avancer dans un fonctionnement plus serein — sans Outlook !

Team Rhythm/Cycle
Exemple : Team Rhythm/Cycle

Thème : amélioration continue et Rétrospectives

Visualize your policies

En soi, Visualize your policies ne propose rien de nouveau, si ce n’est l’idée simplement brillante de préciser une date d’expiration. Nous ne passons pas en revue assez souvent nos process et autres contrats de fonctionnement, et cela ne semble pas logique de le faire systématiquement à chaque Rétro. Cette simple idée d’une date d’expiration permettra de s’en charger naturellement.

Visualize your policies
Exemple : Visualize your policies

Kaizen Board

C’est toujours compliqué le suivi des actions de Rétro. Il y a les petits trucs tous bêtes, qu’on fait et puis on n’en parle plus. Il y a les gros trucs, compliqués, et qui souvent dépassent un peu l’équipe, que prend généralement sur lui le Scrum Master et qui avancent lentement — à condition qu’il suive bien cela de son côté. Et puis, il y a tous ces changements de process, que l’équipe met en place mais qui mettent du temps à vraiment rentrer dans les mœurs, et dont on oublie de vérifier, une fois qu’on y est, que c’était effectivement une bonne idée et que les choses vont mieux depuis.

Sans parler du fait que parfois l’équipe a l’impression que faire la Rétro ne sert à rien, logique puisqu’on ne mesure par l’impact de les actions de Rétro.

Kaizen board propose un board dédié qui devrait permettre de mieux s’y retrouver, de voir que ça avance (y compris en apportant de la transparence sur ce que prend en main le Scrum Master), et surtout de s’assurer que ça sert à quelque chose !

Kaizen board
Exemple : Kaizen board

Achievement Posters

Achievement Posters propose un mini-atelier où l’équipe matérialise ses accomplissements lors de l’itération passée :

Achievement Posters
Exemple : Achievement Posters

Je vois tout un tas d’intérêt à mettre en place cette pratique :

  • Un excellent moyen de démarrer ou terminer la Revue de Sprint voire la Rétrospective
  • Et également un moyen d’évoquer les aspects positifs de l’itération, avant de passer à une Rétrospective dont certains formats sont très axés sur les problèmes et les actions à mener (en effet ces formats de Rétro laissent moins de place aux moments positifs et aux compliments, ce qui dérange l’équipe)
  • D’une manière générale, renforcer les liens dans l’équipe
  • Communiquer positivement en dehors de l’équipe, notamment auprès des parties prenantes
  • Une manière de formaliser les KPI de l’équipe, en affichant clairement que les accomplissements de l’équipe sont alignés avec ses objectifs globaux
  • Et aussi une manière de faire le point avec la roadmap à plus long terme, en faisant le lien avec les milestones et autres grosses releases

Bref, c’est cool, ça fait du bien à l’équipe, et ça aide à emmener tout le monde dans la bonne direction 🙂

Chat content
Un chat aussi content que moi, là tout de suite

Bonus : Comment décoller un Post-it

Shame !
Je ne savais pas décoller mes Post-it correctement

J’avoue, j’ai honte, je ne décollais pas mes Post-it correctement. À vrai dire, je n’ai pas le souvenir d’avoir jamais vu quiconque décoller correctement ses Post-its. Cependant, je ne vais pas vous gâcher la surprise en vous dévoilant la solution ! Vous n’avez qu’à acheter votre propre copie de ce chef-d’œuvre !

Conclusion

Foncez, c’est de la bombe !

Attention tout de même, l’auteur vous met en garde si vous utilisez un board virtuel, tel que JIRA. Mon conseil : arrêtez JIRA.

Attention tout de même, l’auteur vous met en garde si vous utilisez un board virtuel, tel que JIRA. En effet, beaucoup des idées présentées seront difficiles à appliquer dans ces conditions. En ce qui me concerne, je vous conseillerais plutôt… D’arrêter JIRA. Du moins d’arrêter ses boards pour leur préférer des boards physiques.

Franchement, ‘faut arrêter avec JIRA, le management visuel c’est mieux

Souvent les équipes qui sont habituées aux boards JIRA, ne voient aucun intérêt à passer à des boards physiques, pointant alors du doigt l’effort supplémentaire pour maintenir le board physique en plus du board JIRA. Je ne sais plus qui a dit cette phrase, qui explique à la perfection la situation :

Si vous ne voyez pas d’intérêt au management visuel, c’est que vous vous y prenez mal.

En général, j’essaie d’ajouter des exemples concrets de pourquoi un board physique est tellement mieux :

  • Une tâche est bloquée ? Pourquoi ? Où le notez-vous ? Écrivez sur votre board !
  • Une tâche est en recette ou en cours de validation chez un partenaire ? Quel partenaire ? Où en est-il ? A-t-on des nouvelles ? A-t-il besoin d’aide ? Écrivez sur votre board !
  • Besoin d’une tâche technique en plus ? Faites le Post-it et on n’en parle plus. Pas besoin de passer par la bureaucratie JIRA pour une tâche qui prendra moins d’une heure à faire. Beaucoup d’équipes abandonnent le découpage en tâches techniques uniquement parce que JIRA y est inadapté, pas parce qu’ils ne retirent aucun avantage d’avoir des tâches techniques.
  • Vous voulez expérimenter avec votre process d’itération ? Par exemple détailler les différents types de revues par lesquelles doit passer une US avant d’être considérée Done ? Pas besoin de faire de demande pour le faire évoluer dans JIRA.

Pourquoi les facilités de JIRA ne nous aident pas

A l’inverse, j’explique également en quoi on peut se passer facilement des supposés avantages de JIRA :

On ne veut pas perde du temps à mettre à jour deux boards !

Et bien, je réponds… Pourquoi mettre à jour le board de JIRA ? Le board physique ne suffit-il pas ? Utilisez JIRA uniquement comme outil de gestion de backlog global, mettez simplement à jour en fin d’itération les US terminées. Au pire, faites-le pendant la Revue de Sprint, ce sera l’affaire de 5 minutes. Par contre, ne mettez pas de tâches techniques dans JIRA : c’est ce qui est réellement coûteux à maintenir en double.

JIRA calcule automatiquement la vélocité de l’équipe…

… À condition d’avoir un process complètement aligné avec JIRA : JIRA ne compte les points que des US qui sont “résolues.” En pratique cela correspond souvent à des US qu’on a livré en production, ce qui n’est pas forcément le cas du process de l’équipe et de son Definition of Done. L’équipe ne faisant pas forcément des releases synchronisées avec ses itérations. Autre gag classique de JIRA : on met à jour des tickets dans le passé, pour tout un tas de raisons bonnes ou mauvaises, et contrairement à ce à quoi on pourrait s’attendre, cela ne met pas à jour la vélocité des itérations précédentes. En bref : on va plus vite à calculer soi-même la vélocité de l’équipe. En pratique, c’est très rapide à faire, voire même gratuit en le faisant par exemple en même temps que la Revue de Sprint.

JIRA aide à ne rien oublier !

Humm, parce que vous pensez réellement oublier une Story qui serait importante ? En toute honnêteté, si vous l’avez oublié, c’est qu’elle était bonne à sortir du backlog. Ça ne sert à rien d’avoir un espace de stockage illimité de backlog, par contre vous risquez de vous embrouiller et de vous perdre.

JIRA me donne un historique du projet.

C’est un argument qui se tient, à moitié et selon votre contexte projet. Pour beaucoup de projets, ce qui fait foi c’est ce qu’on a sorti, le produit qu’on a construit. Le backlog terminé n’a en fait aucune valeur. Tous les cas de figure où on serait content de déterrer quelque chose de JIRA, correspondent à des cas où on s’est raté quelque part : une doc manquante, du code mal écrit, un test manquant ou mal fichu… Dans une précédente mission on avait l’habitude de nous dire :

La vraie spec du legacy, c’est le comportement en prod.

Tout est dit. On s’en fiche que le comportement soit illogique, on s’en fiche de l’historique qui fait qu’on en est là, on doit vivre avec quoi qu’il arrive.

Ce livre : le réquisitoire parfait pour le management visuel

Finalement, ce livre peut être vu comme une liste d’excellents exemples de ce que peut apporter le management visuel à une équipe, de manière très concrète, fun, visuelle et convaincante.

Procurez-le vous, et montrez-le autour de vous !

Top