MyProjectStuff

Onzième épisode du roman fil rouge du livre Kanban pour l’IT.

Dans le dernier épisode MyProjectStuff,  Charles visualise le goulot d’étranglement des tests sur le tableau Kanban de l’équipe de réalisation Véga.

Sprint 3 Aldébaran – Version majeure 4.0

Sophie décide de préparer sa prochaine rétrospective. Elle s’isole de l’open space un après-midi pour travailler sur la VSM du projet et identifier le prochain thème de rétrospective. Elle construit sa cartographie sur la base de la dernière version mineure 3.1 :

Une story passe en moyenne trois semaines de mûrissement dans le backlog. Pauline y consacre deux heures de travail. La story est ensuite implémentée en moyenne en deux jours pendant le sprint. Une version compte quatre sprints avant d’être déployée. Elle reporte ces informations sur le schéma suivant :

MyProjectStuff

MyProjectStuff : VSM Version 3.1 Aldébaran

Sophie calcule une efficience de 10,5% pour le processus ayant permis de livrer la version 3.1. Un peu surprise du résultat si bas, elle se lance dans l’analyse du gaspillage.

 

Analyse du gaspillage

Sophie commence l’analyse du gaspillage du processus d’Aldébaran. La cartographie montre que l’essentiel du gaspillage se trouve dans le backlog. Cela confirme que ce processus de mûrissement de stories n’est pas efficient. Elle et Pauline l’ont déjà constaté. Elles espèrent que la mise en place du système kanban au niveau marketing va porter ses fruits.

Le gaspillage suivant est le temps passé à attendre la mise en production. Ce point est lié au choix de la cadence de livraison du produit tous les quatre sprints. Elle est dictée par le coût d’une mise en production.

Ces deux pistes d’amélioration ne sont pas dans les mains de l’équipe. Elle fait alors un zoom sur la VSM du sprint :

Sur un total de 80 heures, à peu près 16 heures apportent de la valeur ajoutée à une story. Il y a donc 64 heures d’attente.

VSM sprint Aldébaran

VSM sprint Aldébaran

L’efficience est de 20% ! Localement, le processus est bien plus efficient. Ce n’est pas surprenant car Scrum est un processus optimisé autour des stories sur des cycles courts.

Les gaspillages les plus importants sont liés à la durée du sprint : la planification toutes les deux semaines nécessite d’avoir assez de stories pour l’équipe sur cette période. Une fois implémentée, la démo n’ayant également lieu que toutes les deux semaines, la story attend quelques jours avant d’être démontrée.

L’équipe pourrait essayer de passer à des sprints d’une semaine pour augmenter l’efficience du processus. Pauline serait prête à suivre ce rythme mais les utilisateurs clés ne pourraient se rendre disponibles aussi fréquemment pour la démo. Découpler les deux cadences de planification et de démo serait une piste envisageable.

Le gaspillage suivant est la revue. Ce résultat renforce son sentiment qu’une limite de quatre, qu’elle n’a pas réussi à descendre, sur la colonne « En revue », est trop élevée. Elle décide de mettre le focus de la rétrospective sur ce point et commence une première analyse :

Une story développée doit avoir une validation fonctionnelle sur le serveur de recette et technique par une revue de code. L’équipe aime bien valider le scénario de démo avec Pauline. Il faut donc trois intervenants pour cette phase de revue : le Product Owner, le développeur faisant la revue et le développeur corrigeant les retours techniques ou fonctionnels.

Le risque d’attente entre ces trois intervenants est fort. Cela expliquerait que les stories restent plus longtemps qu’elles ne le devraient en revue et donc que la limite de quatre soit rapidement atteinte.

Travailler sur ce gaspillage avec l’équipe devrait permettre de réduire la limite à trois ou deux. C’est en tout cas ce qu’elle espère.

Dans le prochain épisode MyProjectStuff, l’équipe Aldébaran analyse les diagrammes de flux cumulés du sprint 3 lors de la rétrospective Scrum.