Comment un outil des années 50 pourrait-il être le bon pour suivre et capitaliser sur les runs d’aujourd’hui ? Notre première réaction serait de dire que ce sera trop lourd (en plus, c’est un outil «qualité» !) et que l’on ne pourra jamais y trouver la flexibilité que l’on recherche dans les développements Agile.
Voici pourtant pourquoi le PDCA est totalement adapté à la méthode Agile.
Le PDCA expérimental et la notion de run
L’outil PDCA est en effet totalement adapté au plan d’action expérimental, celui qui consiste à lancer des analyses, et agir en fonction des résultats obtenus. Les phases divergent alors plus ou moins par rapport au PDCA classique.
Plan – Planifier
Nous avons vu la semaine dernière que la phase de planification se faisait à la suite d’un travail parfois long d’analyse des causes premières d’un problème. C’est un peu différent dans le cas du plan d’action expérimental puisque l’on va noter toutes les analyses potentielles ou les actions expérimentales sans se poser la question de leur validité – ce qui n’exclut pas de se poser quand même la question de leur pertinence… On liste dans la partie « Plan » tout ce qu’il semble pertinent d’entreprendre. C’est dans les phases suivantes que l’on confirmera si oui ou non on va dans la direction envisagée.
Il n’y a pas de limite sur les types d’actions : faire une recherche documentaire est une action. Il est même souhaitable de les inclure dans la partie de planification, les résultats seront ainsi rattachés au plan d’action pour une meilleure capitalisation.
Quel lien avec les runs ? Lors d’un run, on prévoit de faire une liste définie d’actions. On les liste dans la partie « Plan » avec responsable et délai. C’est ce que l’on retrouve dans les tableaux type Kanban utilisés le plus souvent dans les métiers du développement informatique. Il y a une première colonne de «back log» avec toutes les idées. Au moment de définir le prochain run, on fait passer les cartes que l’on veut implémenter dans la colonne « Prochain run. » Cela correspond à une planification, puisqu’à ce moment précis chaque carte reçoit un responsable et un délai.
L’exemple ci-dessous est réalisé avec trello.com que j’utilise au quotidien.
Do – Réaliser
Pas de grosse différence avec le PDCA classique ici : on fait ce qui est prévu
Dans le cas des runs, la carte passe dans la colonne « Done » après réalisation.
Check – Vérifier
Il s’agit d’une phase très importante pour le PDCA expérimental. C’est là que l’on vient analyser les résultats de chaque action et décider d’aller plus loin ou non.
- Les hypothèses sont-elles confirmées ?
- Les modèles fonctionnent-ils ?
- Le planning définit est-il tenable ?
Le format que nous proposons rend cette opération plus simple en proposant de définir le résultat attendu dès la phase de planification (lorsque c’est possible bien entendu) et en proposant une colonne assez large pour la partie « Check » afin de permettre de préciser les actions de validation ou d’y créer des liens vers des documents plus conséquents (rapports, compte-rendus de réunions, …)
Pour notre run, il ne s’agit pas seulement de confirmer que cela fonctionne, mais aussi de valider que les actions sont possibles à mener dans le délai du run.La partie vérification se déroule donc en 2 temps : c’est fait et ça fonctionne (ou pas*) et j’ai le temps nécessaire pour l’inclure dans le run.
- Et si ça ne fonctionne pas ?
Dans le cas d’un run, c’est simple, on capitalise l’action dans le manuel métier ou le rapport projet et on archive la carte. Dans le cadre d’un plan d’action expérimental, on peut avoir besoin de lancer de nouvelles actions. On repasse alors dans la catégorie « Plan » (et là aussi, il eut être intéressant de capitaliser dans un manuel métier)
Dans les 2 cas, il faut reconnaître la valeur d’une analyse, d’une action ou d’un test qui ne fonctionne pas : on n’a peut-être pas résolu le problème ou fini la fonction, mais on a apprit. C’est important. Pas toujours facile dans les milieux techniques où l’on est formaté à « sortir des produits » !
Act – Capitaliser -> Agir
Le terme Act demande ici une traduction différente, utilisée parfois dans le cadre du PDCA classique : Agir Il s’agit d’appliquer concrètement les éléments validés pendant la phase précédente. Ainsi la fin de notre PDCA expérimental marque le début d’un PDCA plus classique dans lequel les actions validées seront listées. C’est pour cela que notre modèle de plan d’action propose les colonnes Quoi, Qui et Quand dans la partie capitalisation. Nota : pas de vérification, c’est le travail précédent qui a permis de valider ce que l’on devait faire. Seule la colonne Done (Réalisé) est conservée pour permettre de montrer visuellement que tout est fait.
Aucune différence dans le cas d’un run. Simplement la carte va être attribuée à un responsable, et envoyée dans sa liste de tâche.
Le PDCA reste le modèle idéal de plan d’action
Ainsi, nous avons vu que l’enchainement des taches et la logique du PDCA reste applicable pour les méthodes de développement d’aujourd’hui.
Néanmoins, les outils évoluent. Et si le fichier excel reste le moyen le plus couramment utilisé pour géré des plans d’action qualité, de nouvelles solutions sont disponibles sur des plateformes web grace aux outils de gestion de projet. Asana ou Trello et d’autres encore offrent des possibilités nouvelles de collaboration et font faire peau neuve à ce vieil outil qu’est la roue de Deming.
The Floating Mushroom 