agilité, transformation, décision, organisation, frictions
agilité, transformation, décision, organisation, frictions
La méthode agile a-t-elle réellement accéléré la prise de décision en entreprise ?
La méthode agile a-t-elle réellement accéléré la prise de décision en entreprise ?
Les frameworks agiles promettaient la vitesse. Sprints, cérémonies, backlogs : un lexique entier s'est installé dans les équipes. Et pourtant les organisations les mieux équipées en rituels agiles ne sont pas les plus rapides à décider. La recherche le documente depuis quinze ans, sans que ce constat quitte le champ académique.
Les frameworks agiles promettaient la vitesse. Sprints, cérémonies, backlogs : un lexique entier s'est installé dans les équipes. Et pourtant les organisations les mieux équipées en rituels agiles ne sont pas les plus rapides à décider. La recherche le documente depuis quinze ans, sans que ce constat quitte le champ académique.
C'est presque caricatural, mais on tient un stand-up pour décider quand tenir la vraie réunion. On affine un backlog pour savoir quoi inclure dans le prochain backlog. La cérémonie a pris la place de l'acte.
C'est presque caricatural, mais on tient un stand-up pour décider quand tenir la vraie réunion. On affine un backlog pour savoir quoi inclure dans le prochain backlog. La cérémonie a pris la place de l'acte.
C'est presque caricatural, mais on tient un stand-up pour décider quand tenir la vraie réunion. On affine un backlog pour savoir quoi inclure dans le prochain backlog. La cérémonie a pris la place de l'acte.
L'agilité est devenue une religion organisationnelle. Elle a ses textes fondateurs, ses officiants certifiés, ses rituels hebdomadaires. Ce que cette institutionnalisation a produit mérite d'être regardé en face.
Un framework agile répond à un problème réel : réduire l'écart entre ce qui est décidé en haut et ce qui se passe en bas. La logique est juste. Mais chaque couche de méthode ajoutée pour gagner en agilité est aussi une couche de coordination supplémentaire à gérer. SAFe structure les dépendances entre les équipes, puis organise ses propres réunions de synchronisation entre elles. Les OKR alignent les objectifs, puis produisent des cycles de reporting qui consomment le temps qu'ils étaient censés libérer. Aucune de ces réunions n'est une erreur d'exécution. C'est la mécanique normale de tout système de coordination : il coûte ce qu'il prétend économiser, dès qu'il atteint une certaine taille.
Ce décalage entre la promesse et l'observation est mesuré. Moe, Aurum et Dybå ont suivi quatre projets en Scrum dans deux entreprises passées : il faudra 1 à 2 ans pour passer d'une décision hiérarchique à une décision réellement partagée. La même année, Drury, Conboy et Power examinaient les décisions prises aux quatre étapes du cycle d'itération. Trois effets ressortent : une perte de perspective stratégique à long terme, un stock croissant de travail reporté d'une itération à l'autre, et un désengagement des équipes. Le sprint accélère ce qu'il contient et refoule ce qu'il ne sait pas traiter.
Le mécanisme invoqué pour justifier la vitesse est lui-même fragile. Eisenhardt observait en 1989 que les décideurs les plus rapides mobilisent plus d'informations que les décideurs lents, et développent plus d'alternatives, pas moins. La vitesse tient à la façon dont le débat est organisé et tranché. Retirer des comités ne la produit pas.
La vraie agilité n'est donc pas une méthode. C'est la capacité de décider avec peu d'informations, sans attendre la prochaine cérémonie pour le faire. Cette capacité ne se décrète pas dans un framework. Elle suppose que les personnes proches du terrain disposent à la fois de l'information utile et de l'autorisation réelle d'agir. Quand ces deux conditions sont absentes, la méthode agile produit de la vitesse apparente, pas de la vélocité décisionnelle : les sprints s'enchaînent, les arbitrages s'accumulent.
Un framework agile répond à un problème réel : réduire l'écart entre ce qui est décidé en haut et ce qui se passe en bas. La logique est juste. Mais chaque couche de méthode ajoutée pour gagner en agilité est aussi une couche de coordination supplémentaire à gérer. SAFe structure les dépendances entre les équipes, puis organise ses propres réunions de synchronisation entre elles. Les OKR alignent les objectifs, puis produisent des cycles de reporting qui consomment le temps qu'ils étaient censés libérer. Aucune de ces réunions n'est une erreur d'exécution. C'est la mécanique normale de tout système de coordination : il coûte ce qu'il prétend économiser, dès qu'il atteint une certaine taille.
Ce décalage entre la promesse et l'observation est mesuré. Moe, Aurum et Dybå ont suivi quatre projets en Scrum dans deux entreprises passées : il faudra 1 à 2 ans pour passer d'une décision hiérarchique à une décision réellement partagée. La même année, Drury, Conboy et Power examinaient les décisions prises aux quatre étapes du cycle d'itération. Trois effets ressortent : une perte de perspective stratégique à long terme, un stock croissant de travail reporté d'une itération à l'autre, et un désengagement des équipes. Le sprint accélère ce qu'il contient et refoule ce qu'il ne sait pas traiter.
Le mécanisme invoqué pour justifier la vitesse est lui-même fragile. Eisenhardt observait en 1989 que les décideurs les plus rapides mobilisent plus d'informations que les décideurs lents, et développent plus d'alternatives, pas moins. La vitesse tient à la façon dont le débat est organisé et tranché. Retirer des comités ne la produit pas.
La vraie agilité n'est donc pas une méthode. C'est la capacité de décider avec peu d'informations, sans attendre la prochaine cérémonie pour le faire. Cette capacité ne se décrète pas dans un framework. Elle suppose que les personnes proches du terrain disposent à la fois de l'information utile et de l'autorisation réelle d'agir. Quand ces deux conditions sont absentes, la méthode agile produit de la vitesse apparente, pas de la vélocité décisionnelle : les sprints s'enchaînent, les arbitrages s'accumulent.
L'agilité mesure la vitesse des rituels, non la vitesse des décisions.
L'agilité mesure la vitesse des rituels, non la vitesse des décisions.
Point de vue
Point de vue
L'agilité mesure la vitesse des rituels, non la vitesse des décisions.
Point de vue
Avant de revoir la méthode, il est possible de poser une question plus simple : où se forment les embouteillages décisionnels ?
Ils prennent trois formes, et aucune n'apparaît dans les slides de la revue de sprint. La première est une dépendance entre équipes que personne n'arbitre : deux équipes autonomes attendent chacune la décision de l'autre, et le sujet revient à l'ordre du jour de la synchronisation pendant six semaines. La deuxième est un outil qui impose une double saisie : le temps perdu ne se voit nulle part, car il est réparti entre trente personnes, quelques minutes chacune, tous les jours. La troisième est une règle d'escalade qui envoie l'arbitrage vers un niveau qui n'a pas le contexte nécessaire pour trancher : la décision remonte, redescend en question, puis remonte à nouveau.
Ces trois blocages ont un point commun. Ils sont parfaitement connus des personnes qui font le travail, et invisibles dans les instances qui pilotent la méthode. La revue de sprint mesure ce qui a été livré. Elle ne mesure pas ce qui a attendu.
Spentia conduit un entretien individuel confidentiel de trente minutes avec chaque collaborateur du périmètre. Le format compte autant que la question : en atelier collectif, un blocage qui implique le niveau au-dessus se raconte rarement. Le fait de couvrir l'intégralité du périmètre compte aussi, car une friction se reconnaît à sa récurrence. Un témoignage isolé est une anecdote. Le même irritant, décrit par vingt personnes à l'aide de termes différents, est une cause racine.
En quatre semaines, la cartographie ressort chiffrée en euros par an, chaque friction rattachée à ce qui la produit : une règle, un outil, une frontière d'équipe, un pouvoir de décision mal attribué.
Ce que produit le livrable, c'est un tri. Les frictions qu'une règle réécrite fait disparaître la semaine suivante, et celles qui nécessitent un véritable arbitrage de la part de la direction. Les premières se traitent sans toucher au framework. Les secondes indiquent où l'autorité de décision doit être déplacée pour que la méthode tienne enfin sa promesse.
Sources
Moe, N. B., Aurum, A. & Dybå, T. (2012). Challenges of shared decision-making: a multiple case study of agile software development. Information and Software Technology, 54(8), 853-865. https://doi.org/10.1016/j.infsof.2011.11.006
Drury, M., Conboy, K. & Power, K. (2012). Obstacles to decision making in Agile software development teams. Journal of Systems and Software, 85(6), 1239-1254.
Eisenhardt, K. M. (1989). Making fast strategic decisions in high-velocity environments. Academy of Management Journal, 32(3), 543-576. https://doi.org/10.5465/256434
Avant de revoir la méthode, il est possible de poser une question plus simple : où se forment les embouteillages décisionnels ?
Ils prennent trois formes, et aucune n'apparaît dans les slides de la revue de sprint. La première est une dépendance entre équipes que personne n'arbitre : deux équipes autonomes attendent chacune la décision de l'autre, et le sujet revient à l'ordre du jour de la synchronisation pendant six semaines. La deuxième est un outil qui impose une double saisie : le temps perdu ne se voit nulle part, car il est réparti entre trente personnes, quelques minutes chacune, tous les jours. La troisième est une règle d'escalade qui envoie l'arbitrage vers un niveau qui n'a pas le contexte nécessaire pour trancher : la décision remonte, redescend en question, puis remonte à nouveau.
Ces trois blocages ont un point commun. Ils sont parfaitement connus des personnes qui font le travail, et invisibles dans les instances qui pilotent la méthode. La revue de sprint mesure ce qui a été livré. Elle ne mesure pas ce qui a attendu.
Spentia conduit un entretien individuel confidentiel de trente minutes avec chaque collaborateur du périmètre. Le format compte autant que la question : en atelier collectif, un blocage qui implique le niveau au-dessus se raconte rarement. Le fait de couvrir l'intégralité du périmètre compte aussi, car une friction se reconnaît à sa récurrence. Un témoignage isolé est une anecdote. Le même irritant, décrit par vingt personnes à l'aide de termes différents, est une cause racine.
En quatre semaines, la cartographie ressort chiffrée en euros par an, chaque friction rattachée à ce qui la produit : une règle, un outil, une frontière d'équipe, un pouvoir de décision mal attribué.
Ce que produit le livrable, c'est un tri. Les frictions qu'une règle réécrite fait disparaître la semaine suivante, et celles qui nécessitent un véritable arbitrage de la part de la direction. Les premières se traitent sans toucher au framework. Les secondes indiquent où l'autorité de décision doit être déplacée pour que la méthode tienne enfin sa promesse.
Sources
Moe, N. B., Aurum, A. & Dybå, T. (2012). Challenges of shared decision-making: a multiple case study of agile software development. Information and Software Technology, 54(8), 853-865. https://doi.org/10.1016/j.infsof.2011.11.006
Drury, M., Conboy, K. & Power, K. (2012). Obstacles to decision making in Agile software development teams. Journal of Systems and Software, 85(6), 1239-1254.
Eisenhardt, K. M. (1989). Making fast strategic decisions in high-velocity environments. Academy of Management Journal, 32(3), 543-576. https://doi.org/10.5465/256434
