Manager, c’est prendre des décisions, et c’est ensuite s’assurer de leur bonne exécution.
Comment le processus de décision peut-il soutenir l’agilité de l’organisation ?
Cet article amène quelques éléments de réflexion en rapprochant un modèle de management proposé par Ichak Adizes, une vision systémique et des exemples issus du framework de mise à l’échelle SAFe…
Une tension à réguler pour plus d’agilité
Manager pour changer, le modèle d’Ichak Adizes
Ichak Adizes commence son livre “Maîtriser le changement” par la question :
”Qu’est-ce que manager veut dire ?”
Il propose comme réponse le modèle suivant :
Le changement est indissociable de la vie. Vivre pour un individu ou une organisation, c’est changer.
En psychologie cela correspond à “la règle de l’homme mort” :
Ne pas prendre pour objectif quelque chose qu’un mort arriverait mieux à faire qu’un vivant (exemple : ne plus souffrir ou pour un manager ne plus avoir à gérer des personnalités difficiles ! ).
Cependant, “changer” implique de résoudre des problèmes pour continuer à exister.
“Vivre veut dire résoudre des problèmes, et grandir veut dire être capable de résoudre de plus gros problèmes”. Ichak Adizes.
Il faut donc gérer ces problèmes et leurs résolutions, c’est ce que l’on nomme le management. Cette gestion se concrétise en deux activités principales : décider et implanter, c-a-d exécuter de manière efficiente les décisions prises.
Manager, c’est donc gérer un premier paradoxe : changer pour continuer à rester le même. Ce qu’en systémique, on nomme l’homéostasie.
Le paradoxe de la qualité du management
La qualité du management devient fonction de la qualité des décisions ET de l’efficience de leur mise en œuvre.
Or, ces deux processus s’opposent rapidement !
“la qualité de décision ne peut ni prédire, ni assurer la probabilité de l’exécution”, la démocratie s’oppose au système totalitaire. Adizes parle de démocrature : la démocratie dans la prise de décision et la dictature dans l’exécution. Comment concilier souplesse-ouverture et discipline de l’exécution ? C’est le deuxième paradoxe du management qui se retrouve dans l’agilité dans la tension entre alignement des équipes et auto-organisation.
Modèle classique séquentiel
Dans l’entreprise classique, bâtie sur un mode hiérarchique et bureaucratique, la qualité du management s’obtient en séparant les processus selon une logique de spécialisation : certains décident, tandis que d’autres exécutent.
Cela peut fonctionner tant que le modèle reste séquentiel :
changement > problème > gestion > décision > implantation > fin du problème
C’est-à-dire tant que la vitesse d’implantation est inférieure à la fréquence du changement.
Besoin de régulation
Cependant la mise en œuvre des solutions génère elle-même du changement, le système se perturbe donc lui-même au travers d’une boucle de rétroaction :
Quand l’implantation rencontre des problèmes pendant que d’autres changements se produisent, le système rentre en instabilité. La vision linéaire, séquentielle ne suffit plus, il faut adopter une approche circulaire et mettre en place des boucles de régulation plus courtes afin de stabiliser le système.
Exemple des équipes Scrum
Une tension fréquente existe entre la fréquence de livraison (deux semaines) et la capacité de prise de décision des middle-managers pour résoudre les impedimentas (freins et obstacles) soulevés par les équipes (> 2 semaines).
Il ne s’agit pas seulement d’un problème de décision OU d’exécution, mais d’un problème d’interaction ENTRE la décision et l’exécution. Les systèmes hiérarchiques sont organisés pour optimiser le contrôle de l’exécution, mais pas pour raccourcir la boucle de retour entre le processus d’implantation et celui de décision.
La boucle de retour (implantation -> décision) prend beaucoup trop de temps et les problèmes d’exécution s’empilent, ne trouvent pas de solution, dégradant la qualité de l’exécution, voire la rendant contre-productive.
Sociocratie
Certains vont chercher à amener cette interaction par le changement du mode de décision. Par exemple la Sociocratie introduit un processus de décision collectif qui cherche à garantir la bonne exécution. Se référer à l’atelier-conférence “Décider plus efficacement” . L’article “Using “Sociocracy for Decision Making and Learning in Agile” permet également de comprendre l’aspect circulaire (systémique) de la sociocratie :
“Like Agile, Sociocracy is based on systems theory but applied to decision making.”
Le processus de décision dans SAFe
SAFe est un framework de mise à l‘échelle de l’agilité dans la production digitale qui rencontre un succès croissant. Contrairement à l’agilité de 1ère génération centrée sur l’équipe, le framework inclut d’emblée les managers comme vecteurs privilégiés de la transformation (au travers par exemple des formations Leading SAFe). Comment aborde-t-il en particulier la question de la prise de décision ?
Que dit SAFe?
L’objectif de SAFe consiste à accélérer la livraison de valeur pour enchanter le client, tout en respectant les parties prenantes et la société.
Achieve the sustainably shortest lead time with:
Best quality and value to people and society
High morale, safety, and customer delight
Au travers de ses quatre valeurs fondamentales, SAFe insiste tout particulièrement sur la qualité de l’exécution et l’alignement global du système afin de livrer de la valeur au client :
- Built-in quality – quality cannot be added later, it must be baked in.
- Program execution – we’re here to deliver value to our customers.
- Alignment – Global alignment trumps local excellence.
- Transparency – Up and down, leadership needs to know what teams are doing, but teams need to know the strategy in order to execute.
Passer du local au global
Au niveau local, un framework itératif et incrémental comme Scrum, assure une proximité satisfaisante entre décision et exécution par une équipe de moins de dix personnes.
Les décisions quant au travail à effectuer sont prises le premier jour du sprint, lors de la planification de Sprint, sont revues chaque jour lors du Daily Meeting et sont inspectées au plus tard au bout de deux semaines lors de la revue de Sprint. De plus, la constitution même de l’équipe (auto-organisée, pluridisciplinaire et si possible co-localisée) assure un traitement rapide des problèmes émergents.
Les choses se gâtent quand il faut escalader des problèmes (impediments) que l’équipe de production ne peut résoudre au niveau local. La remontée du système hiérarchique de décision entraîne une dégradation rapide de la performance :
- une question de délai : s’il faut provoquer une réunion ad hoc, le délai pour monter la réunion dépasse généralement le temps de l’itération;
- du flou : plus on s’éloigne de la source d’information au travers des couches hiérarchiques, plus on perd en connaissance du contexte local où le problème est apparu;
- une perte de pertinence dans le temps : la situation continue d’évoluer (et potentiellement de s’aggraver) pendant que le signalement initial du problème continue son petit bonhomme de chemin sans modification.
Plus le système considéré est large, plus il sera sensible à ces dégradations. Au-delà d’une amélioration locale de la performance des équipes, améliorer l’efficacité globale du système passe ainsi par l’amélioration de sa capacité à raccourcir les boucles de feedback entre exécution et décision. C’est un exemple d’application d’une pensée systémique au flux de valeur.
Principe n°9 de SAFe
Le framework de mise à l’échelle SAFe repose sur neuf principes qualifiés de “Lean-Agile” car combinant des éléments du mouvement agile et des principes exposés par Don Reinertsen dans son ouvrage “The Principles of Product Development Flow: Second Generation Lean Product Development” :
Se référer à l’article SAFe Lean-Agile Principles Abridged : https://www.scaledagileframework.com/blog/safe-lean-agile-principles-abridged/
Si le principe 9 “Decentralize decision-making” correspond à notre propos, il convient de remarquer que les neuf principes sont interdépendants. Par exemple, la décentralisation des processus de décision ne pourra s’effectuer correctement que si le principe 8 est réellement mis en œuvre : “Unlock the intrinsic motivation of knowledge workers’. Le tout dépendant du principe 2 “Apply systems thinking” afin qu’une optimisation locale ne mette pas en péril le fonctionnement global.
Comment cela se traduit-il ?
SAFe propose de réfléchir à chaque type de décision pour déterminer s’il faut la décentraliser ou non.
Chercher à décentraliser représente une approche saine pour raccourcir les boucles de feedback, cependant certaines décisions stratégiques demeurent plus efficaces si elles sont prises de manière globale. Il faut tenir compte des impacts en considérant le délai et les aspects stratégiques et financiers.
Il convient donc d’établir un framework de prise de décision.
Management 3.0 et 7 niveaux de délégation
C’est assez similaire à la démarche de Jurgen Appelo proposée dans “Management 3.0” au travers des sept niveaux de délégation.
La pratique du Delegation Board (https://management30.com/practice/delegation-board/) et du Delegation Poker (https://management30.com/product/delegation-poker/) trouve tout à fait sa place afin de raffiner le framework de prise de décision.
Les 3 critères de Dean
Dean Leffingwell, le créateur de SAFe, propose une approche plus simple au travers de trois critères principaux concernant la décision :
- est-elle fréquente ou urgente ?
- est-elle stable dans le temps ?
- apporte-t-elle une économie d’échelle ?
Plus la combinaison de ces trois critères est élevée, plus la décision doit être globale.
Que pensez-vous, par exemple, de la décision d’entamer une transformation agile de l’entreprise ?
Il semble que ce soit une décision non-fréquemment à prendre + stable dans le temps + apportant une économie d’échelle. Elle relève donc d’une décision stratégique à centraliser.
Mais n’oublions pas le modèle d’Adizes, l’implantation décentralisée de cette décision centralisée va créer des tensions qu’il va falloir détecter grâce aux retours d’information des boucles de feedback courtes et fréquentes.
Souvenons-nous des principes agiles : “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” “The best architectures, requirements, and designs emerge from self-organizing teams.”
Pensez en revanche à décentraliser, en particulier si les décisions :
- sont fréquentes (ex. priorisation des éléments à produire lors des itérations)
- sont critiques (ex. une décision impactant directement la capacité d’un client à utiliser le produit ou service)
- requièrent de l’information locale (ex. la capacité d’une équipe à traiter une demande urgente et imprévue)
La décentralisation dans les pratiques SAFe
La mise en place de SAFe s’articule généralement autour du concept d’Agile Release Train (ART) : une organisation virtuelle de plusieurs équipes agiles afin de constituer un flux de production de valeur (niveau programme) à l’auto-organisation renforcée.
Thèmes stratégiques
Des thèmes stratégiques sont définis au niveau global de l’entreprise. Leur définition collective intègre la boucle de feedback remontant du terrain au travers des Product Managers, des responsables techniques (Enterprise architect) et des Business Owners vers l’équipe en charge du Portfolio Management.
Ces thèmes vont nourrir la vision, le budget, la roadmap et les backlogs au niveau programme c-a-d au niveau des ART.
https://www.scaledagileframework.com/strategic-themes/
Cadence du Program Increment
Au niveau programme, l’exécution s’effectue sur une cadence de 10 semaines, correspondant à cinq itérations de production des équipes. C’est ce que l’on nomme le Program Increment.
S’inspirant d’une mise à l’échelle des activités de Scrum, cette cadence va procurer le cadre de la décentralisation des décisions au niveau des Trains :
- chaque train dispose de son budget de fonctionnement et d’un backlog résultant des décisions matérialisées par les thèmes stratégiques
- une première activité de deux jours, le Program Increment Planning, réunit l’ensemble des acteurs du Train pour décider de la production des 10 prochaines semaines. Les éléments prioritaires du Program Backlog sont répartis par les équipes sur les prochaines itérations en fonction de leur capacité de production.
- Le soir du premier jour, l’équipe de management se réunit pour prendre en compte les feedbacks récoltés dans la journée, prendre les décisions informées correspondantes et réinjecter ces décisions le lendemain matin afin de permettre aux équipes de préparer au mieux leurs 5 prochaines itérations.
- à l’issue de la deuxième journée, les équipes proposent aux Business Owners les objectifs du prochain Program Increment. La validation de ces objectifs s’effectue au travers d’une évaluation directe de leur importance stratégique. Le feedback est immédiat et l’information circule rapidement entre la production et la couche stratégique.
- Toutes les deux semaines, les équipes intègrent le travail produit afin de détecter les problèmes au niveau du système. Les différents stakeholders sont ainsi informés des difficultés rencontrées et peuvent soutenir les équipes.
- Toutes les 10 semaines a lieu la System Demo qui permet de vérifier l’adéquation entre ce qui avait été prévu et ce qui est finalement livré. Là encore, les différents stakeholders sont informés et peuvent interagir directement avec les équipes.
- L’information résultante de cette activité irrigue directement la préparation du prochain Program Increment Planning afin de tenir compte des derniers retours d’information.
- Et la boucle est bouclée…une nouvelle itération de programme commence…
Nous ne détaillerons pas plus en avant les mécanismes de SAFe. Notre objectif est simplement de vous donner un aperçu de la manière dont le framework apporte un cadre favorisant la décision locale, la transparence, la collaboration et la remontée rapide d’informations afin de s’adapter aux problèmes émergents.
Don Reinertsen et Economic Framework
Une autre matérialisation de la recherche de transparence et d’efficacité dans les prises de décision se trouve dans la notion d’Economic Framework de SAFE. Couvrir cet aspect sort du cadre de cet article, mais vous pourrez trouver plus d’information sur le site de SAFe en consultant les deux entrées suivantes :
Les principes- clés qui sous-tendent ce concept de vue économique (principe 1 du framework SAFe) s’inspirent directement des travaux de Don Reinertsen sur l’optimisation des flux de production : Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
L’objectif est d’aider toutes les parties prenantes du flux de valeur à prendre de meilleures décisions en se basant sur un modèle économique commun. Cinq principes exposés par Reinertsen contribuent spécifiquement à élaborer ce modèle :
- The Principle of Quantified CoD : si sous quantifiez une seule chose, quantifiez le coût du délai
- The Principle of Continuous Economic Trade-Offs : effectuer des choix basés sur des critères économiques tout au long du processus
- The Principle of Optimum Decision Timing : Chaque décision a son moment économique idéal
- The Sunk Cost Principle : ne tenez pas compte de l’argent déjà dépensé pour prendre vos décisions (biais cognitif)
- The First Decision Rule Principle : utiliser des règles de décision pour décentraliser le contrôle économique
Conclusion
La transformation agile d’une organisation cherche à amener plus de valeur, plus rapidement à ses clients. Cela comprend inévitablement une réflexion sur les processus de décision et les boucles de rétroactions entre l’exécution et les décisions.
C’est un exemple de vision systémique de l’amélioration : améliorer l’exécution ne suffit pas si les problèmes rencontrés ne peuvent être résolus rapidement par des décisions informées et prises dans le bon contexte.
Nous avons pris quelques exemples dans le framework de mise à l’échelle SAFe pour illustrer une mise en pratique de cette vision systémique de la prise de décision. SAFe suggère en outre de construire un modèle économique de prise de décision qui favorise l’alignement et donc la bonne exécution.
Au-delà de l’agilité locale des équipes, la réflexion systémique sur l’agilité de vos processus de décision contribuera significativement à atteindre vos objectifs d’amélioration…
L’auteur de cet article est Christophe Keromen.
[…] https://blog.goood.pro/2018/05/15/decider-et-executeret-decideret/ […]