Un outil pour l’amélioration continue du standard

Désolé pour les gamers, mais non je ne vais pas vous parler du dernier Day of Defeat. Par DoD comprenez plutôt « Definition of Done », c’est à dire l’ensemble des critères à respecter pour considérer une tâche terminée. Par exemple, avant de soumettre son code, un développeur doit s’assurer de respecter le critère: « tests unitaires OK ».

En quoi un outil aussi « low-tech » et aussi simpliste qu’une check-list peut nous aider à l’ère de Google et de l’iPhone ? À une révolution dans le niveau de qualité fournie. Pour preuve emblématique, les initiatives récentes dans le milieu hospitalier. Cet extrait parle de la pose d’un cathéter (voie veineuse centrale).

« In 2001, though, a critical care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give a doctor checklist a try. […] Doctor are supposed to (1) wash their hands with soap, (2) clean the patient’s skin with chlorhexidine antiseptic, (3) put sterile drap over the entire patient, (4) wear a mask, hat, steril gown, and gloves, and (5) put a steril dressing over the insertion site once the line is in. […]

In the Keystone initiative’s first eighteen months, the hospitals saved an estimated $175 million in costs and more than fifteen hundred lives.« 

Et ce seulement dans le Michigan !

Avant même de parler des DoD, je rappelle que ceux-ci sont au service de l’amélioration continue du standard.

Qu’est ce qu’un ( bon ) standard ?

Je vous propose cette définition :
« Un standard est la meilleure pratique constatée à ce jour, énoncé explicitement, avec une finalité affichée, et dont on sait mesurer les écarts. »

Celui-ci au sens Lean se doit de respecter certaines grandes caractéristiques, il doit être :

• issu du terrain
• évolué sur la base de l’amélioration continue et de la résolution de problème
• simple
• supporté au maximum par du management visuel
• remis en cause sur la forme et sur le fond lorsqu’il n’est pas appliqué

Les DoD sont des éléments de ce standard, ils se doivent donc eux aussi de respecter ces caractéristiques. Appliquons donc celles-ci à nos DoD :

Issu du terrain

C’est sur le terrain que devra être appliqué le standard et c’est bien là que les problèmes sont rencontrés et encore là que le standard sera remis en cause et amélioré.

Voici un autre extrait tiré du même livre qui relate l’échec de la première version de cette check-list. Cette première version ayant été rédigée par des chirurgiens, non pas au bloc, mais lors de réunions en omettant la plupart des acteurs, infirmières, anesthésistes, …

« I gave the checklist to Dee, the circulating nurse, and asked her to run through the first section with us at the right time. Fifteen minutes later, we were about to put the patient under general anesthesia, and I had to say, Wait, what about the checklist?
« I already did it, » Dee said. She showed me the sheet. All the boxes were checked off.
No, no, no, I said. It’s supposed to be a verbal checklist, a team checklist.
« Where does it say that? » she asked. I looked again. She was right. It didn’t say that anywhere.
Just try it verbally anyway, I said.
Dee shrugged and started going through the list. But some of the checks were ambiguous. […]. And after a few minutes of puzzling our way through the list, everyone was becoming exasperated. Even the patient started shifting around the table.
« Is everything okay? » she asked.
Oh yes, I told her. We ‘re only going through our checklist. Don’t worry.
But I was getting impatient, too.  The checklist was too long. It was unclear. And past a certain point, it was starting to feel like a distraction from person we had on the table.
By the end of the day, we had stopped using the checklist. Forget making this work around the table. It wasn’t even working in one operating room. »

Dans cet extrait il est clair que l’infirmière Dee aurait dû être consultée pour l’élaboration de la check-list. Les propositions d’améliorations doivent être émises par ceux qui rencontrent le problème et qui ont la meilleure vision de toutes les contraintes. Mais c’est loin d’être suffisant.

Un exemple issu de nos métiers : Jean développeur décide qu’à partir de maintenant le passage dans un formateur de code est obligatoire avant tout commit. C’est donc un nouveau DoD pour terminer une tâche de développement.

