Il propose également un atelier sur ce thème qui me semblait complémentaire au format conférence que j'avais adopté; Vous pouvez lire le compte rendu de sa dernière session à Agile 2009 à Chicago.
J'ai donc pris contact avec lui pour faire cet atelier, Visual Management for Agile Teams, ensemble lors des XP Days Benelux en novembre.
Pour préparer cet atelier, Nous avons un premier essai lors de la dernière session CSM d'Agilbee à Rennes, avec une dizaine de participants:
L'objectif de cet atelier exploratoire est de construire un Scrum board qui répond à un certain nombre d'exigences, des plus simples - le tableau doit montrer qui travail sur quoi, aux plus subtiles telles que les gestions de dépendances. Le tableau est construit par équipe en deux itérations avec des revues entre les itérations.
Normalement, quelques slides sont déroulées en guise d'introduction avec quelques photos de Scrumboard qui ont certainement une influence sur le résultat de l'atelier. J'ai décidé de ne rien montrer pour avoir un résultat brut pour cette première... La prochaine fois, je ferais l'introduction!
Equipe bleue
Le tableau ne répond pas à toutes les exigences, telles que le product backlog visible mais il est assez aéré. Les deux équipes ont fait le choix d'avoir des postits de couleurs différentes par histoire utilisateur et des gommettes de couleurs pour suivre le travail de chacun.
Pour le premier, cela fait bien ressortir les histoires utilisateurs mais apporte de la confusion sur les codes couleurs. Cela pourrait être intéressant dans le cas de Kanban board avec des lignes fonctionnelles plus macro et plus stable dans le temps.
Pour les gommettes, c'est simple, ça marche pour les petites équipes. Pour les équipes plus nombreuses, on est vite à court de couleurs et on doit plutôt utiliser les Nametags. Ceux-ci ont un autre intérêt, celui de limiter le travail en cours en limitant par exemple deux nametags par personne.
Les nouvelles exigences se sont plutôt traduites par des éléments supplémentaires, gommettes, couleurs, post-its, ce qui en complique la lecture: une légende a été nécessaire.
Equipe Rouge
Les nouvelles exigences de la seconde itération ont amené une part de refactoring du tableau avec l'ajout de deux colonnes supplémentaires: Finished Today et Test.
La seconde est classique, surtout lorsque l'on a une spécialisation dans l'équipe, développeur/testeur par exemple. La première l'est beaucoup moins: l'exigence consiste à montrer ce qui a été réalisé dans la journée. On peut se demander à quoi sert cette exigence puisque l'on a une colonne "Done" pour visualiser cela: Déplacer son post-it lorsque l'on a fini une tâche est une mini célébration, bon pour le moral, difficile d'attendre le lendemain pour le faire. Mais alors l'information se perd le lendemain lors de la mêlée et surtout il est plus délicat de mettre à jour le sprint burndown chart. Ce petit exercice anodin fait ressortir les mauvaises pratiques d'équipe telles que faire ce graph sur la base du reste à faire plutôt que sur les tâches finies.
Une idée intéressante est remontée avec la liste des obstacles: On attribue un indice à chaque obstacle. Les tâches impactées par cet obstacle ont un tag (postit ou gommette) sur lequel on reporte l'indice.
les objectifs d'un bon tableau visuel sont remplis si :
- L'équipe se sert effectivement du tableau, notamment pendant la mêlée
- Votre chef est fier de le montrer à son chef
- Une personne qui le découvre peut le comprendre sans explication
- Il change avec les besoins ou les contraintes du projet
- Les managers ou décideurs s'arrêtent pour le regarder, avec intérêt et curiosité
- Vous le trouvez beau
* Arrêtez de visualiser si vous ne voulez ou ne pouvez pas faire d'action.
* Avant de faire une action rendez visible le problème et ses objectifs.
Je ne serais pas si catégorique et je parlerais plutôt du besoin ou de la nécessité d'avoir un feed-back rapide, ce qui génère ensuite des actions.
[1] Prochaines sessions Management visuel:
