Raison 1 : L'information est disponible en permanence et instantanément

Il n'est pas nécessaire d'ouvrir un fichier ou d'accéder à une application, l'information est là devant tout le monde.

Raison 2 : Tout le monde peut consulter le mur d'informations

On constate qu'il y a plein d'intervenants extérieurs qui viennent consulter le mur, pour prendre la température du projet, s'assurer que cela avance, se rappeler des dates clefs du projets...
On peut même assister à des réunions autour du Scrum Board entre les membres de l'équipe, le Product Owner ou d'autres intervenants.

Raison 3 : C'est plus simple pour le Daily Scrum

Il n'est pas facile d'être à plus de 3 autour d'un écran tout en restant debout, le backlog mural permet à toute l'équipe de visualiser ce qu'il se passe durant la réunion, de lire ce qu'il y a sur les post-it pour se préparer à répondre aux 4 questions quand son tour viendra.
La visualisation globale du backlog de sprint permet à toute l'équipe de participer au Daily.
Avec une application, il faut soit

  • imprimer un point de situation mais c'est difficile de faire des changements durant le Daily,
  • faire passer les développeur à tour de rôle devant l'écran, c'est trop "militaire" à mon gout.


Raison 4 : On rajoute plein d'informations supplémentaires autour du BackLog de Sprint

On peut avoir :

  • Le nom du projet avec les intervenants (ça fait toujours de la pub) :-)
  • L'objectif du Sprint, en 1 ou plusieurs phrases : cela permet de rappeler l'objectif du sprint
  • La DoD (Definition Of Done) : Qu'est-ce qu'une tâche terminée
  • Les 4 questions du Daily (ça évite d'avoir des : "heu c'est quoi au fait les questions" :-) )
  • Un planning mensuel présentant plusieurs mois : pour noter les absences, les dates clefs et les évènements importants du projet ou sprint
  • Quelques diagrammes d'états important pour le sprint
  • ...


Raison 5 : C'est le K du VAK !

K pour Kinesthésiste (Merci Bruno pour ta présentation à l'anniversaire de la FSUG en 2009).
On touche (pour une fois) quelque chose : ça change du clavier.
Les développeurs "signent" (avec leurs initiales) les Post-it qu'ils s'affectent pour le développement (en cours) ou pour les tests (to test), cela responsabilise le développeur.

Raison 6 : La vérité est sur le mur

Il ne peut pas y avoir de doute sur ce que l'on regarde, une personne peut consulter un mauvais fichier, le ScrumMaster a ramené le fichier Excel chez lui et ne l'a pas déposé sur le réseau ...
En une fraction de seconde, on voit des choses :

  • 3 tâches en cours avec une équipe de 5 développeurs : il y en a 2 qui sont à la plage ? :-)
  • 7 tâches en cours avec une équipe de 5 développeurs : il y a des tâches en attente
  • ...


Raison 7 : L'équipe est transparente

L'équipe présente sont avancement et partage ces difficultés.

Raison 8 : Il n'y a moins de "ça doit être une erreur"

J'ai vu beaucoup de "Oui j'ai mis 0 pour terminé mais c'est pas encore terminé, mais ça va être fait bientôt" !!!
Le développeur préfère anticiper ses activités car c'est plus simple pour lui : why not.
Avec le tableau mural, on fait la modification après avoir terminé sa tâche.
Et les données sont mises à jour plus fréquemment.

Raison 9 : Pas de statistique par développeur

Bien sur, vous pouvez "pister" la performance individuelle de chaque développeur mais c'est plus difficile, et c'est bien.
Cela permet de travailler sur la performance collective de l'équipe.

Raison 10 : J'aime les rature sur les Post-it :-)

Les ratures, les post-it de travers, déposé "un peu" n'importe comment...
ça donne un coté réel du projet.
Les ratures racontent l'histoire de la tâche et peuvent en dire long sur la réalisation de la tâche.


Voila mes 10 raisons, bien sur, il faut que l'équipe soit collocalisée et que l'écran de "Minority Report" ne soit pas commercialisé à moins de 100€.