La fable du middle manager et de l’agilité

Il était une fois un manager qui encadrait des développeurs. Dans son entreprise, c’était un peu la chaos suite à une croissance rapide. Des chefs de projets fonctionnels écrivaient des spécifications fonctionnelles en fonction de ce que leur racontaient les équipes métier ; les managers des dev se distribuaient entre eux ces spec, puis chacun essayait d’assigner les tâches à ses développeurs en fonction de ses propres estimations. Après, chaque mois, on essayait de packager ces projets ensembles, pour sortir une nouvelle version du site, et toujours avec quinze jours de retard, parce que ce n’est pas simple à synchroniser tout ça. Dans ce contexte, les demandeurs et les développeurs ne se voyaient jamais, bien que travaillant les uns juste au dessus des autres.

Un jour, ce manager a rencontré un autre manager d’une autre entreprise, qui lui raconta comment ils essayaient de mettre en place Scrum. Ce fut une révélation. Un an après, toutes les équipes avaient été réorganisées en feature teams, chacune avec leur PO, leur PO adjoint, leur scrum master (éventuellement tournant). Les développeurs s’appropriaient leur feature, et ceux qui ne voulaient pas travailler en équipe, refusaient le management visuel ou la relecture de code avaient même donné leur démission ! Chaque équipe avait sa propre Definition of Done. Chaque équipe connaissait sa valeur, ses KPI. Des démos étaient faites tous les quinze jours à l’ensemble des équipes métier concernées par les évolutions. On récoltait du feed back. On pouvait répondre sereinement aux chefs qu’il n’y avait aucun problème pour changer les priorités à deux semaines.

L’histoire qu’il raconte alors, c’est comment les principes agiles permettent avant tout de réorganiser l’équipe de dev, en la responsabilisant, et font en sorte que les changements de priorités soient gérés dans un comité ad-hoc, et non plus subis par le management ou par l’équipe. Bref, c’est faire en sorte que les équipes de dev soient heureuses.