Est-ce qu'il faut demander la permission pour faire correctement son boulot ?
Il y a quelques semaines, j'ai participé à un Agile Game Labs 🎲 organisé par Agile Toulouse. J'y ai joué au "Built-in quality Game", proposé et animé par David Brocard lors de cette soirée. Le jeu est très intéressant mais lors d'un jeu sérieux, les réactions des participants sont tout aussi intéressantes.
Il arrive régulièrement lors de jeux sérieux que les gens fassent le parallèle avec leur quotidien. C'est d'ailleurs un peu le but. Et ils envisagent parfois que l'action effectuée dans le jeu ne soit pas possible dans la vie réelle.
D'où l'importance de se poser le plus souvent possible les bonnes questions dans cette vie réelle.
Dans le contexte du "Built-in quality Game", l'équipe de joueurs va introduire, une par une, des nouvelles pratiques dans son flux de production et constater l'amélioration de la qualité de cette production.
On démarre avec un tableau de flux, souvent appelé "Kanban Board", assez classique avec ses contraintes sur le travail en cours pour chacune des colonnes. Le nombre de colonnes est assez élevé avec de nombreuses activités à parcourir pour aller de l'idée business au déploiement en production.
La mécanique de base du jeu repose sur un lancer de dés pour chaque item qui arrive en production. Ce lancer permet de dire si la fonctionnalité est ok (somme des 2 dés >= 7) ou si elle doit revenir dans une des colonnes du tableau en fonction du problème qui a été détecté en prod.
On suit la valeur présente en prod avec un graphique. On se rend compte très vite qu'elle ne monte pas beaucoup, entre les goulots d'étranglement sur le flux et les retours des problèmes en prod. On entre alors dans une 2ème phase où l'équipe va pouvoir "acheter" des pratiques qui vont lui éviter d'attendre l'arrivée en production pour identifier et corriger les problèmes.
| Somme des dés | Problème | Retour en | Sauf si on pratique |
|---|---|---|---|
| 2 | Pas de business pour cet fonctionnalité | Nouvelle idée business | Lean Startup |
| 3 | Fonctionnalité nutilisable | Backlog produit | Walking Skeleton |
| 4 | Ce n'est pas la fonctionnalité demandée | Backlog de sprint | BDD |
| 5 | Problème de migration des données | Backlog de sprint | Devops |
| 6 | Il y a un bug | Implémentation | TDD |
En intégrant certaines pratiques qui limitent les problèmes, on constate que la valeur mise en prod augmente beaucoup plus vite. C'est bien évidemment très simpliste mais c'est normal car ça doit rester un jeu facile à aborder.
Dans un jeu de ce genre, il y a toujours quelqu'un pour questionner la possibilité de faire dans la vie réelle l'action réalisée dans le jeu - et ce fut le cas ce soir là.
C'est très bien mais est-ce qu'on va nous autoriser à utiliser [insérer ici le nom d'une des pratiques] ?
En fait, on pourrait presque croire que ces jeux sont là presque exclusivement pour ça. Il y a des exceptions mais, la façon de faire correctement le boulot, souvent on la connait. Ce qui est difficile, c'est de la pratiquer effectivement.
Est-ce qu'il y a besoin de demander la permission à qui que ce soit si les personnes qui font sont convaincues de la façon de procéder ? Moins la pratique est visible de l'extérieur, plus c'est facile.
Si je suis seul en train de coder sur mon poste, je ne vois pas qui pourrait m'interdire de pratiquer le TDD à moins de m'enlever le clavier des mains.
Si les devs d'une équipe sont convaincus qu'il y a un élément de dette technique à résorber, je ne vois pas qui pourrait les en empêcher à moins de leur bloquer l'accès au code.
Les jeux sont intéressants pour la découverte de certaines idées mais ils le sont moins tout autant pour la thérapie collective qui consiste à se rendre compte que beaucoup de choses que l'on croit impossible ne le sont pas du tout.