Catégorie : Scrum

Cela devait bien arriver et c’est malheureusement arrivé !

Il y a 4 mois, J’ai coaché un projet en interne (durant 3 sprints de 2 semaines) pour aider les équipes à gagner en maturité sur la méthode Scrum que l’équipe utilisait depuis 3 mois. Je considère que ce coaching a porté ses fruits puisque l’équipe a pris conscience de certains de ses dysfonctionnements et a cherché à y remédier par elle même avec mon support. Le motivation de l’équipe était alors très bonne et la productivité supérieure à ce qu’elle avait été (bien que nous ne disposions pas de métriques fiables – comme une mesure régulière de la vélocité)

Aujourd’hui, force est de constater que ce projet s’éloigne de la méthode Scrum. Ce n’est pas encore visible sur la forme car l’équipe parle encore de Sprint, de « Scrum of Scrum » et fait des rétrospectives, mais sur le fond tout est changé et je vais me permettre de donner ma vision personnelle des raisons qui ont conduit à cela.

1. Le management n’a pas eu suffisamment confiance dans la réussite de l’équipe auto-pilotée et a (re)commencé à faire du micro management pour se rassurer car lui aussi subit une très forte pression de la part de son management pour délivrer à temps
2. Le conflit de priorité entre Produit (nouvelles fonctionnalités) et Engineering (Stabilité) n’a pas été résolu. La méthode Scrum oblige à prendre une décision, à la rendre visible dans le backlog et permet de focaliser les énergies sur 1 objectif commun. Plutôt que de prendre des décisions difficiles et lourdes de conséquences, les 2 entités ont préféré masquer le problème en changeant leur façon d’utiliser le Product Backlog et disant « on va faire un peu des 2 ». Le problème est toujours présent … mais comme on le voit moins, certaines personnes pensent qu’il est résolu (qui a dit que les managers croyaient en la Magie ?).
3. Le micro management s’est traduit par un contrôle journalier de l’équipe sur la réalisation de tâches unitaires suivant un processus par étapes remis à l’ordre du jour (abandon du concept de sprint et surtout de ‘done’ en fin de sprint).
4. Contrairement à la volonté de l’équipe, les ressources sont affectés à des tâches précises et chacun est responsable de sa partie. Fini l’engagement de l’équipe à délivrer itérativement quelque chose qui marche, voilà le retour de la justification individuelle !
5. La plus grande partie du reporting actuel consiste à expliquer pourquoi l’avancement du projet n’est pas conforme à la roadmap définie initialement par … quelqu’un … sans implication de l’équipe. La seule question posée actuellement est « pour quand ce sera prêt ? » plutôt que « comment je peux t’aider à résoudre tes problèmes ? ».

Attention, mon propos n’est pas de dire que la méthode utilisée (Waterfall couplée à du micro-management) est mauvaise car je suis convaincu que l’équipe va délivrer les fonctionnalités demandées (j’ai moi-même utilisée cette méthode avec succès dans le passé). Mais comme pour la plupart des projets dans ce mode, ce sera avec du retard et avec un niveau de qualité non optimal (et cela devient déjà visible sur ce projet).

Mais je suis également convaincu qu’une approche Agile avec Scrum aurait permis de délivrer plus vite un produit de meilleure qualité. Car une équipe motivée, travaillant par petits incréments avec des objectifs clairs et partagés, est la plus grande chance de réussite d’un projet. Donc plutôt que de se concentrer sur le ‘pourquoi ca n’a pas marché’ il est plus important de se focaliser sur le ‘que reste-t-il à faire pour finir’.

Comme axe d’amélioration personnel, j’en retire qu’un coaching au niveau de hiérarchie supérieure aurait peut-être permis d’utiliser Scrum suffisamment longtemps pour prouver son efficacité et convaincre cette hiérarchie.

On apprend beaucoup de ses erreurs et puis il n’est pas dit que ce projet ne puisse pas revenir à l’agilité d’ici quelques mois, restons optimistes !