Gouvernance agile : quand l’agilité masque les vrais problèmes d’organisation

Dans de nombreuses organisations, l’agilité est introduite pour gagner en efficacité, en réactivité et en autonomie. 

Sur le papier, les rituels sont en place, les rôles sont définis et les équipes travaillent en itérations. Dans la réalité, certains dysfonctionnements persistent. Et bien sûr, ils ne viennent ni des outils ou frameworks mais d’un sujet moins visible au premier abord, la gouvernance.

Dans mes précédents articles sur les transformations agiles, j’ai souvent insisté sur le fait que ce sont les comportements et les décisions qui transforment une organisation et non pas les frameworks.

Pour comprendre ce phénomène, nous allons d’abord regarder comment l’agilité est mise en place dans les organisations et les écarts que l’on observe entre théorie et réalité.

On verra ensuite les différents types de dérives de gouvernance que cela peut masquer, avant d’identifier les leviers concrets pour rétablir un cadre clair sans renoncer aux principes agiles.

Pourquoi certaines organisations appliquent mal l’agilité

Avant de parler de gouvernance, il faut reconnaître que de plus en plus d’organisations ne partent pas de zéro.

Les équipes utilisent Scrum pour organiser leur travail. 

À l’échelle, des cadres comme SAFe sont souvent déployés. 

Les rituels sont connus : daily, sprint review, rétrospective, PI Planning, ART Sync, ... 

Le vocabulaire est généreusement partagé.

Vu de l’extérieur, tout semble fonctionner.

Mais dès que l’on regarde de plus près, un décalage apparaît, comme souvent quand on creuse d’ailleurs.

Par exemple, dans certaines équipes, la daily devient un point de suivi où chacun rend compte de son activité. 

Le Product Owner, parfois ancien chef de projet, attend un niveau de détail proche d’un reporting classique.

À l’échelle, certains événements sont adaptés, voire supprimés. 

Par exemple :

Retirer le Sprint d’Innovation & de Planification au motif qu’il ne produit pas directement de valeur peut sembler pragmatique. 

C’est souvent le signe que l’on privilégie l’exécution à court terme, au détriment du pilotage global.

Ces ajustements traduisent une manière de faire de l’agilité sans remettre en question certaines logiques existantes. 

Et c’est là que la question de la gouvernance commence à apparaître.

Une gouvernance floue : « Y a-t-il un pilote dans l’avion ? »

Dans plusieurs accompagnements, le premier signal n’est pas un problème d’organisation, mais un problème de clarté.

• Mais qui décide des priorités ? « Les product owners, mais comme ils ne sont pas souvent disponibles (car c’est juste une casquette), ce sont des Business Analysts qui tranchent souvent. »
• Qui arbitre en cas de conflit ? « Ca dépend. Et puis on n'a pas de conflit car on est agile.»
• Qui porte réellement la vision produit ? «  C’est quoi ce truc ? »

En théorie, les rôles existent mais en pratique, les responsabilités sont souvent ambiguës.

Un exemple revient régulièrement : l’absence de roadmap.

Certains Product Owners évitent de se projeter, au nom de l’adaptabilité.

Dans le même temps, les attentes en matière de reporting restent fortes avec suivi d’avancement, engagement sur des délais, visibilité pour le management.

Ce décalage crée une situation inconfortable pour les équipes car elles avancent, produisent, livrent mais sans toujours comprendre la direction globale qui devrait être impulsée par le PO.

Et comme souvent, sans cadre explicite, les décisions se prennent au fil de l’eau.Et lorsqu’un problème apparaît, il devient difficile de savoir qui doit trancher.

Dans ce contexte, l’agilité ne simplifie pas la gouvernance et la rend plus floue.

Quand l’agilité remplace le cadrage stratégique

Deuxième situation fréquente : des projets lancés avec un cadrage insuffisant.

La vision est encore floue. 

Les objectifs ne sont pas réellement priorisés. 

Les arbitrages structurants n’ont pas été faits.

Dans ce contexte, l’agilité est souvent perçue comme la solution parfaite. On va avancer par itérations, ajuster progressivement, laisser l’équipe construire.

Dans certains cas, cela fonctionne.

Mais lorsque le cadrage est trop faible, les équipes se retrouvent à compenser le manque de vision par des arbitrages incessants.

On se retrouve rapidement avec des sprints qui changent de contenu en permanence.

Le problème n’est pas l’incertitude car elle fait partie du jeu. Le problème, c’est l’absence de direction, l’étoile du nord qui oriente le produit.

