La prédictibilité au pays de Kanban

Kanban est de plus en plus présent au sein des entreprises et de la communauté Agile. Scrumban, la conjonction des pratiques Scrum associées aux techniques de management visuel proposées par Kanban, en est l’une des formes les plus connues.

Kanban se fait également une place auprès des équipes de maintenance et des équipes IT grâce à sa gestion du travail en flux continu. Toute équipe qui n’a pas besoin de livrable concret à période fixe, adoptera Kanban en prenant quelques éléments de Scrum, tels que le standup meeting ou la rétrospective flottante.

En ce début d’année 2013, nous vous proposons un aspect peu utilisé dans les équipes Agiles, la prédictibilité avec Kanban. Durant l’année dernière, nous avons eu l’occasion de mettre en oeuvre plusieurs Kanbans importants sur des projets de développement et de maintenance. Nous avons utilisé les indicateurs produits par les pratiques de Kanban pour mettre en oeuvre de la prédictibilité sur ces projets. 

Le premier tableau fournit le résultat d’indicateurs de performance sur un des projets que nous avons accompagné dans une démarche Kanban. Ce tableau est généré quotidiennement. Il est le résultat du mouvement des tâches sur le tableau Kanban par l’équipe projet. 

Définition : Le temps de cycle est le temps passé depuis le démarrage du travail sur une tâche jusqu’à ce qu’elle atteigne l’état "Terminé". À ne pas confondre avec le lead Time qui correspond à l’instant où la tâche est créée jusqu’à sa résolution.

Dans un objectif de simplification, nous n’avons pas fait apparaître le lead Time dans le tableau. Nous reviendrons sur ce sujet dans un prochain article. 

Le deuxième tableau fournit un état des lieux du projet actuel :

Les deux tableaux nous permettent d’obtenir notre tableau de prédictibilité :

Ce tableau nous donne une première idée de ce qu’il est possible de réaliser en analysant quotidiennement les données provenant d’un Kanban. 

La première ligne permet d’identifier la fin du projet. Si nous n’ajoutons aucune nouvelle User Story au projet actuel, le projet prendra fin le 13 février 2013. Si nous ajoutons 10 nouvelles Users Stories, nous finirons le 27 février 2013 et nous aurons 14 jours de retard supplémentaire. 

Les deux autres lignes suivantes indiquent le nombre d’anomalies et le temps pour les résoudre. 

Le tableau ci-dessus est un exemple simplifié dans lequel nous utilisons la vélocité moyenne pour calculer les "dates d’arrivée" et le temps de "résolution des anomalies" en relation avec le nombre de personnes sur le projet. Nous pourrions compléter ce tableau avec la vélocité basse, haute et moyenne pour les User Stories et les anomalies, prendre en compte les périodes de congés, les évolutions par User Story, etc.

Comment fait-on pour calculer la prédictibilité sur notre projet? Pour ce faire, nous prenons le temps de cycle moyen pour terminer une User Story. Dans notre cas, elle est de 22 jours. Nous multiplions ce chiffre par le nombre de Users Stories restantes à faire. Le tout est divisé par la capacité de travail de notre équipe.

Par exemple, si nous devons réaliser 9 Users Stories et que le temps de cycle est de 22 jours, nous aurons 198 jours d’activité. Etant donné que nous avons 10 personnes dans l’équipe pour une capacité moyenne de 200 jours par mois, nous pourrons terminer le projet dans un mois.  

Nous devons également tenir compte des anomalies. Pour ce projet, nous réalisons 3 anomalies pour 1 US, avec un cycle de temps de 19 jours par anomalies, soit 513 jours. Il nous faudra donc 2,5 mois supplémentaire pour corriger l’ensemble des anomalies.

Vous trouverez les formules de calcul détaillées ici.

En complément, nous pourrions ajouter les évolutions, prendre en compte les jours de congé, etc.

Conclusion

Le calcul de la prédictibilité en Kanban est un formidable outil de pilotage. Nous avons eu l’occasion de le mettre en oeuvre sur plusieurs projets depuis 2010. Il s’avère être un outil de plus en plus précis après une première période de stabilisation d’environ 3 à 4 sprints (de 2 semaines). 

Ces données nous permettent d’obtenir des indicateurs Agiles en temps réel en évitant l’effet tunnel des méthodes classiques. Dans les exemples que nous avons proposé, nous extrapolons le nombre potentiel d’anomalies sur le projet, donc le coût réel. Celui-ci est habituellement caché et le client le découvre souvent à la fin de son projet (certaines SSII ajoutent même une pondération de 30% dans leurs propositions commerciales). Obtenir ses données en temps réel permet de remonter des données factuelles auprès des managers et de prendre rapidement des décisions pour réduire ce gaspillage en terme de qualité et de finance. 

Avec un simple reporting quotidien, nous disposons automatiquement d’une vraie visibilité sur notre projet : la date d’atterrissage de notre backlog, le coût d’un nouveau besoin, le nombre et le coût moyen des anomalies par User Stories, etc. Le tout sans estimation! Le cérémonial est réduit au strict minimum. C’est simple, c’est Lean!

Maintenant que nous pouvons analyser nos coûts, nous aborderons la "Réduction des coûts au pays de Kanban" dans un prochain article.

Note : Les chiffres présentés dans cet article sont donnés à titre d’exemple sans lien avec un projet réel.