On a acheté l'agilité. On a oublié de changer nos façons de faire : récit d'une transformation agile
Une organisation de taille moyenne est venue nous voir un an après le début de ce qu'elle appelait une transformation agile. Elle avait formé les gens, acheté des outils et rebaptisé chaque groupe « équipe Scrum ». Pourtant, la livraison ne semblait pas plus rapide et le personnel était épuisé. Le résumé honnête d'un chef d'équipe, au début de 2021 lors d'un appel vidéo, fut : « On fait toutes les réunions, maintenant, et rien n'a changé. »
Le récit ci-dessous est anonymisé et assemblé à partir de plusieurs mandats, mais ce mode d'échec est l'un des plus courants dans l'adoption de Scrum. Ils avaient copié les cérémonies de Scrum sans en adopter le but. Cela s'appuie sur le Guide Scrum, qui décrit Scrum comme un cadre fondé sur l'empirisme, et non comme une série de réunions à exécuter.
Les symptômes d'une transformation de nom seulement
En surface, tout avait l'air agile. En dessous, les vieilles habitudes de commande et de contrôle étaient intactes, simplement vêtues d'un nouveau vocabulaire.
Le Scrum quotidien était devenu une réunion de statut où les développeurs faisaient rapport au gestionnaire, plutôt qu'un plan, entre développeurs, pour leur propre journée.
Les revues de sprint montraient des diapositives au lieu d'un produit fonctionnel, de sorte qu'aucune véritable rétroaction ne pouvait circuler.
Le Product Owner ne pouvait pas vraiment décider des priorités; un comité directeur renversait le backlog chaque mois.
Les sprints étaient planifiés d'abord selon l'échéance, puis remplis de tout ce qui pouvait y entrer, si bien que l'équipe était en retard dès le premier jour.
Ce sont les signes d'une exécution mécanique. Les événements étaient à l'agenda, mais l'empirisme qui les sous-tend, inspecter de vrais résultats et s'adapter, n'avait jamais lieu. Le travail à distance et hybride étant encore nouveau pour plusieurs, les réunions devenaient aussi le seul contact, ce qui les rendait encore plus lourdes.
Ce qui a changé la trajectoire
Nous n'avons pas ajouté plus de Scrum. Nous avons fait en sorte que le Scrum existant signifie vraiment quelque chose, une contrainte à la fois, avec la direction présente pour les parties difficiles.
Donner au Product Owner une réelle autorité. La direction a convenu que le Product Owner était maître de l'ordonnancement du Product Backlog, point final. Le comité directeur s'est recentré sur les objectifs et le financement, et non sur la réorganisation du travail en plein sprint.
Faire en sorte que la revue de sprint montre un logiciel fonctionnel. Plus de diaporamas. Les parties prenantes voyaient un incrément fonctionnel et donnaient une rétroaction qui alimentait le sprint suivant. Une rétroaction sur laquelle on peut agir, c'est tout l'intérêt de l'inspection à la revue.
Laisser l'équipe planifier vers un objectif de sprint, pas une liste de souhaits. Chaque sprint s'engageait sur un seul objectif clair et une prévision choisie par l'équipe. La portée s'ajustait pour protéger l'objectif, c'est ainsi que Scrum est censé gérer la pression.
Redéfinir le Scrum Master comme un coach, non un coordonnateur. Nous avons retiré les Scrum Masters de la réservation de salles pour les amener à lever les obstacles systémiques, comme la chaîne d'approbation qui étouffait le Product Owner.
Les progrès furent inégaux et certains gestionnaires ont peiné à lâcher prise. Mais en quelques trimestres, les équipes livraient des incréments plus petits, plus souvent, et l'épuisement s'est atténué parce que c'était enfin le travail, et non la cérémonie, qui comptait.
La leçon à retenir
Une transformation agile n'est pas un déploiement de réunions ou d'outils; c'est un changement dans la façon dont les décisions se prennent et dans la vitesse à laquelle on apprend des résultats réels. Les événements de Scrum ne créent de la valeur que lorsque l'empirisme sous-jacent est réel. Si votre Scrum quotidien est un rapport de statut et votre revue un diaporama, vous n'avez pas encore Scrum, peu importe ce que dit l'agenda. Commencez par rendre un seul événement vraiment honnête, et laissez-le entraîner le reste.
Si votre transformation agile a les cérémonies mais pas les résultats, le service-conseil en réalisation de programmes et de projets de XNM peut vous aider à retransformer les gestes en agilité réelle et opérante.