L’agilité permet de gérer l’incertitude mais pas l’absence de cadrage.

Agile washing : des transformations agiles seulement en apparence

Troisième cas, plus subtil : les réorganisations « agiles ».

Sur le papier, elles s’inspirent de modèles et patterns connus. 

Organisation en tribus, squads, chapters, répartition des responsabilités, mise en avant de l’autonomie.

Dans la réalité, ces modèles sont souvent adaptés pour intégrer l’existant.

On voit apparaître des binômes à la tête des équipes ou des tribus, combinant responsabilité produit et responsabilité technique. 

Les rôles de management sont repositionnés pour conserver les équilibres historiques. 

Les Chapter Leads existent parfois mais sans pouvoir de management.

Ces choix peuvent se comprendre car ils permettent de sécuriser une transformation et de repositionner des profils expérimentés, mais ils créent aussi de la confusion.

Les équipes ne savent plus toujours à qui se référer et les décisions restent concentrées mais moins visibles. 

L’organisation change juste en apparence et les équipes ont l’impression d’être les dindons de la farce.

Adapter un modèle est nécessaire sinon on va traiter le coach agile de dogmatique. Mais le dénaturer pour préserver l’existant l’est beaucoup moins.

Comment rétablir une gouvernance agile efficace

Face à ces situations, la réponse n’est pas de “faire plus d’agile” mais consiste à remettre de la clarté et du bon sens là où ils manquent cruellement.

Et la bonne nouvelle c’est que nous avons des leviers concrets à notre disposition.

1) Clarifier les responsabilités dans une organisation agile

Lorsque les décisions restent implicites, les tensions montent assez vite. 

Les équipes ne savent pas toujours jusqu’où elles peuvent décider seules, ni quand elles doivent demander validation. Et ce flou finit par créer des malentendus assez classiques.

C’est souvent là que des approches issues de Management 3.0 peuvent aider.Le Delegation Poker, par exemple, sert simplement à mettre à plat le niveau de délégation sur un sujet. 

Est-ce que c’est une décision du manager, une décision partagée ou une décision portée par l’équipe ? Le fait d’en parler collectivement change déjà beaucoup de choses.

Dans le même esprit, la Give & Take Matrix permet de regarder un peu plus la réalité du terrain que ce qui est écrit dans une matrice RACI. 

Le RACI dit “qui est responsable”, mais ce n’est pas toujours aussi propre. 

La Give & Take Matrix permet de regarder les responsabilités telles qu’elles sont réellement vécues. 

L’idée est de distinguer ce que les personnes “donnent” dans l’organisation (ce qu’elles portent, ce qu’elles décident, ce sur quoi elles influencent) et ce qu’elles “reçoivent” en termes de responsabilités ou de contraintes. 

Cela met souvent en évidence des écarts entre le rôle théorique et ce qui se passe au quotidien.

L’idée est de remettre un peu de clarté sur des sujets qui sont déjà là, mais rarement posés noir sur blanc.

2) Donner une vision produit claire aux équipes agiles

L’un des plus gros malentendus de l’agilité, c’est de croire qu’on ne peut plus prévoir au-delà du prochain sprint. C’est totalement faux bien-sûr et l’agilité ne supprime pas le besoin de perspective.

Au lieu de s’enfermer dans une roadmap de fonctionnalités gravées dans le marbre six mois à l’avance qui sera de toute façon fausse dans deux semaines, on passe à une roadmap orientée objectifs. 

L’idée c’est qu’on définit la direction et les problèmes qu’on veut résoudre, mais on laisse la liberté sur la manière technique d'y arriver. 

C'est ce qui permet de donner un cap sans transformer les équipes en simples exécutants de tickets Jira.

Dès qu’on travaille avec plusieurs équipes, le risque de naviguer à vue est démultiplié. C’est là que des rituels comme le PI Planning ou des outils comme le Program Board prennent tout leur sens.

Ce ne sont pas juste des réunions de plus ou des tableaux complexes mais des moments de transparence où l’on pose les dépendances sur la table. 

Ça permet d'éviter de découvrir des bloqueurs le mardi matin en plein sprint parce qu'une autre équipe n'a pas livré son API.

Pour lier tout ça, les OKR (Objectives and Key Results) sont redoutables s'ils ne sont pas détournés en indicateurs de flicage. 

Ils forcent tout le monde, du management au dev, à se poser la seule question qui compte :

« Quel impact concret veut-on voir sur le produit ? ».

