Dans ce troisième et dernier article de la série consacrée à l'Holacracy, je partage notre propre retour d'expérience sur sa mise en œuvre débutée en 2017 au sein du département Digital de la DSI (service informatique) Swiss Life.
Cet article est dédié à Bernard Marie Chiquet qui nous a quitté bien trop tôt (le 24 septembre 2022) et a tant œuvré pour la démocratisation de l’Holacracy en France et au-delà. Mes pensées vont à Perrine, Margaux et Louis.
Si vous découvrez l'Holacracy, je vous invite à consulter les deux articles précédents :
Le contexte de mise en oeuvre de l'Holacracy
Pour la rédaction de cet article, j’ai tenu à décrire en toute transparence le contexte dans lequel nous avons expérimenté l'Holacracy et les moyens que nous nous sommes donnés. Vous aurez ainsi tous les éléments pour juger du crédit à apporter à ce partage d'expérience se voulant honnête, objectif et sans parti pris.
Contexte
La mise en œuvre de l'Holacracy concerne le département dont j'ai eu la responsabilité de 2014 à 2018. Comme évoqué en intro, il s'agit du département digital de la DSI de Swiss Life (société d'assurance d'un peu moins de 3000 personnes en France). D'un point de vue démographique, le département a compté en moyenne 15 à 17 collaborateurs pendant l'adoption. Dont un peu plus de la moitié de prestataires travaillant au quotidien avec les internes. La moyenne d'âge était autour de 30 ans avec 3 personnes de plus de 40 ans et une majorité d'hommes (le grand drame de l'informatique). Le département comptait et compte encore principalement des développeurs et managers agiles. Il est à cheval sur deux sites géographiques : Paris et Roubaix.
Autre précision importante, les équipes pratiquaient déjà les méthodes agiles au moment de l’adoption et étaient en cours d’acquisition de la façon de penser (ou “mindset”) agile (acquisition immédiate pour certains et plus longue pour d’autres).
Formation
Historiquement, j'ai suivi une première formation d'introduction à l'Holacracy d'une journée proposée par Igi Partner. Puis une seconde plus avancée (Formation certifiante "Praticien" avec un véritable examen) de 4,5 jours accompagné d'une membre de mon équipe (Emilie Arnould qui partage son propre regard sur cette expérience à la fin de cet article). J'ai ensuite proposé à un sponsor haut placé chez Swiss Life (niveau Comité Exécutif) d'expérimenter cette innovation sur notre département. Proposition acceptée.
Les étapes d'adoption de l'Holacracy
Le séminaire de direction
Avec l’accord du sponsor et le financement associé, nous avons débuté l'accompagnement par Igi Partner. Cet accompagnement a commencé par le "séminaire de direction" (terme utilisé par le coach) rassemblant l'ensemble des membres du département (internes et prestataires) pendant 2 jours. Ce séminaire explique le fonctionnement de l'Holacracy avec un peu de mise en pratique.
Il m'a ainsi permis de prendre la température auprès des membres de notre département, observer leurs réactions. Globalement, à ce stade, tout le monde était prêt à essayer par ouverture d'esprit sans être certain que ça apporterait quelque chose de plus, compte tenu du fait que nous étions déjà pas mal "outillés" grâce aux méthodes agiles. Parmi les réactions, la question suivante est revenue plusieurs fois : "Ok on va fonctionner en Holacracy mais tant que toutes les équipes dont on dépend ne fonctionneront de la sorte, est ce que ça a vraiment un intérêt ? On constate déjà les limites avec l'agilité qui reste encore peu pratiquée par certaines équipes dont on dépend". Il y a eu aussi quelques réactions plus enthousiastes.
Bienvenue dans la "vraie vie" 🙂
Signature de la constitution
Suite au séminaire, j'ai donc décidé de soumettre mon pouvoir aux “règles du jeu” de l'Holacracy décrites avec précision dans la constitution. Après tout, il y a bien une constitution des droits de l'homme, ou un code de la route, pourquoi pas une constitution qui régit nos interactions et processus de prise de décision, dans une logique de protection des individus des jeux de pouvoir et d’accélération de la prise de décision par des processus et des rôles explicites. Et accessoirement, éviter de basculer dans l’anarchie en l’absence de lien de subordination entre les individus.
J'ai lu dans un article qu'il était déconseillé ou inutile de signer la constitution officielle Holacracy pour deux raisons. La première est qu'il ne faut pas nécessairement appliquer la constitution à la lettre mais l'adapter à son contexte. Et la seconde qui consiste à considérer que les membres de l'équipe ne sont pas dupes au point de percevoir la signature de la constitution par le "boss" comme un véritable engagement.
De mon point de vue, la constitution est un tout (tout comme Scrum est un tout) et mettre en œuvre une variante de l'Holacracy n'est plus de l'Holacracy. De même que faire du Scrum sans faire de Rétrospective de Sprint ne revient pas à faire du Scrum. Les résultats ne seront pas ceux qu'on peut attendre de Scrum. Et il n'y a pas de dogmatisme là dedans. C'est juste du pragmatisme.
Pour ce qui est de l'impact sur les membres de l'équipe, oui il y a toujours des sceptiques pour lesquels seuls les actes comptent. Et par conséquent, l'intégrité du “boss”, autrement dit sa capacité à se soumettre aux règles du jeu de l'Holacracy est clé. Mais pour d'autres, l'impact de cette signature a été réel et a certainement contribué à son adoption rapide.
Phase d'accompagnement
La phase d'accompagnement a duré 12 semaines avec un break pendant l'été. Pendant ces 12 semaines d'accompagnement, le ou les coachs Holacracy étaient présents une journée pour animer les réunions de triage et de gouvernance du cercle du département rassemblant l'ensemble de ses membres. Chacun de ces derniers ayant un rôle affecté correspondant à l'organisation existante au démarrage de l'accompagnement (on commence par "coder" l’existant en organisation Holacracy).
La réunion de gouvernance a normalement lieu à une fréquence moins élevée, mais la pratiquer chaque semaine à des fins d’apprentissage nous a permis de maîtriser plus vite le processus (même constat pour l’apprentissage de Scrum). Les coachs ont également animé des sessions courtes (moins de 2 heures) de formation sur des thèmes précis de l'Holacracy ou connexes. Par exemple l'apprentissage du rôle de Second Lien ou encore l'apprentissage d'un Système d'Organisation Individuel (SOI) basé sur la méthode "Getting Things Down" de David Allen qui fait parti des experts convaincus par l'Holacracy (Citation de David Allen au passage : “Le modèle Holacracy a bouleversé mon univers”).
À peu près à mi-chemin de l’accompagnement, nous avons décidé de créer des sous-cercles (trois sous-cercles, un par équipe en gros) afin de "jouer" véritablement avec l'holarchie (cercle dans un cercle). Ca me semblait indispensable de franchir rapidement ce cap tant que nous bénéficiions encore de la présence des coachs.
Les choses ont commencé à devenir intéressantes car nous avons pu observer une grande diversité (que je considère comme une richesse) dans l'évolution des sous-cercles. A la fois en termes de façons de "coder" leur organisation et dans le rythme d'adoption et d'assimilation de l'Holacracy. Certains sous cercles ont par exemple "codé" de nombreux rôles, chacun "joués" par une personne différente. D'autres ont énormément simplifié en "codant" parfois un seul rôle pour plusieurs personnes (exemple : "artisan du code" pour le rôle de développeur avec un clin d'œil au mouvement Craftsmanship). Un sous cercle a testé empiriquement différentes approches, etc.
Après l'accompagnement
Suite à l’accompagnement, nous avons vécu une période de flottement. Le risque du retour au naturel était palpable. Il faut dire qu’au même moment, la transformation digitale de Swiss Life exerçait une forte pression sur notre département. Difficile de se transformer dans ces conditions. Sur les 3 équipes, une a continué son appropriation de l’Holacracy, développant de nouveaux réflexes, une autre a su conserver ses acquis et la dernière n’est pas parvenue à réellement prendre le train en marche. Sans rejeter pour autant l’Holacracy, elle a même tenu à conserver certains éléments sans exclure l’éventualité d’y revenir plus tard.
Afin d’ancrer cette démarche d’adoption de l’Holacracy, Emilie (1er lien d’un sous-cercle) a suivi la formation de coaching en Holacracy. Peu à peu le contenu de notre réunion de “one to one” au cours de laquelle nous faisions le point ensemble de façon hebdomadaire, a commencé à être reformaté par le fonctionnement en Holacracy. Idem avec mes autres “N-1” (au sens RH bien sûr, puisqu’il n’y a pas de subordination en Holacracy). Peu à peu, j’ai pu rentrer pleinement dans mon rôle de premier lien du cercle du département.
Adaptations de Scrum et Holacracy
Nous sommes également rapidement arrivés à un enjeu à régler : celui du cumul des évènements propres à Scrum ou Kanban et des réunions propres à l’Holacracy. Ça commençait à faire beaucoup pour les sous-cercles.
Nous sommes arrivés à la conclusion (avec approbation des coachs en Holacracy) que la rétrospective (commune à Kanban et Scrum) pouvait être considérée comme une réunion de triage dans le sens où on y traite clairement des tensions. Là encore, la diversité d’une équipe à l’autre s’est exprimée. Certaines équipes se sont inspirées du processus de triage pour revoir leur processus d’animation de la rétrospective. D’autres ont fait le chemin inverse.
Bénéfices de l’Holacracy
Mon constat est qu’il est assez difficile, voire impossible, de mesurer quantitativement les bénéfices de l’Holacracy lorsqu’on dispose d’équipes agiles. Une équipe agile exploite un processus concret d’amélioration continue, à travers notamment la rétrospective (que ce soit en mode projet ou non). Donc comment discerner les améliorations en termes de réactivité, de qualité, de productivité, entre celles générées par les méthodes agiles d’une part et l’Holacracy d’autres part.
Pour autant, j’ai le sentiment que l’adoption de l’Holacracy - de part l’accompagnement dont nous avons pu bénéficier et le caractère explicite de nombreux aspects - a eu pour effet une accélération de l'acquisition de l’état d’esprit agile. Ce qui à mes yeux, est bien plus important et précieux que la maîtrise des “outils” véhiculés par les méthodes agiles ou l’Holacracy. Pour précision, je considère que l’état d’esprit associé à l’utilisation de l’Holacracy est le même que celui des méthodes agiles. Par exemple : face à un problème qui semble insurmontable, long et pénible à résoudre, l’agiliste cherchera à trouver le “petit pas” à faire immédiatement avec peu d’effort qui commencera déjà à améliorer la situation plutôt que de rester figé dans l’immobilisme (statu quo). Ce qu’on appelle “l’art du possible”.
A contrario, l’appropriation du concept de “tension” (plutôt que “problème”) a re-libéré la parole sur tous les problèmes venant gêner le quotidien. Je dis “re-libéré” car l’adoption de l’agilité avait eu le même effet. C’est là qu’on passe généralement par l’étape de “plainte” de bon nombre de membres de l’équipe. Nous sommes resté un moment dans cette posture de la plainte avant de penser à relativiser certaines difficultés et concentrer son énergie sur les “vrais problèmes”. A sortir de la posture de “victime” qui trouve que le “problème” vient souvent d’une autre équipe. Même si, pour autant, il ne faut pas minimiser les freins rencontrés par les équipes qui étaient bels et bien réels et complexes, notamment du fait que les équipes DSI étaient encore très “silotées”, spécialisées par compétences techniques, avec par conséquent un très haut niveau de dépendances entre elles. En particulier les équipes “front” (qui développe uniquement la partie visible pour l’utilisateur) appartenant au département dont on parle ici.
J’ai également noté un renforcement du niveau d’engagement de la plupart des membres du département. Peut être grâce au sentiment d’égalité instauré par la signature de la constitution. Même si l’agilité n’a pas changé ma posture managériale vis-à-vis de l’égalité instaurée et l’absence de lien de subordination dans notre quotidien (hormis du point de vue strictement RH et encore). Mais encore une fois, l’acte compte plus que la parole. La signature de la constitution fut un acte fort de plus, auquel s’est succédé bien évidemment l’application de cette constitution.
Difficultés rencontrées
Nous avons bien sûr rencontré des difficultés en chemin. J’ai déjà évoqué certaines que je vais résumer dans ce paragraphe et en évoquer d’autres.
J’ai par exemple déjà évoqué le manque de “bande passante” de certaines équipes particulièrement impliquées sur leur projet du moment. Difficile de se transformer sans faire de la place. J’ai également évoqué le scepticisme (constructif) de certains membres du département : “ok on va être en Holacracy mais si les autres départements ne jouent pas également le jeu, à quoi bon ?”.
Une autre difficulté que je n’ai pas abordée est celle de la complexité de l’Holacracy. Cette technologie vient ajouter des rôles précis ainsi que des règles du jeu et des processus (de prise de décision notamment) millimétrées. Tout en changeant le paradigme organisationnel. Si Scrum change le paradigme en termes de gestion de projet, ce n’est finalement qu’une application installée sur un système d’exploitation qui est l’organisation elle-même englobant l’équipe Scrum. Hors en adoptant l’Holacracy, on change de système d’exploitation. Du coup, la bonne nouvelle, c’est qu’on peut continuer à utiliser Scrum en Holacracy sans grandes adaptations. Mais on change de système d’exploitation. C’est pas rien.
Donc au delà de réussir à adopter la bonne “façon de penser” Holacracy (ce qui peut être facilité par la culture agile pré-existante au sein du département), il a fallu maîtriser “l’outil”. Chacun doit comprendre les rôles de premier et second lien, le principe de tension et savoir où et comment la remonter, sans parler des subtilités de cercles et de sous-cercles, et des processus de prise de décision. Si je continue de comparer Scrum et l’Holacracy, le guide Scrum en français compte environ 6500 mots (hors table des matières, remerciements et notes de traduction), la constitution Holacracy 4.1 (donc après de nombreuses améliorations) en français en compte environ 11700 (corps du texte uniquement là aussi) soit presque le double. De plus, la gymnastique intellectuelle à exercer pour la lecture de la constitution me semble bien plus élevée que pour le guide Scrum dont la simplicité est remarquable. A noter au passage que les premières versions de la constitution étaient rédigées dans un espèce de langage juridique vraiment soporifique. Heureusement, ce n’est plus le cas.
Surtout ne vous méprenez pas, mon propos ne consiste pas à dire que Scrum est mieux que l’Holacracy. Ce sont deux outils totalement différents (compatibles certes) qui ne servent pas du tout à la même chose.
Bref, ça n’a pas été simple pour tous les membres du département de s’approprier tout ce que l’Holacracy implique.
Mon vécu en tant que premier lien
L'Holacracy a pu m'apporter des réponses concrètes à des questions du genre :
- Jusqu'où peut-on déléguer et comment le faire efficacement ?
- Comment faciliter/accélérer la prise de décision à l’échelle d’un département tout en ayant recours à l’intelligence collective et sans sacrifier l’engagement de chacun (cf. je suis davantage engagé dans mon travail au quotidien si j’ai la possibilité de participer aux décisions) ?
Par ailleurs, j’ai mis plusieurs mois à réussir à adapter mes interactions avec les premiers lien des sous-cercles (cf. entretiens hebdo en “one to one” pré-existants) de façon à coller au maximum au fonctionnement en Holacracy. Une relecture fréquente de la raison d’être et des redevabilités du premier lien ainsi que des processus de prise de décisions s’est avérée nécessaire. Et j’ai certainement dû commettre des erreurs parfois. J’ai d’ailleurs demandé à mes interlocuteurs de “one to one” (1er liens des sous-cercles) de m’aider à prendre la hauteur nécessaire pour respecter au mieux le fonctionnement en Holacracy. Ce qui démontre une fois de plus le degré de profondeur et de complexité de l’Holacracy. D’autant plus que, je le rappelle, j’étais déjà depuis longtemps dans une posture de manager agile (qui n’est pas dans le registre du “je commande et je contrôle” les membres de mon équipe).
Le point de vue d’Émilie
C’est Émilie qui parle sur ce paragraphe.:
En quelques mots : un gros mal de crâne après la lecture de la constitution, beaucoup de frustration durant la phase d’apprentissage, du lâcher prise et au final un sentiment d’amélioration dans la manière de prendre des décisions et dans notre capacité à avancer par “baby step”.
Avec les processus hyper rigides utilisés en holacratie, je trouve qu’on arrive à traiter une multitude de tensions diverses et variées en très peu de temps. On en traite facilement une vingtaine en 1H. Le processus et le facilitateur (gardien du processus) nous empêchent de tergiverser en cherchant une solution parfaite, qui n’existe d’ailleurs jamais, et nous oblige à essayer quelques chose, prendre une action et voir les effets associés. Ce que j’apprécie également, c’est que c’est souvent la personne qui arrive avec sa tension qui repart avec une action pour faire avancer son problème, pas son “manager”.
Cette question revient en permanence: “De quoi as-tu besoin”. Parfois on a juste besoin de se plaindre, et une fois que c’est fait, le facilitateur nous repose la question “De quoi as-tu besoin” ? Et enfin “As-tu tout ce dont tu as besoin ?”
Quand je vais à d’autres réunions en dehors de mon département, réunions qui peuvent parfois durer le double ou le triple de temps et qu’on arrive à traiter seulement 3 ou 4 sujets, je vois la force de l’holacratie sur notre capacité à trouver des solutions en mettant à profit l’intelligence collective avec un processus rigide pour nous guider. Je ne peux d’ailleurs m’empêcher, quand les sujets s’éternisent, de poser parfois quelques questions issues de nos pratiques d’holacratie, du genre “De quoi as-tu besoin” ? Cette question a parfois tendance à déstabiliser mes collègues. En expliquant ce dont j’ai besoin, je suis déjà en train de trouver une solution sans même m’en rendre compte.
Je rejoins Florent sur l’impact sur l’état d’esprit, c’est sûrement là qu’est l’apport le plus notable, et il est difficile de savoir si c’est l’holacratie ou notre transformation agile qui en est la cause. Je suis tentée de penser que c’est un peu des deux.
Conclusions et questionnements
Pour conclure, je dirais que l’Holacracy mérite à minima d’être expérimentée même si le “ticket d’entrée” n’est pas négligeable à la fois en terme d’accompagnement à prévoir pour faire les choses bien et d’appropriation (cf. complexité et degré de profondeur du changement d’habitudes et de façon de penser).
Et pour finir, voici quelques questionnements personnels que je partage :
- Quels auraient été les gains si les membres du département n’avaient pas déjà commencé à acquérir l’état d’esprit et les pratiques agiles au préalable ?
- Aurais-je dû imposer l’Holacracy ? Sur le moment, j’ai cru préférable de ne pas imposer l’adoption de l’Holacracy tout en présentant cette initiative comme une expérimentation. Je n’étais pas à l’aise avec l’idée d’imposer un changement aussi profond. Plus profond que l’adoption de Scrum qui l’est déjà. Cette tolérance a pu par exemple faciliter le fait qu’une des équipes abandonne en cours de route (sans tout rejeter certes). L’autre approche aurait consisté à considérer l’adoption de l’Holacracy comme une décision d’entreprise à suivre, avec bien sûr les moyens mis sur la table pour accompagner ce changement dignement.
- Peut-on vraiment arriver à se parler de rôle à rôle plutôt que de personne à personne ? J’ai constaté à quel point cela prend du temps d’adopter la bonne attitude pour interagir véritablement entre “rôles” (tel que défini par l’Holacracy) plutôt qu’entre “personnes”. Bien évidemment, ce n’est absolument pas naturel quand on a longtemps travaillé selon un autre modèle d’organisation, mais je trouve que même après une longue pratique, ça reste difficile malgré l’intérêt évident.
Photo de Cherrydeck sur Unsplash.