Les Bases du Management Agile

Chacun a en tête sa propre vision, souvent caricaturale, du manager. La mienne repose sur un savant mélange entre mes propres expériences et la description archétypale proposée par Hollywood. On y voit en général un individu en costard-cravate au sérieux inébranlable traverser des couloirs sans fin un gobelet greffé à la main, quand il n’est pas absorbé dans d’interminables réunions stratégiques. Son mode de fonctionnement avec les équipes repose en général sur une dose majoritaire de “contrôle et de commandement”, au milieu de laquelle transparaissent (souvent trop peu) son style et sa sensibilité personnelles…

Contrôle et commandement

Le “Contrôle et commandement” (on entend plus couramment l’anglicisme “Command and control”) est un style de leadership moderne issu d’une vision du monde basée sur la prédiction et le contrôle. Deux axes d’une idéologie qui repose sur les suppositions suivantes :

• Nous pouvons prévoir précisément le futur (les conséquences à moyen ou long terme)
• Nous pouvons et nous devons utiliser des mécanismes de contrôle pour obtenir les résultats attendus, quelles que soient les conséquences négatives de ces mécanismes.

Parmi les grands principes qui accompagnent cette idéologie, on retrouve :

• Un système de décision centralisé (donc non collaboratif)
• Une organisation basée sur une hiérarchie pyramidale (la culture du command and control existe aussi dans les organisations à la structure horizontale).
• Une opacité de l’information plus on remonte la chaîne hiérarchique
• Un management qui crée toutes les règles dans son coin.
• Une aversion pour l’échec
• Un encouragement à “travailler pour faire plaisir au patron”
• Une surveillance excessive des mouvements des collaborateurs.
• Etc.

J’ai pu connaître parfois cette situation mais j’ai aussi heureusement rencontré des managers qui s’éloignaient notablement de cette image. Et même si elle tendrait aujourd’hui à se diluer de plus en plus dans l’agilité, je constate que cette culture du management n’est pas prête de disparaître…

Le Manager Agile

À l’opposé, qu’il adopte sobrement le style vestimentaire de Tom Cruise dans “La Firme” ou qu’il arbore fièrement la chemise à carreaux et le chignon d’un hipster, le manager agile, va devoir quant à lui épouser une nouvelle forme de leadership. Il est toujours aussi indispensable à l’organisation mais dans un cadre agile, un certain nombre de ses responsabilités sont transférées aux rôles présents dans les équipes Scrum (Scrum Master, Product Owner, Développeurs).

Le manager agile est un “servant-leader” qui va aider ses équipes en éliminant tout obstacle qui pourrait entraver leur réussite, comme un jardinier veillerait au bon développement de ses plantes. Il peut essayer de les engueuler et de leur mettre des coups de pieds, mais je doute que ça les fasse pousser plus vite…

Il est chargé de créer et d’entretenir un environnement dans lequel les équipes agiles peuvent se développer, expérimenter et atteindre les objectifs qui leurs sont confiés. Il va se concentrer sur la génération de valeur plus que sur les “deadlines”.

Parmi ses autres responsabilités nous pouvons ajouter :

• Faire régner la transparence. Il veille à ce que les équipes agiles partagent ouvertement leurs progrès mais aussi leurs problèmes. Lui-même a une vision claire qu’il n’hésite pas à partager à tous.
• Encourager la collaboration et le partage de connaissances. Il pose des questions, fait confiance à ses collaborateurs et il n’a pas peur de déléguer.
• Encourager et récompenser la prise d’initiatives (leadership) au sein des équipes. Il leur permet de s’améliorer, de devenir autonomes et d’innover.

La route vers l’agilité

Dans sa période de transition et d’adaptation vers un management plus agile, le manager “traditionnel” peut rencontrer un certain nombre d’écueils avant d’adopter pleinement l’état d’esprit agile. Je vais évoquer trois exemples d’erreurs et leur solution pour conclure cet article :

Erreur : Mesurer la valeur business des équipes en se basant sur leur vélocité

La vélocité n’est pas un indicateur fiable.

Elle varie selon beaucoup de facteurs : le type de “stories” choisies pour le Sprint, leur taille, le niveau technique des développeurs, la qualité des estimations etc. Le but principal de la vélocité est de permettre aux développeurs de savoir à peu près combien de stories ils peuvent prendre dans le Sprint à venir, en aucun cas d’aider les managers à faire des mesures, des projections ou des comparaisons.

Une meilleure idée serait de privilégier la collaboration et de consulter le Product Owner, qui est la personne “chargée de maximiser la valeur du produit résultant du travail de l’équipe”. Il est le plus à même d’identifier la valeur business produite.

Erreur : Ajouter des membres aux équipes pour un oui ou pour un non

Il peut s’avérer parfois utile d’ajouter des membres aux équipes agiles.

C’est le cas par exemple si l’équipe doit absorber une charge de travail plus importante que prévue à moyen terme, si la demande émane de l’équipe elle-même et si elle est consciente de la baisse de productivité que la réorganisation engendrera dans un premier temps.

En revanche, c’est une mauvaise idée si l’équipe subit des demandes de support et des distractions venant de l’extérieur. Ajouter des membres revient alors à mettre un pansement sur une jambe de bois puisque le problème à l’origine va persister. Pire encore, vous prenez le risque de créer un “silo” au sein de l’équipe Scrum, créant une équipe dans l’équipe…

La solution est de reconnaître que cette situation entrave l’équipe puis de travailler avec elle (Scrum Master, product Owner, Developpeurs) et les parties concernées pour faire cesser cette pratique.

Erreur : Tenter de négocier avec le Product Owner pour qu’il cède aux pressions

…voire, horreur absolue, couper l’herbe sous le pied du Product Owner en demandant directement aux développeurs de faire le boulot…

Aussi choquant que cela puisse paraître, si vous avez un Product Owner, il devient par définition le propriétaire du produit et l’organisation doit respecter ses choix. C’est la condition indispensable pour qu’il remplisse sa mission correctement. Il prend ses propres décisions, en harmonie avec les stakeholders avec qui il est normalement en contact régulier. Il doit cependant parfois être capable de résister aux pressions des uns et des autres, s’il estime que le succès du produit en dépend. Il aura souvent besoin pour cela du soutien de Leaders Agiles…un manager par exemple.

Une courte liste d’exemples qui pourrait beaucoup s’allonger, mais j’en resterai là pour aujourd’hui. En espérant qu’ils donneront une idée claire du rôle de Manager Agile à ceux qui débutent ainsi qu’à ceux qui font la transition vers l’agilité…à bientôt !