Ceci afin d’éviter de tomber dans le piège de la feature factory : on livre beaucoup et vite, mais on livre des choses qui ne servent pas forcément à grand chose.

3) Faire évoluer l’organisation pour soutenir l’agilité

Dans les cas où la gouvernance est “maquillée”, un travail plus structurel est nécessaire.

Cela passe par une clarification des rôles, mais aussi par la création d’espaces de décision adaptés.

Les guildes, lorsqu’elles sont réellement actives, permettent de structurer le partage de connaissances et certaines décisions transverses. 

On se rencontre régulièrement autour d’objectifs communs pour définir des standards co-construits.

Le levier le plus puissant reste le Target Operating Model (TOM) expliqué en détail dans mes précédents articles. C'est le "système d'exploitation" de votre entreprise. 

Un TOM orienté agile permet d'aligner la structure (budgets, équipes, RH) avec les ambitions réelles de l'organisation. 

Il oblige à confronter l'existant (le As-Is) aux besoins de demain (le To-Be), pour passer d'une logique de silos à une logique de flux de valeur.

Bien sûr, ces évolutions demandent du temps. Mais elles sont souvent indispensables pour sortir des incohérences.

Exemple concret de conflit entre gouvernance et agilité

Dans une transformation que j’ai accompagnée, plusieurs équipes travaillaient déjà en Scrum depuis un moment. 

L’organisation était en place, les sprints tournaient, les estimations en story points étaient utilisées et les équipes s’engageaient sur leur capacité.

Sur le papier, tout semblait cohérent. Mais dans la réalité, il y avait un décalage assez fort entre les niveaux de lecture.

Côté équipes, le pilotage se faisait clairement en story points, avec une logique d’engagement sprint par sprint. 

Mais en parallèle, du côté produit, la lecture de la roadmap restait très orientée charge et délais avec une projection en jours-hommes et des attentes d’engagement sur des dates de livraison.

Ce double niveau de lecture a rapidement posé problème.

• D’un côté, une logique agile basée sur la capacité et l’incertitude.
• De l’autre, une logique plus classique basée sur des engagements de délai assez fermes.

La difficulté n’était pas tant dans les outils utilisés, mais dans la cohabitation de deux systèmes de pilotage. 

Les sprints donnaient une visibilité court terme, mais les attentes de livraison restaient structurées sur une vision beaucoup plus prédictive.

Avec le temps, ça a généré des tensions assez classiques comme : 

• la difficulté à tenir les engagements, 
• l’incompréhension sur les variations de vélocité 
• et les discussions récurrentes sur ce qui est vraiment fiable ou non. 

En effet, les vélocités permettent de définir une capacité théorique qui peut varier en fonction des acteurs présents durant les sprints. 

Mais des engagements fermes sans concertation avec les équipes n'apportent pas plus de fiabilité.

Le travail a donc consisté à remettre de la cohérence entre ces deux lectures. 

Cela a impliqué de clarifier ce qui relevait du pilotage agile et ce qui relevait des engagements de delivery et surtout d’aligner les attentes des deux côtés.

Il a aussi fallu accepter une forme de réalité des deux côtés et de reconnaître que la capacité des équipes n’est pas un engagement de date figé mais que la direction avait malgré tout besoin d’un minimum de visibilité pour piloter.

C’est un réajustement progressif souvent axé sur la négociation du périmètre qui a permis de sortir d’une logique de confrontation entre deux modèles, pour revenir à quelque chose de plus lisible et fiable pour tout le monde.

Tableau de synthèse sur l’agilité et la gouvernance

Pour conclure, voici une synthèse des principales situations observées et des leviers associés :

Conclusion

L’agilité ne règle pas les problèmes de gouvernance mais les rend juste impossibles à ignorer.

On peut s'enfermer dans les rituels et les frameworks pour donner le change, mais le vernis finit toujours par craquer dès qu'il faut trancher une priorité ou assumer un arbitrage difficile.

C’est ce fameux moment où les sourires amusés des premières expériences agiles font place aux premières prises de conscience parfois houleuses.

L’enjeu n'est pas de faire du Scrum by the book, mais de regarder en face qui décide de quoi et sur quelle base. Vouloir une équipe autonome sans lui donner de vision claire ou attendre de la réactivité tout en maintenant des circuits de validation opaques, c’est une impasse.

Le succès d'une transformation se joue dans la capacité à rendre les responsabilités explicites même quand c'est inconfortable.

L’agilité est un outil de transparence et cette clarté est sans doute la seule chose dont les équipes ont réellement besoin pour avancer sereinement.