C’est sans doute une bonne initiative, mais elle est vouée à l’échec. Pourquoi ?

Évoluant sur la base de l’amélioration continue et de la résolution de problème

Le standard ne pourra être respecté que si il est partagé par toute l’équipe. Pour y arriver, le Lean nous met à disposition l’amélioration continue et la résolution de problème via, dans le cas des méthodes agiles, les rétrospectives.

Revenons au formateur de code de Jean. C’est une nouvelle contrainte pour les développeurs qui ne la comprennent pas forcément ( « c’est pour faire joli ? », « moi j’aime pas les accolades à droite ! « , etc…).

En effet, les autres membres n’éprouveront pas le besoin puisqu’ils n’y voient pas de solution à un problème donné.

Pourquoi ne pas se servir de la rétrospective ?

Si des actions d’amélioration ont été trouvées lors d’une rétrospective, il est très probable que des DoD puissent s’en déduire. De plus, c’est un moment privilégié où toute l’équipe est concentrée à l’amélioration du process.

Comment ce cas aurait pu être traité en rétro ?

Jean : « Je n’ai pas pu finir ma user story pour la recette, le merge était trop difficile avec la US de René. »

René : « Mais on ne travaillait pas sur les mêmes méthodes ? »

Jean : « J’ai eu pleins de conflits parce que tu mets toutes tes accolades à la ligne… »

René : « Mais c’est beaucoup plus lisible au niveau de l’indentation, non ? »

Jean : « C’est pas le standard le plus répandu ! »

René : « C’est toi le stand… »

La vache Octo : « Meuuuuuuuuuuuuuuuuuuuuuuh »

Le coach Octo : « Ca vous dit de traiter le point au calme et en rétrospective technique ? »

Dans cette retro spécifique aux développeurs le coach (ou team leader) va aider l’équipe à clore ce débat « passionnant » de l’indentation et convenir d’un formateur unique ainsi que de l’ajout au standard d’un DoD « FORMATEUR DE CODE APPLIQUÉ ».

On a maintenant deux fervents défenseurs de cette partie du standard, Jean qui appréhende un nouveau merge difficile et René qui aime ses accolades !

C’est donc bien le processus d’amélioration continue qui nourrit et fait évoluer le standard.

Simple

Le but final est de construire le meilleur standard applicable. Qui dit applicable dit simple. Cela implique que les DoD qui le composent soient le plus simples possibles.

Ainsi, la formalisation d’un DoD doit respecter quelques règles :

• univoque pour toute l’équipe :
  • « BUILD OK » peut ne pas être suffisant, c’est en local ? en environnement sandbox ?
  • « BUILD OK SUR MACHINE TOTO » lève le doute.
• en nombre limité :
  • Cette liste de DoD devra être appliquée et contrôlée pour chaque tâche Il faut donc limiter leur nombre (entre 1 et 10 critères pour passer une tâche d’un état à un autre)
• concis :
  • Le nombre de DoD pour l’ensemble du process peut devenir conséquent, il ne faut pas noyer l’information. À « Vérifier que le build d’intégration continue sur la machine TOTO n’a pas été mis en échec par notre commit », on préférera « BUILD OK SUR MACHINE LP32 » qui reste malgré tout parlant pour l’équipe.

Management visuel

Toujours dans le but de rendre notre standard applicable le plus simplement possible, nous allons cette fois ci nous appuyer sur le management visuel.

Rendre les DoD visuels les rendra plus accessibles et donc plus facilement utilisables.

Comme ils ne seront qu’une source d’informations parmi d’autres, il convient de les rendre clairs et normés. Par exemple Post-It vert clair /  marqueur noir / en majuscule.

Je vous laisse apprécier la différence :

En agile, les étapes du processus sont reflétées par les colonnes du scrumboard / kanban board. Les DoD doivent être contrôlés au changement d’état. Celui-ci se matérialise par le déplacement du Post-It de la colonne A vers la colonne B. Le meilleur endroit pour afficher les DoD est donc, à mon sens, au dessus (ou en dessous) de celles-ci.

