Chers collègues,
J’ai le plaisir de vous annoncer que j’ai atteint les objectifs fixés par la direction et que l’équipe que je pilote est désormais “agile”. Afin d’aider d’autres équipes à passer ce cap difficile, je vous livre mon retour d’expérience sur cette transformation.
Septembre 2019, en tant que manager de l’équipe, j’ai partagé avec elle l’objectif de l’année : devenir agile ! J’ai donc demandé à l’équipe de suivre la méthode SCRUM. J’ai laissé l’équipe élire son Scrum Master : c’est Gérard, notre développeur PHP, qui était en congés ce jour-là qui a été choisi.
Notre analyste fonctionnel a pris le rôle de Product Owner. Nous avons mis en place un backlog dans JIRA afin de piloter facilement le traitement des User Stories. Le passage en agilité l’a peu impacté dans son travail. Il continue de fournir à notre équipe des spécifications classiques. Le Product Owner et l’équipe ont un lien fort. Les développeurs contactent régulièrement le Product Owner pour récupérer les informations manquantes qui les empêchent d’avancer dans leur travail.
Le Scrum Master, en plus de son rôle de développeur, a eu pour mission d’organiser des cérémonies. Je lui ai vivement conseillé de partir sur des itérations d’un mois afin qu’on ne perde pas trop de temps avec ces réunions. Nous organisons donc une démonstration où les membres de l’équipe se démontrent les user stories réalisées durant le mois. Ensuite, nous réalisons une rétrospective. Je reste en spectateur pour valider que l’équipe pointe bien leurs erreurs et ne cherchent pas à rejeter la faute sur le management mais aussi pour leur rappeler le budget serré et les fortes attentes de nos clients. Enfin, le Product Owner présente, pendant le sprint planning, la roadmap avec les projets à réaliser dans les trois mois à venir. Cela lui permet de partager avec l’équipe le budget alloué et les jalons de livraison. Ils ont une bonne vision des projets à venir !
L’équipe est, bien sûr, pluridisciplinaire :
- Cinq personnes sont dédiées à la conception des solutions.
- Dix développeurs peuvent implémenter les conceptions faites par leurs collègues quand elles sont finalisées. Chacun a son périmètre technique, cela nous permet d’avoir une vraie expertise ! Pour faciliter l’organisation du travail, les développeurs créent eux même les user stories afin qu’elles s’adaptent aux périmètres techniques de chacun et que tous puissent donc travailler en toute autonomie.
- Deux personnes gèrent les anomalies. C’est un choix stratégique de ma part car je juge qu’ils n’ont pas la compétence pour travailler sur des évolutions.
Concernant les livraisons, nous ne livrons pas à chaque itération. Il faut qu’on attende d’avoir réalisé l’ensemble des user stories avant de pouvoir livrer, sinon cela n’a pas de sens. Nous essayons de regrouper la livraison de plusieurs projets afin de diminuer les coûts de livraison. Il faut dire qu’une livraison nous prend actuellement un mois !
L’équipe tient ses engagements ! Cela s’explique notamment grâce au pilotage que nous avons mis en place sur le projet. Le chef de projet met à jour quotidiennement l’avancement des projets traités par l’équipe. Le daily lui permet de distribuer les tâches et de valider quotidiennement que chacun avance bien sur la tâche qui lui est attribuée . Et, il faut l’avouer, le travail du chef de projet me rassure. Il me fournit les indicateurs qui me permettent de suivre sereinement la consommation du budget.
Bien sûr, nous travaillons avec les points de complexité. L’un de nos développeurs estime la complexité de chaque user story à sa création. En fonction du nombre de jours disponibles dans l’itération, nous pouvons donc connaître le nombre d’US que l’on est capable d’embarquer. Pour simplifier les calculs, nous partons du principe qu’un point représente un jour/homme. Grâce à ma capacité à motiver l’équipe, nous arrivons toujours à tenir l’engagement même si cela nécessite quelques soirée au boulot. Et, entre nous, je suis assez fière de constater que mon équipe a une vélocité plus importante que l’équipe dans le bureau d’à côté ! Cela me conforte dans ma stratégie de management et dans l’implication de mes équipiers.
Un coach agile est venu faire un bilan de notre transformation. Vous allez rire ! Encore un qui est arrivé avec sa théorie et qui n’a pas compris les spécificités de notre produit.
- Nous ne pouvons pas avoir une “Definition of Done” partagée par l’équipe puisque cela va dépendre du périmètre technique de chacun. On ne va pas s’amuser à faire une DoD par développeur.
- On est là pour produire ! On a des clients à livrer nous ! Dédier du temps pour retravailler du code et améliorer la qualité du produit ?! Aucun client ne voudra financer ce caprice. Challenger les solutions demandées par nos clients ?! Nos clients connaissent leurs besoins et, surtout, c’est eux qui nous fournissent le budget.
- Et la cerise sur la gâteau : il voulait qu’on mette en place des indicateurs sur l’utilisation de nos fonctionnalités en production. Vraiment, il doit s’ennuyer ce coach ! Pour savoir si nos clients sont satisfaits, on fait attention à respecter les jalons de livraison. La vie de la production n’est pas notre problème !
Chers collègues, comme vous pouvez le constater, je peux dire avec fierté que mon équipe a réussi ce challenge de la transformation agile. Pour les autres managers qui, comme moi, doivent transformer leur équipe, je vous partage donc mon retour d’expérience. Voila, je suis assez surprise du résultat voire même déçue. Nous avons appliqué à la lettre la méthode SCRUM et je ne vois pas le gain. On perd énormément de temps en réunion et les développements ne sont pas plus rapides qu’avant !
De plus, cette transformation a fatigué mon Scrum Master. Il a fait beaucoup de formations pour avoir cette casquette et je le trouve maintenant très négatif sur notre organisation. Il est temps qu’il prenne des vacances !
N’hésitez pas à revenir vers moi si vous avez des interrogations.
Cordialement,
Muriel, Manager d’équipe.
(Sinon moi c’est Charline Renart, Agiliste chez Valeuriad et un peu fatiguée des projets “fragiles” 🙂 )
