Imaginons une entreprise lambda (ou Delta-Omicron pour faire mode) dans laquelle vous êtes appelé en tant que Coach Agile. Ou plutôt, Coach Agile Consultant Produit DevOps Manager Expérimenté avec au moins 5 ans d’expérience comme on voit dans les annonces aujourd’hui. Votre mission, si vous l’acceptez, sera de procéder à la “transformation Agile de l’organisation”.
Derrière cette terminologie un brin pédante se cache une vraie problématique sur laquelle tout Coach Agile va devoir se pencher un jour. Elle se décompose selon moi en deux points principaux :
- Transmettre l’état d’esprit Agile aux groupes et personnes concernés (transmettre valeurs, principes et la dose de bon sens qui va habituellement avec).
- Proposer des façons de réorganiser le travail autour de ces mêmes valeurs et principes. C’est là qu’interviennent les frameworks et la palanquée d’outils de facilitation qui peuplent le monde merveilleux de l’agilité.
Les deux options traditionnelles
Se pose alors un problème de taille. Par où commencer ce travail “d’évangélisation” ? À ma connaissance, il y a deux façons “traditionnelles” de procéder. Si l’on visualise l’organigramme de l’entreprise comme une pyramide, avec les leaders aux étages supérieurs et les techniciens aux niveaux inférieurs on se retrouve avec les possibilités suivantes :
- Démarrer le travail par la base de l’organisation, en réorganisant d’abord le travail des développeurs (définition large qui englobe de multiples spécialités comme le web design, l’UX, les testeurs etc.) en équipes Scrum (ou autres) tout en faisant remonter la bonne parole aux managers et à leurs supérieurs.
- Démarrer l’implantation de l’agilité par le sommet de l’organisation, en formant les dirigeants et les managers qui sont alors censés devenir leaders/influenceurs de cette transformation Agile. Ils appuieront les Coach Agiles dans la propagation de l’agilité vers la base de l’organisation.
Et comme si ça n’était pas déjà suffisamment compliqué, ces deux options sont généralement assorties d’un plan de transformation agile.
Le Plan de Transformation Agile
Les responsables de la transformation vous demanderont probablement ce document magique (pour eux) qui présentera toutes les étapes de la transformation telle que vous la prévoyez. Casser tel ou tel silo, réorganiser telle ou telle équipe de 20 personnes en équipes pluridisciplinaires, expliquer l’Agilité aux managers, organiser des ateliers pour les groupe X et Y…Bref, il doit y figurer ce que vous ferez, où, quand, comment, avec qui, pourquoi et sur combien de temps.
Cette méthode ne vous rappelle rien ? Nous revoilà à nouveau calés sur un fonctionnement en cascade, donc non-agile avec exigences, analyse, conception, mise en oeuvre, validation et mise en service…
Et même si l’action de définir les contours et détails d’un plan offre des bénéfices clairs, nous savons tous ce que vaut le plan en lui-même au final…pas grand chose. Et cela fait bien longtemps que l’on est au courant. Comme le disait un certain Helmuth von Moltke en 1871 :
No plan of operations extends with any certainty beyond the first encounter with the main enemy forces. (Aucun plan ne survit à la première rencontre avec les forces ennemies)
Votre plan n’aura qu’un but : rassurer quelqu’un sur des actions que vous ne pourrez de toute façon pas exécuter de la manière prévue par le plan (“Plans are worthless, but planning is everything” Dwight D. Eisenhower). Il n’a aussi qu’une probable destination : le fond d’un obscur dossier dans l’ordinateur de celui qui vous l’a demandé (ou un tiroir pour les plus âgés d’entre nous).
En résumé vous voilà avec deux angles d’attaque possibles : prendre la pyramide de l’entreprise par le haut ou par la base, avec un lourd plan de transformation agile attaché à la cheville. Passons rapidement en revue ces deux options.
L’option 1 : démarrer par la base
C’est l’option que j’ai personnellement expérimentée, bien qu’indirectement lors de mon précédent poste de Coach Agile. La mise en place initiale de l’agilité dans les départements informatiques et autres “Digital Factories” ne pose en général pas de problèmes majeurs. Soyons honnêtes, ce n’est jamais facile, il y a toujours des questions et des frictions mais ça se fait. Les développeurs y trouvent très rapidement leur intérêt. En revanche son extension à certaines équipes transverses ou aux premières couches de management s’avère parfois impossible. La pilule ne passe pas…
L’option 2 : démarrer par les leaders
C’est l’option proposée par le framework SAFe. Et apparemment, il semblerait que les organisations qui l’implémentent restent assez loin du scénario idéal présenté dans la formation SPC (SAFe Program Consultant). À savoir, former des leaders, managers et dirigeants qui seront chargés de propager ce qu’ils ont appris aux strates inférieures de l’entreprise.
Je suis souvent le premier à critiquer SAFe (pour un tas de raisons) mais ce modèle d’organisation a au moins le mérite de reconnaître que le changement est quasi-impossible tant que l’organisation ne se trouve pas dans une situation désespérée. SAFe propose deux conditions au changement :
- Une direction visionnaire
- Un état de panique totale
La documentation formule ça de façon un peu plus poétique que moi mais l’idée reste la même :
“A burning platform – Sometimes the need to change a product or service is obvious. The company is failing to compete, and the existing way of doing business is obviously inadequate to achieve a new solution within a survivable time frame. Jobs are at stake. This is the easier case for change. While there will always be those who are resistant, they are likely to be overcome by the wave of energy that drives a sense of urgency for mandatory change through the organization.”
Scaled Agile Framework : Reaching the Tipping Point
Il y a le feu au lac, des postes sautent ou vont sauter et même les plus réticents devront s’adapter pour sauver leur peau. C’est le schéma idéal pour un changement de haut en bas nous dit SAFe…Ce n’est pas à ma connaissance un schéma si courant dans la réalité. Et est-ce bien agile ? Je laisse cette question en suspens…
La seconde condition, s’appuyer sur le leadership d’une direction visionnaire me semble tout aussi improbable étant donnée la lourdeur hiérarchique et administrative de beaucoup de grandes organisations.
Que vous attaquiez par la base ou par le sommet, avec ou sans direction prête à prendre des risques, vous allez rencontrer des résistances…
Résistances
Tout simplement parce que vos collaborateurs ne sont pas des pièces de machinerie que l’on déplace à l’envi, selon les besoins d’un plan et encore moins des “ressources”. Ce sont des humains…avec leur propre vision des choses. Pourquoi refusent-ils le changement ? Voici quelques pistes :
- La peur de voir son poste menacé par ces pratiques nouvelles.
Une peur infondée, car à titre d’exemple, un manager devenu agile est aussi indispensable qu’avant. Simplement, son rôle, ses méthodes et son approche changent. - Un attachement irrationel à des pratiques rassurantes mais inefficaces.
Comme planifier à outrance avant de se lancer dans un projet ou établir des projections insensées dans le futur… - Une vision rigide des méthodes de travail.
Par exemple, certaines personnes considèrent qu’il est bon de travailler dur et tard pour être efficace ce qui est en complète opposition avec les principes de l’agilité. - Des angoisses liées à une idée compliquée de l’agilité.
La peur d’avoir à subir de façon trop contraignante les rituels, les frameworks, les estimations, l’avalanche de mesures (utiles) et de leurs acronymes (nébuleux et inutiles) etc. Le vertige d’avoir à plonger dans le grand océan de l’agilité et de s’y perdre… - Une incompréhension du rôle du Coach Agile.
Parfois mal compris, souvent occupé à observer, coacher, discuter, socialiser, faciliter, comprendre, préparer des ateliers…les occupations du Coach Agile peuvent susciter certaines interrogations et résistances. - La peur d’expérimenter et d’échouer.
- Etc.
Alors bien-sûr, c’est pour ces raisons que le travail de fond qui consiste à faire ressortir les benefices de l’agilité pour chacun et clarifier les rôles prend tout son sens. Mais ça ne sera parfois pas suffisant.
Parfois aussi, plus simplement, votre périmètre d’action a été mal négocié. Si l’extension de l’Agilité vers les couches supérieures de management n’a pas été prévue d’emblée vous risquez de vous heurter à une résistance farouche. Au mieux vous ferez face à des écrans de fumée, ce que j’appelle aussi le mirage agile.
Le Mirage Agile
Toutes ces départements réfractaires à l’agilité vous donneront parfois l’illusion que la transition est possible. Même si le concept ne leur plaît pas et qu’ils ne le comprennent pas. Et même si l’agilité les laisse dubitatifs, ils ont bien compris que quelque chose d’important se jouait en périphérie de leurs bureaux.
Il vont parfois donner l’illusion de s’intéresser à cette “étrange pratique new age” qu’est l’agilité. Pour faire bonne figure auprès des autres, pour dire qu’ils ont initié une démarche…Démarche qui est en général à l’origine pour le Coach de rendez-vous inutiles ou annulés, de demandes de “plans de transformation” sans intérêt et d’autres tentatives de se laisser convaincre aussi vaines les unes que les autres.
Vous y croyez, eux pas vraiment. Il y a toujours une bonne raison de “ne pas faire”. Un supérieur sceptique, un emploi du temps plus chargé que celui du Président des États-Unis, une envie de “voir ça plus tard, car ce n’est pas le bon moment, tu comprends on doit boucler le projet bidule et on est en retard”…Souvent aussi, ils ont eux-mêmes bien compris que les lourdeurs hiérarchiques les empêcheraient de se lancer dans l’aventure.
Que fait-on alors ?
Une troisième voie
Il existe une troisième alternative, bien différente des deux précédentes qui permettrait de naviguer plus aisément à travers ce maelstrom de sensibilités et de barrières administratives.
Développer l’agilité là où elle est attendue, là où elle apportera un bénéfice quantifiable rapidement, là où elle va soulager une douleur instantanément. Ça peut démarrer par une unité business, ça peut démarrer en lançant Scrum dans une Digital Factory. Ça peut commencer par 3,4,7 équipes en agilité à l’échelle…ou une seule unité Scrum.
Les autres équipes ne veulent pas en entendre parler ? Tous les efforts seront faits pour qu’elles y viennent mais ça n’a pas d’importance. Ce qui importe c’est le rayonnement des pôles où l’agilité aura été implantée avec succès. Ont-ils l’air plus détendus ? S’améliorent-ils en tous points ? Sur les techniques, la collaboration, la régularité, la prédictabilité, etc. Si oui, c’est votre meilleur outil pour étendre l’agilité à des groupes un peu plus hésitants.
C’est une façon de faire plus naturelle, plus simple, et à mon sens plus agile, dans la mesure où elle permet une adaptation au fil de l’eau et une implantation plus fluide de l’agilité. Démarrer le travail là où les esprits semblent les plus réceptifs en progressant de façon organique vers l’objectif…
C’est aussi la solution proposée par Kurt Bittner sur scrum.org avec son article “Freeze The Pond Versus Take The Hill Two Metaphors For Enterprise Agile Change”, dont je m’inspire librement dans ce billet.
Dans son texte, l’auteur compare l’expansion de l’agilité dans l’entreprise à la progression du gel sur une étendue d’eau. Les premières zones gelées (l’agilité) apparaissent aux endroits les plus propices à la transformation, avant de se propager ensuite à l’ensemble du lac, de manière naturelle tout en contournant les zones plus difficiles (impuretés, feuilles, profondeur etc.). Il n’y a rien de systématique dans le procédé, qui est un produit des circonstances.
Je concluerai avec une citation extraite de l’excellent livre de Mark Schwartz, A Seat at the Table :
“We need immediate cultural change so that we can become Agile! – That attitude […] is strangely non-Agile — what we really need to do is experiment and learn about how an Agile approach to IT works within the broader business context that is the enterprise.”
Citation qui fait par ailleurs écho à la quatrième valeur du Manifeste Agile (décidément incontournable) :
“L’adaptation au changement plus que le suivi d’un plan”
À bientôt !