Remis en cause sur la forme et sur le fond lorsqu’il est non appliqué

L’un des grands principes d’un standard, tel que le Lean le définit, est qu’il est vivant. La définition d’un standard donnée en début d’article parlait bien d’un instant T. Si à T+1 on observe que le standard n’a pas été appliqué, il faut le remettre en cause.

Si un critère du DoD n’est pas appliqué il est nécessaire de se poser les questions suivantes :

• le critère n’a pas été vérifié car il n’est plus pertinent ?
• le critère n’a pas été vérifié car il n’est pas assez « ergonomique » et clair dans le DoD ?
• le critère n’a pas été vérifié car la personne n’a pas regardé le DoD ?
• le développeur en charge de vérifier le critère a pensé à tort/à raison qu’il s’agissait d’un cas particulier non encore explicité dans le standard de l’équipe ?

Dans le cas où le critère a été mal compris il convient de le modifier. Par exemple si le critère « TEST FONCTIONNEL OK » ne suffit pas car le test peut passer en local mais échouer en environnement sandbox, le reformuler en « TEST FONCTIONNEL OK EN SANDBOX ».

Mais que faire quand on découvre que le DoD a été contourné à tort ?

Déboires

Dans la pratique il s’avère que, même avec des développeurs pleins de bonne volonté, l’application des DoD n’est pas toujours réalisée.

Et pourtant… C’est très frustrant de voir à une rétrospective une US KO, la vélocité chuter, alors que le remède était là, en majuscules et visible partout dans l’openspace :

Jean, en charge de la US à KO : « Ca marchait en local. »

L’équipe : …

Comment garantir le respect des DoD

Quelque chose de simple mais qui fonctionne : le binômage dans le déplacement des Post-It. Un développeur souhaitant faire avancer sa tâche doit avertir un autre développeur. Le but étant de responsabiliser deux personnes sur le respect du DoD mis en place pour ce changement d’état.

De manière générale, il faut à tout prix responsabiliser l’équipe au respect des DoD : « c’est votre standard, c’est-à-dire la meilleure façon que vous avez trouvé jusqu’ici pour réaliser l’objectif. Soit vous l’appliquez à la lettre si il est pertinent soit vous le remettez en cause en équipe».

Un autre outil qui peut déranger mais qui peut fonctionner dans certaines équipes, le « wall of shame ». Très simple… un Post-It géant avec le nom de chaque développeur. Le non respect d’un DoD entrainant un bâton à coté du nom du développeur concerné.

Il suffit d’en faire un jeu plus qu’un outil de « flicage » et c’est à mon avis le meilleur moyen de garantir le respect des DoD. L’équipe est responsable des DoD donc à l’équipe elle-même de fixer, dans un cadre pro, la conséquence du non respect du standard. Le but n’étant pas de sanctionner mais de faire prendre conscience des DoD.

Comment en faire un jeu ?

• 5 bâtons = un fond d’écran « Dora l’exploratrice » pendant 2 jours
• 10 bâtons = des croissants pour l’équipe
• …

Enfin, quelque chose que je n’ai pas encore pu essayer mais qui me semble prometteur, les cases à cocher. De la même manière que pour une check-list classique, il faudrait posséder sur les Post-It matérialisant les User-Stories une case à cocher par DoD. Ainsi un oubli de DoD est clairement visible de tous. Et tout le monde peut participer au respect du standard. Si vous avez des retours d’expériences la dessus, je suis preneur !

Conclusion

On peut maintenant définir un DoD :
« Elément visible de tous, concis et univoque définissant les conditions permettant de passer une tâche d’un état à un autre. Leur ensemble définissant le standard d’un processus ».

Avec l’utilisation des DoD, il devient possible de partager tous les standards d’une équipe sur l’outil que tout le monde utilise et voit en permanence, le scrumboard / kanban board.

Autrement dit, la meilleure façon d’apporter de la valeur au projet connue à ce jour est visible par tous et à tout instant.