TL;DR
La capacité du pôle développement partagé allait au plus insistant, et une unité décrochait sur sa feuille de route. Scrum a été appris en une semaine, adapté à une micro-équipe de trois unités, puis laissé en place. La méthode a survécu au sauvetage.
Situation à mon arrivée
La maison mère faisait passer le développement web par un petit pôle au service de trois business units. Un développeur principal, fraîchement recruté et aidé d’un apprenti, portait tout, fixant lui-même son temps, sa planification et ses tickets, sans système partagé.
- Pas de file partagée, donc rien ne fixait l’ordre.
- Pas d’arbitrage, donc la priorité allait à la voix la plus forte.
- Un développeur pour trois unités, donc les demandes urgentes déplaçaient les tickets planifiés.
Il ne pouvait pas dire non, si bien que tout chef de projet insistant obtenait son ticket urgent ; le défaut était structurel, pas dans sa bonne volonté. Une unité, Astrocenter, restait sur sa feuille de route au lieu de réclamer et prenait du retard, ce qui pénalisait sa performance. J’étais responsable de cette unité, et c’est la configuration d’une mission du type sauvetage et redressement.
Le diagnostic
Le symptôme visible était le retard d’Astrocenter. La cause était l’absence de toute structure partagée de priorisation. Faute d’arbitrage, la capacité allait à la voix la plus forte, et l’unité qui tenait sa feuille de route au lieu de pousser s’en trouvait privée. C’est un défaut structurel, pas une défaillance des personnes ; insister davantage auprès du développeur n’aurait fait que déplacer l’injustice. Lire la situation comme une question de structure, et non comme celle d’un développeur lent, a ouvert la suite : l’équipe avait besoin d’une façon de décider, pas de plus d’efforts.
Le plan d’actions
L’expédient en place était la persuasion personnelle : les chefs de projet obtenaient leur créneau en pressant directement le développeur. Ce raccourci a été écarté, car c’est cette pression qui avait produit l’injustice.
Scrum et l’Agile n’étaient connus que par quelques notions. L’ouvrage de référence a été acheté et, en une semaine, un modèle écrit pour des équipes bien plus grandes a été adapté à une micro-équipe de trois Product Owners et deux développeurs, tout en continuant à piloter la mienne. C’est la part autodidacte du Bâtisseur tous terrains. Le rôle de Scrum Master a été endossé, et comme la mienne était l’une des trois, un manager de celle-ci a été placé comme Product Owner afin de ne pas être juge et partie. L’équipe a fait vivre le dispositif.
Mise en œuvre
Le système comptait huit volets, chacun répondant à ce qui manquait à l’organisation précédente.
- Des sprints de quinze jours, un rythme fixe à la place d’une file ouverte.
- Une feuille de priorités par Product Owner, tenue dans Google Sheets et remplie avant chaque sprint, pour que la préséance soit écrite et non négociée à la voix.
- L’estimation par le développeur principal, qui pesait chaque demande en faisabilité et en temps nécessaire.
- Des tickets rédigés par le développeur lui-même dans Jira, pour que la maîtrise reste à celui qui fait le travail.
- Une charte de bonne conduite signée par tous, interdisant les urgences forcées hors de la chaîne.
- Une rétrospective à chaque fin de sprint, enchaînée sur la planification suivante, avec une réunion de préparation en amont avec chaque Product Owner.
- Une capacité priorisée par les objectifs à moyen terme et les projets de fondation, et non par un quota de points fixe.
- Une répartition permanente entre travail de fondation et nouvelles demandes, gardant de la marge pour les corrections de bugs.
Des difficultés réelles
La mise en place n’a pas été propre. La méthode a été apprise en la conduisant, un modèle conçu pour de grandes équipes a été transposé à une micro-équipe de trois Product Owners, et une partie n’a pas collé au départ. Le problème de neutralité était réel : mon unité était l’une des trois, et la désignation du Product Owner et la charte ont été conçues pour y répondre. Ce document existe parce que forcer des tickets avait été l’abus courant, et cela n’a pas été dissimulé. La méthode reposait sur ma conduite de Scrum Master avant de pouvoir s’alléger et laisser l’équipe la tenir.
Résultat
Observé en un mois : les équipes étaient plus sereines, les projets avançaient en parallèle, et aucune business unit n’avait de reproche à formuler ; la direction était soulagée. Observé sur plusieurs mois : le rôle de Scrum Master a été allégé et davantage d’autonomie donnée au développeur principal, tout en veillant à ce que les principes et la charte tiennent.
La pérennisation : la méthode a été conservée aussi longtemps que le groupe en a eu besoin, et sa direction informatique n’a jamais imposé les règles Scrum plus strictes en vigueur dans le reste de ses équipes. Elle est restée le système de l’équipe pendant des années après mon retrait. Un sauvetage laissé en marche sans moi, c’est ce que raconte la page Qui suis-je ?.
Vous faites face à une capacité de développement qui va au plus insistant ? Parlons-en.