L’illusion du prêt-à-porter pour l’organisation agile

Source Image Steve Schroeder -flickr licence cc-BY-NC-2.0

L’organisation agile prête à l’emploi n’existe pas, pas plus qu’on ne peut la créer à tâtons et par itérations, sans vision d’ensemble. Dans l’article suivant, je développe pourquoi l’évolution de Github pourrait bien prouver que la notion d’organisation plate est un leurre. Comme elle pourrait prouver que réinventer la poudre, à tâtons, n’est pas toujours une bonne idée. Certes, la culture de collaboration, de méritocratie et de débrouillardise de l’open source conjuguée aux méthodes agiles peuvent être un liant pour faire travailler ensemble une large communauté, de façon relativement flexible. Ce n’est pas non plus la recette ultime pour le besoin d’adaptabilité des organisations. Il faut également se méfier des rigidités induites par certaines méthodes trop procédurières.

être agile en silos, ce n’est pas de l’agilité organisationnelle

« La croissance d’un écosystème autour d’un projet nécessite plus qu’une simple licence. Construire un projet à une grande échelle nécessite un examen attentif du modèle de gouvernance, du leadership et des obstacles à la collaboration

Harmonization 2.0: How Open Source and Standards Bodies Are Driving Collaboration Across IT, Linux foundation Networking and Orchestration White Paper

Certes, la culture de collaboration de l’open source peut être un liant pour faire travailler ensemble une large communauté, de façon relativement agile. Néanmoins, elle montre qu’à une certaine taille, il faut un cadre de décisions et d’autorité. C’est ce qu’a créé le projet linux, en 2005, avec la structure des mainteneurs, avec assez de réussite jusqu’à présent.

Le noyau linux est un projet en mode collaboratif dont on voit bien la finalité opérationnelle. Cependant, sa particularité est d’être transverse à tous les métiers, et de faire contribuer des personnes majoritairement techniques. Qui plus est, sa raison d’être opérationnelle est assez claire pour tous. Le code de conduite qui privilégie l’excellence technique toutefois ne fonctionnerait vraisemblablement pas dans un environnement plus mixte, ou, outre certains aspects d’interculturalité à gérer[1], il ne s’agirait pas que de découper de façon analytique un système compliqué en un ensemble de sous-systèmes qui peuvent être traités par des expertises précises.

Une organisation, c’est un système complexe aux multiples composants imbriqués

Les composants et le fonctionnement du système sont indissociables des interactions entre acteurs. Pour aborder cette complexité, il faut pouvoir faire dialoguer des individus aux langages, aux enjeux, et aux disciplines d’expertises, complètement différents. Néanmoins, ils ont tous autant de raisons d’être entendus, pour faire avancer le projet d’entreprise vers une direction commune . Le système de décision et d’arbitrage doit être alors d’une autre nature. C’est tout le problème de la recherche d’agilité organisationnelle à un niveau d’entreprise.

Les méthodes agiles s’appliquent très bien à des équipes autonomes à taille maîtrisée. Au sens où elles restent capables de s’adapter au changement en étant au plus près des besoins des clients et des utilisateurs, grâce à de la communication directe. Néanmoins cela reste de l’agilité dans l’exécution. Il manque une marche d’escalier entre l’agilité stratégique de l’entreprise et l’agilité tactique du projet. Surtout si on se met à créer de très nombreux projets en méthodes agiles sans coordination. Imaginons qu’ils partent vers plusieurs axes stratégiques, tous avec des directions différentes, le résultat pourrait ne pas être très satisfaisant.

On peut très bien avoir des silos d’agilité, des cellules agiles avec un haut niveau d’excellence opérationnelle. Cependant, au milieu d’un organisme sans forcément de raison d’être globale, comment assurer que le tout marche dans une direction voulue? Les choses seront certainement mieux faites, plus rapidement, au niveau de l’exécution des projets. Toutefois, comment garantir au niveau global de l’organisation, que le modèle tient la route? Arbitre-t-on les ressources entre projets en fonction de l’alignement avec des objectifs stratégiques? Des indicateurs formalisent-ils le suivi des buts de l’organisation, afin que l’ensemble des projets délivrent le maximum de valeur? Qui a la responsabilité pour arbitrer quoi ? A-t-on une culture commune qui favorise l’implication et la motivation inter fonctionnelle de toutes les parties prenantes ?

Github : comment garder l’équilibre entre flexibilité et stabilité?

octocat de github

GitHub en quelques dates

2005 Création du logiciel de gestion de versions distribuées Git, par Linus Torvalds, sous licence open source GPL V2.

2008 Création de Github à San-Francisco par Preston-Werner, Wanstrath, et Hyett.

C’est une plate-forme d’hébergement de code (des espaces de dépôts de fichiers de code source) outillée autour de Git, pour travailler à plusieurs développeurs sur un projet open source. Les développeurs bénéficient d’espace de dépôts gratuits sous condition de laisser le code accessible, visible et modifiable à tous. Pour des dépôts privés, il faut souscrire à un abonnement mensuel (personal plan)

2010 Lancement de Github organization (pour gérer permissions, droits et collaborateurs).

2011 Lancement de Github enterprise, la version installable en entreprise.

2015 La société est valorisée à 2 milliards (du fait des fonds levés) pour 250 employés.

2016 Des pertes de 66 millions de dollars pour 98 millions de dollars de revenus sur neuf mois. Github atteint et dépasse les 500 employés.

Son chiffre d’affaire provient à 50% des comptes Github Enterprise, 37% des « organization plan » et 13% des « personal plan ». Des analystes considèrent que Github est relativement statique face aux « nouveaux » entrants sur son marché (Gitlab création 2011, Bitkeeper créé par BitMover avant 2002, passé en open source en 2016 ….)
Mars 2018 Github affiche 800 employés, 80 millions de dépôt de codes et 27 millions de développeurs qui l’utilisent

Juin 2018 Rachat par Microsoft pour 7,5 milliards de dollars.

Une culture a priori ouverte et indépendante

L’évolution de la société Github, créée en 2008 et rachetée en juin 2018 par Microsoft, est assez pertinente à étudier dans ce contexte, à plus d’un titre.

D’abord au regard de la question « comment garder un équilibre entre flexibilité et stabilité en grandissant? » considérant sa forte croissance sur dix ans. Ensuite, parce qu’on a ici une société qui s’est créée initialement sur la proposition d’outils de collaboration. Lesquels outils devaient aider les développeurs des communautés du libre à mieux « travailler ensemble ». Par conséquent, a priori, la culture de départ serait collaborative et agile. Enfin, c’est aussi une société qui cristallise l’imagerie projetée par les modes organisationnels et la culture de l’open source, mais pas forcément de façon rationnelle. Comme on peut le constater sur les réactions concernant le rachat par Microsoft mais aussi sur ce qui a pu être écrit d’un certain modèle supposé d’organisation plate qui a, pour le coup, complètement disparu en 2014.

De nombreux développeurs voire organismes de recherche ont retiré leurs projets open source de Github , à l’annonce du rachat[2]. Le tout pour basculer sur un proche concurrent, Gitlab. Or de nombreux développeurs sont à la fois sur l’un ET l’autre, voire sur Bitbucket aussi. Alors, quelle mouche (ou naïveté) les a piqué? Serait-ce le côté société privée américaine de Microsoft et son passé estampillé « logiciel propriétaire » qui ferait craindre de perdre la culture « indépendante et ouverte » de Github?

Github est une société américaine à but lucratif

Il est bon de rappeler que Github, société privée de San Francisco, n’a jamais été une association à but non lucratif ou résolument orientée vers « le bien commun » ou la logique des communs. Certes, l’offre d’hébergement initiale était gratuite pour une certaine catégorie de population sous certaines conditions. Toutefois cela n’est pas en contradiction avec l’intention de développer un modèle économique rentable avec des offres payantes derrière. Comme par exemple … Google ? Facebook ?

Github a démarré avec des services d’hébergement gratuit pour développeurs open source en se finançant sur des levées de fond, pour aller ensuite proposer des services payants à des individus ou des organisations, qu’ils soient open source ou non. D’ailleurs, le modèle économique de Gitlab n’est pas fondamentalement différent.

Les GAFAM aiment l’open source

Ce n’est pas parce que Github propose des outils construits autour d’une solution open source, Git, que Github n’héberge que de l’open source. De plus, Microsoft est devenu un grand contributeur aujourd’hui de l’open source. Comme c’est le cas pour Google ou Facebook ou Amazon. En bref, toutes les GAFAM, à part Apple, contribuent à l’open source. Entre autres, elles y trouvent l’accès à un vivier de compétences de développeurs pour travailler plus rapidement sur plus de projets. Enfin, il y a fort à parier que Github poursuivra son développement « parallèle » aux produits de Microsoft, comme Linkedin. Car les deux ont un intérêt pour Microsoft en tant que réseaux professionnels. Ils permettent, à bien y regarder, de rechercher et faire travailler ensemble des « travailleurs intellectuels », grâce à un graphe de connaissances qui formalise et relie les compétences. Voire qui permettrait de mieux cibler des offres …

L’organisation plate serait assez agile pour en finir avec la bureaucratie

Ces précisions effectuées, regardons de près l’intention initiale prêtée aux créateurs de Github de vouloir une organisation plate, une culture sans chef (sans « titre » et sans « chef officiel »). En 2013, un article de FastCompany, de Chris Dannen[3], mettait en exergue le fait que Github, compagnie privée de 175 employés à l’époque, appliquait la culture collaborative de l’open source à son modèle organisationnel, et que le succès et la croissance rapide venait d’avoir supprimé la bureaucratie en ayant un modèle d’allocation de ressources sur le principe du volontariat. En gros, chacun travaillait sur ce qui lui plaisait, dans une organisation plate. « Contrairement aux entreprises traditionnelles où les projets sont assignés dans une approche « top-down », les GitHubbers s’attaquent aux projets qu’ils souhaitent, sans aucune demande formelle ou ingérence managériale ».

Nous nous concentrons énormément sur la communication dans l’entreprise. Tous les outils que nous construisons visent vraiment à améliorer la communication; en soi, c’est la nature profonde de GitHub. Il s’agit de fournir un moyen de faciliter la communication directe entre un nombre de personnes élevé, au-delà des normes usuelles d’efficacité.

Tom Preston-Warner, interview 2013 dans FastCompany

L’article était intéressant, appuyé sur de nombreux entretiens en interne, et insistait sur l’ingrédient clé du succès, la communication. Une communication claire en interne conduisant à la fois à de bon produits et à une communication claire en externe, grâce aussi à la capacité du leadership (en l’occurrence Tom Preston-Werner, PDG et cofondateur) de résumer les buts de la société en quelques phrases clés. Le fonctionnement des projets étaient similaire aux sous-systèmes du noyau linux, une logique d’au plus-près de l’action. Les projets avaient une « primary responsible person », en principe la personne la plus concernée par l’action selon l’hypothèse que « les personnes les plus proches du problème connaissent le mieux le problème et prennent probablement les meilleures décisions à ce sujet ».

Oui mais … En 2014, de nombreux articles de journaux relaient la décision du co-fondateur Wanstrath, reprenant le poste de PDG après le départ de Preston-Werner, d’en finir avec l’organisation plate et de mettre en place des managers intermédiaires[4].

La tyrannie de l’absence de structure

Certains ont vu dans cette décision les conséquences de problèmes relationnels issus de l’organisation plate, d’autant que le départ de Preston-Werner s’effectuait dans un cadre houleux. Une ancienne employée, Julie Ann Horvath, alléguait alors avoir dû faire face à des comportements sexistes et subi des pressions pour partir. Quelle que soit la part de responsabilités des uns et des autres dans cette situation, elle illustrait parfaitement le fait qu’une organisation réellement plate n’existe pas vraiment, ni dans la perception des personnes, ni dans les faits. Dans les groupes supposés non hiérarchiques, des structures de pouvoir invisibles se mettent en place, sans avoir officiellement de comptes à rendre.

Il n’existe pas de groupe sans structure. N’importe quel groupe de personnes, indépendamment de leur nature, qui se rassemblent pour n’importe quel laps de temps et n’importe quel objectif, se structurera inévitablement d’une manière ou d’une autre.

Jo freeman, The tyranny of structurelessness

Etre vraiment sans manager n’était pas notre intention, à aucun moment. Nous souhaitions construire une société où il ferait bon travailler et qui serait très productive quant à la fabrication de nos produits. Au début, avoir des chefs n’était pas une nécessité, donc nous n’en avions pas. Je pense qu’il y avait un consensus sur le fait que nous passerions à un autre système quand les fissures apparaîtraient. Et les fissures sont apparues. Cela a commencé avec des gens frustrés de ne pas pouvoir aller aussi vite qu’avant. Davantage de contrôles ont été mis en place, et pour cause: GitHub était devenu un logiciel critique pour des millions de personnes, et nous ne pouvions plus avancer au hasard.

Zach Holman Githubber de 2010 à 2014

Ne pas formaliser et communiquer de règles de gouvernance pour clarifier les périmètres d’autorité et de responsabilités des uns et des autres, conduit à la « tyrannie de l’absence de structure » dénoncée par Jo Freeman dans l’essai du même titre en 1972, suite à son expérience des organisations féministes « sans chef » des années 60s. C’est l’angle adopté par le magazine wired dans l’article de Klint Finley, du 20 mars 2014[5]. Ainsi l’auteur développe comment, dans les organisations modernes dites plates, le culte de la bonne personne pour occuper le poste, the « right fit », au sens d’un ajustement parfait de la personne à la culture interne et aux comportements existants dans l’entreprise, conduit à une culture de la reproductibilité ou de la similarité qui tend à employer des gens similaires aux fondateurs.

C’est-à-dire, pour la culture de la Silicon Valley, et de Github, en général de jeunes hommes blancs. Ce qui est loin du code éthique du hacker tel que formalisé au MIT qui suppose de placer les individus au même plan, parce que ce type de sélection induit de facto un jugement de valeur. C’est également contreproductif si l’idée d’une organisation plate est de faire travailler des gens qui autrement ne collaboreraient pas ensemble. Car, selon une étude de la Kellogg School of Management [6], injecter de la diversité dans les équipes (hétérogénéité de genre, de groupes sociaux, etc.) conduit à les rendre plus efficace en termes de résolution de problèmes et de prise de décisions.

l’arbitraire plutôt que l’arbitrage

Certes, la notion de structure plate peut conduire aux dérives d’une autorité officieuse, où les jeux de pouvoir ne sont pas transparents mais implicites et où cela suppose de naviguer dans des relations professionnelles d’ordre plus affectives que rationnelles. Lorsqu’il n’y a pas de processus transparent et de communication sur les prises de décisions et les responsabilités, le règne est plus celui de l’arbitraire que de l’arbitrage objectif. De plus, on ne peut pas vraiment parler de structure plate quand la société appartient exclusivement aux fondateurs. En d’autres termes, on ne peut pas demander à tout le monde de prendre le même niveau de risques et d’investissement personnel, si le bénéfice n’est pas unilatéralement réparti par la suite.

Le dilemme de l'innovateur

Dans son livre le « dilemme de l’innovateur » paru en 1997, le professeur de gestion d’entreprise à l’université de Harvard, Clayton M. Christensen, explique que des entreprises en position dominante sur un marché, bien qu’excellentes opérationnellement, peuvent ne pas survivre à des innovations de rupture dont elles ont pourtant identifié le potentiel de transformation, mais dans lesquelles elles ne veulent pas investir.
acte 1: priorité au soutien, pas à la rupture
En réalité, elles passent une grande partie de leur temps à améliorer la robustesse de leurs produits existants pour satisfaire aux retours de leurs clients les plus importants, selon des critères établis de performance. C’est ce que Christensen appelle des innovations de soutien. Du coup, elles peuvent écarter des innovations de rupture en les ignorant ou en les combattant.
acte 2: apparition de la concurrence
De petites sociétés plus agiles lancent alors des solutions qui sont apparemment moins performantes au départ, plus « bas de gamme », mais qui répondent, grâce à de nouveaux attributs, à des demandes qui n’existent pas encore (ou inexprimées), perdues de vus dans le processus d’amélioration incrémentale des solutions éprouvées. Au fur et à mesure où l’innovation de rupture gagne en popularité, et son concepteur en ressources, elle peut devenir le nouveau standard du marché.
apparition du dilemme
C’est là où apparaît le dilemme, car en voulant « bien faire », en ne voulant pas mettre en danger ce qui a fait son succès, l’innovateur risque … de passer à côté de la prochaine innovation de rupture en préférant investir dans l’amélioration de l’existant. Christensen aurait été un livre de chevet de Steve Jobs et l’aurait inspiré pour lancer l’iphone alors qu’il risquait de cannibaliser l’ipod.

Quoiqu’il en soit, au-delà des limites humaines des organisations plates que l’article de wired s’employait à analyser, Github avait aussi atteint un stade où il devenait nécessaire de stabiliser son offre produit. L’organisation de départ visait simplement à plus de productivité et à créer un marché. A un certain niveau de croissance, quand le produit est utilisé de manière intensive par des millions de personnes, sa robustesse devient critique et peut nécessiter de repenser l’organisation pour la garantir. Tout le problème est ensuite de jouer sur la flexibilité et la stabilité, pour résoudre au mieux le fameux dilemme de l’innovateur.

La pression de la croissance (passage de 150 employés à 600 en trois ans), la nécessité de mettre en place plus de contrôles sur le produit, font que la structure de l’organisation ne cadrait plus avec la proposition de valeur que la société souhaitait délivrer.

« fail fast, fail early », toujours?

Fidèle en quelque sorte à la loi de débrouillardise et le mantra « fail fast, fail early » originellement de Google, mais qui a de quoi soulever quelques controverses (cf. l’article de Todd Olson sur le fallacieux « darwinisme de la conception »[7]), Github a tâtonné pour essayer de trouver par la pratique de nouvelles pratiques managériales et un nouveau mode organisationnel. Ce ne fût pas sans douleurs et sans heurts, si on en croit le témoignage instructif et factuel de Zach Holman, un employé connu de Github et un des premiers, y ayant travaillé cinq ans, de 2010 à 2014 avant d’en être licencié.

Dans son répertoire Github, holman/ama (A repository to ask @holman anything), il répond assez longuement à une question qui lui est posée en 2016 sur la réorganisation de GitHub en 2014[8]. En tant qu’ancien employé, il témoigne de la difficulté à devoir supporter des réorganisations nombreuses, et qui se succèdent sur de court laps de temps, faute de trouver rapidement le bon mode.

Tâtonner n’est pas toujours innover

Cette recherche « à tâtons » peut être présentée comme de l’innovation. Parfois cela peut en être et d’autrefois, c’est l’envie de réinventer la poudre qui prédomine, avec un certain amateurisme dans la recherche. C’est une leçon connue depuis longtemps et qui peut très bien s’appliquer à une startup qui grossit comme à une grande entreprise qui se modifie : il faut savoir accompagner le changement. Si l’expérimentation produit se conçoit aisément à un certain stade de développement, pour en valider la conception, a contrario, l’expérimentation organisationnelle n’est pas forcément une bonne chose à vivre et mieux vaut préparer les transitions de modèles. Le produit, lui, ne ressent pas grand-chose.

Nous construisons un outil pour les développeurs de logiciels, mais nous expérimentons empiriquement* aussi l’avenir du travail. Cette expérimentation nous a mené sur des chemins plutôt intéressants, et nous sommes devenus une meilleure compagnie parce que nous avons emprunté ces chemins, mais tous ces chemins n’étaient pas les bons(* expérimentation empirique est une traduction du terme hacking)

Kakul Srivastava, vice-président product management chez GitHub dans the globeandmail.com, septembre 2016

Github n’est pas le seul exemple où le principe de méritocratie seul ne suffit pas, sauf à se heurter, dès l’atteinte d’une certaine masse critique d’interactions entre différents acteurs ayant des enjeux différents, à des « fissures » de l’organisation. C’est-à-dire plus clairement, des dysfonctionnements qui empêchent de faire les bonnes choses et de créer de la valeur pour toutes les parties prenantes, en prenant en compte les risques et les contraintes.

C’est le cas de Kubernetes, un des principaux outils que Google a rendu open-source et offert en 2015 à la cloud Native Computing Foundation, qui apporte l’orchestration et la gestion de clusters de containeurs en complément d’outils comme docker. Dans un post sur github, le 26 janvier 2017, Bob Wise, general Manager GM – Open Source Container Services à Amazon Web Services et contributeur du projet Kubernetes, proposait de créer un troisième groupe de gouvernance au projet, avec des séparations très claires de l’autonomisation et des responsabilités.

Grandir, c’est aussi apprendre à se gouverner

Le cas kubernetes et le besoin de structures claires de gouvernance

Un des plus délicats des équilibres entre les forces avec lequel notre projet doit composer est de trouver la bonne balance entre, d’une part, la rapidité d’innovation et de livraison de nouvelles fonctionnalités et d’autre part, le besoin des utilisateurs en production de disposer d’une infrastructure stable et fiable. Plus le projet a eu d’utilisateurs, plus il a eu de contributeurs. Les pratiques plus informelles qui convenaient à notre projet à son démarrage, se révèlent désormais inadaptées.
En partie parce que ces pratiques informelles étaient fondées principalement sur les relations personnelles des contributeurs initiaux. Ces pratiques et normes apparaissent opaques aujourd’hui aux nouveaux contributeurs et deviennent même des barrières pour les attirer et s’assurer qu’ils puissent devenir des membres productifs de notre communauté.
Bob Wise, compte countspongebob,
27 janvier 2017 (
https://github.com/kubernetes/community/issues/295)

S’il semblerait que le modèle de gouvernance de la communité Kubernetes soit encore en rodage, le besoin tel que formulé par Bob Wise dans son post initial, montre encore une fois que toutes les communautés open source sont confrontées, dès qu’elles rencontrent le succès et grandissent en nombre d’utilisateurs, au fait de devoir garantir que toutes les évolutions résultent bien dans des produits opérationnels, robustes et durables. Les composantes de ces produits étant de plus en plus imbriquées, la simple méritocratie commune à tous les projets open source ne suffit plus, il faut aller au-delà.

Promouvoir les personnes sur le périmètre, la qualité, la quantité et la durée de leurs contributions est logique pour un projet collaboratif sur la base du volontariat. Pour avoir une autorité sur un domaine, il est important d’avoir contribué significativement aux avancées dans ce domaine. Beaucoup de projets open source se sont ainsi constitués au démarrage en croyant que la méritocratie seule suffisait dans une structure plate. Outre l’aveuglément éventuel vis-à-vis des structures de pouvoir invisibles, à un moment où à un autre, des structures de décisions et d’arbitrage sont à mettre en place en plus. Surtout si le projet rencontre le succès et doit gérer de plus en plus de contributeurs en co-opétition.

Tout gros projet a besoin d’une gouvernance

C’est le cas de n’importe quelle organisation, publique ou privée. Ce qui nous amène à la question essentielle. Si une organisation plate ne convient pas à un projet de grande taille, ni à une petite entreprise ayant vocation à grandir, et si les modes organisationnels et pratiques managériales du vingtième siècle ne sont plus adaptés à l’agilité et à la coopération, que faut-il faire? Beaucoup d’études et de travaux ce sont concentrés sur ce que voulait dire agile pour répondre aux besoins d’adaptabilité des organisations en s’inspirant des méthodes agiles des projets de développement.

Jim Highsmith, auteur de plusieurs livres[9] sur le sujet des méthodes de développement agiles, co-auteur du « agile manifesto », co-fondateur de l’alliance agile et du «agile Project leadership Network», caractérise l’agilité avec deux capacités majeures (en prenant garde à préciser qu’on n’y arrive pas en cinq étapes faciles) :

  • L’agilité est la capacité de créer et de répondre au changement afin de rester profitable dans un environnement d’affaires turbulent (au sens d’incertain, mouvant et dynamique).
  • L’agilité est la capacité à équilibrer la flexibilité et la stabilité

Pourquoi, et avec qui, devenir agile?

La deuxième partie de la définition est là où le bât blesse pour les start-ups qui grossissent (le chemin vers la stabilité). Quant à la première partie, elle est l’épine dans le pied de sociétés établies (créer ou répondre au changement). Dans tous les cas, cette définition oublie une capacité fondamentale quand on en vient à l’agilité organisationnelle qui est de l’ordre des sciences humaines. Il s’agit de « la capacité à faire travailler ensemble de manière fluide et efficace, concertée et coopérative un groupe de parties prenantes vers un but commun ».

Si une organisation est capable de cela, l’agilité telle que définie par Jim Highsmith suivra. Il ne faut pas perdre de vue les enjeux, les objectifs et les exigences des parties prenantes pour qu’il y ait une utilité à ce qu’on fait. Rester « profitable » de manière durable, être capable de créer le changement – ou plutôt faire émerger les besoins de changements, sont des conséquences.

Holacracy©, un remède miracle pour l’agilité ou un cadre bureaucratique rigide?

L’Holacracy© est une méthode et une marque déposée par Brian Robertson et issue de son expérience de PDG d’entreprise de logiciels. Il en développe la promotion au sein d’HolacracyOne.
Les principes
Ayant des principes communs avec le « au plus près de l’action » de la méritocratie open source, l’holacracy® a aussi des différences et propose un nouveau système de management, avec un cadre de gouvernance qui structure les responsabilités et les décisions. Ce cadre oppose à l’organisation hiérarchique pyramidale, des notions de cercles plus ou moins en réseau, plus ou moins dynamiques, de rôles (et non de titre de poste), de redevabilités et également des règles du jeu en réunion, pour rester factuel, régler les conflits et arbitrer en évitant de s’enliser dans la recherche de consensus. La méthode est très détaillée sur la manière de procéder. L’emblématique PDG de Zappos, Hsieh, en est un fervent promoteur et pratiquant.Mais pas forcément pour le plus grand bonheur de ses troupes
les critiques Un article de quartz a même titré « Zappos se débat avec l’holacracy parce que les humains ne sont pas conçus pour fonctionner comme des logiciels ». Selon Robertson, L’holacracy® est semblable à un système d’exploitation d’ordinateur, mais pour organisation. Sauf que la répartition des tâches entre ressources humaines et autrement plus subtile qu’entre ressources machines, et que le système complet de l’holacracy© peut en venir à favoriser davantage la rigidité de ses propres processus que l’adaptabilité humaine, comme le soulignent julia Culen dans son témoignage sur medium, ou Jurgen Apollo dans Forbes. Ce dernier déclare même que « L’holacracy© est un cadre bureaucratique imposé du haut vers le bas, c’est exactement le contraire de ce dont l’agilité du 21e siècle a besoin« [10]

C’est un équilibre entre créativité, autonomie, motivation et engagement et contrôle. Quelques soient les méthodes que vous mettrez en place, la condition sine qua non de succès, dépendra de la gouvernance choisie pour guider les actions des acteurs, mais aussi leur partage de responsabilités. Il s’agit plus de définir dès le début, des principes directeurs et de clarifier de façon transparente pour tous, la manière dont les décisions seront prises (c’est à dire comment, par qui et sous quelles conditions) pour accomplir, en suivant ces principes directeurs, les missions que s’est fixée l’organisation.

Pourquoi faire?

A force de se focaliser sur l’agilité à faire, on en oublie la question de départ. Pourquoi faire ? Les méthodes agiles qui sont proposées aujourd’hui aux organisations ont en commun d’avoir été développées de manière empirique sur le terrain, puis généralisées. On peut se dire que ceci est une bonne chose, car cela en prouve le côté opérationnel.

A contrario, si des principes communs de bonne gouvernance peuvent s’appliquer à toutes les entreprises, chaque entreprise doit investir pour développer sa propre gouvernance, sans en répliquer une autre, en fonction de sa stratégie, ses ressources, sa vision, et surtout sa culture. Le facteur humain est essentiel pour obtenir le comportement souhaité de tous les acteurs impliqués, en particulier pour qu’ils puissent travailler ensemble de manière à la fois autonome, mais aussi coordonnée et coopérative, vers des objectifs communs, qui nécessitent d’être formalisés.

Aussi un cadre de gouvernance qui s’applique bien à une culture n’est pas reproductible tel quel à n’importe quelle autre. Le fait de dire qu’une méthode d’agilité opérationnelle a été empiriquement éprouvée dans le cadre de l’évolution d’une société, n’est pas, dès lors, une garantie de réussite pour tous les contextes et prétendre qu’on a trouvé la solution révolutionnaire est excessif. C’est ce qu’on peut reprocher, sans en nier l’intérêt, aux méthodes telles que l’holacracy©.

La gouvernance prête à l’emploi n’existe pas.

Créer le bon mode de gouvernance qui permettra d’adapter continuellement la balance entre flexibilité et stabilité, est le défi de réflexion que les organisations vont devoir relever pour réussir durablement leur transformation numérique.
Pour mieux appréhender ce défi, ont peut conclure, suite aux réflexions précédentes, que quelque soit ce mode de gouvernance, il devra répondre aux besoins suivants de l’organisation :

  • Constituer avec les parties prenantes un cadre de responsabilités (qui a la responsabilité sur quoi, comment) adapté à sa taille, sa stratégie et sa culture, pour définir un équilibre entre créativité et contrôle, autonomie et engagement
  • Formaliser et communiquer ce cadre de gouvernance à tous et que ses règles du jeu, processus et outils soient assez simples d’usage pour ne pas alourdir la coopération, tout en étant respectés
  • Inclure dans ce cadre de gouvernance une structure compétente pour prendre les décisions sur les grandes directions à suivre/les objectifs stratégiques. Cette structure aura l’autorité ultime, dans un mécanisme défini, pour arbitrer en cas de conflits d’allocations de ressources entre projets/initiatives
  • Pouvoir faire évoluer ce cadre, en cas de goulot d’étranglement ou de dysfonctionnement, avec un mécanisme transparent d’arbitrage objectif impliquant les parties prenantes
  • Fournir à ses membres les outils pour « travailler ensemble »

Le dernier point n’est pas le moindre, pour chercher à rompre avec les modèles organisationnels « classiques ».

fournir les outils pour contrôle le cadre, et pour sortir du cadre

Car aujourd’hui, fournir les moyens de travailler ensemble, c’est fournir un cadre de travail et les moyens … d’en sortir! En effet, il faut savoir réunir des compétences pluridisciplinaires qui n’ont pas forcément l’occasion de travailler ensemble. Du moins, cette collaboration est limitée dans une logique de processus opérationnels classiques. En multipliant les occasions de coopérer et en coordonnant cette coopération, l’organisation se donne le moyen de réinventer son fonctionnement. Parce que ses processus seront revus avec des regards neufs et complémentaires, elle en identifiera mieux les dysfonctionnements. Finalement cela revient à favoriser l’intelligence collective. C’est-à-dire créer les conditions où le tout, habilement incité à devenir créatif, vaut plus que la somme des parties.

Références et liens

[1] A ce sujet de l’interculturalité du noyau linux, lire : https://framablog.org/2015/10/14/une-contributrice-du-noyau-linux-jette-leponge/ et http://sarah.thesharps.us/2015/10/06/what-makes-a-good-community/

[2] « En une heure, 13 000 projets ont été basculés de Github à Gitlab ». Article numera, Nelly Lasage, 6 Juin 2018

[3] Inside GitHub’s Super-Lean Management Strategy–And How It Drives Innovation, Chris Dannen, Fastcompany.com, 18/10/2013

[4] https://www.theglobeandmail.com/report-on-business/small-business/startups/why-github-finally-abandoned-its-bossless-workplace/article31718152/

[5] “Why Workers Can Suffer in Bossless Companies Like GitHub” https://www.wired.com/2014/03/tyranny-flatness/

[6] « Better decisions through diversity » https://insight.kellogg.northwestern.edu/article/better_decisions_through_diversity

[7] https://medium.com/the-design-innovator/iteration-is-not-design-668695445f76

[8] « How did managers get introduced in 2014, and did it really change everything »? https://github.com/holman/ama/issues/800

[9] Auteur en particulier du livre Agile Software Development Ecosystems (Addison-Wesley, 2002). Il y examine les principales caractéristiques et techniques associées à chaque approche Agile majeure: programmation extrême (XP), méthodes Cristal, Scrum, méthode de développement de systèmes dynamiques (DSDM), développement Lean, développement de logiciels adaptatifs (ASD), et Développement piloté par des fonctionnalités (FDD).

[10] Voir le livre « Holacracy: The New Management System for a Rapidly Changing World” de Brian J Robertson, Juin 2015, et aussi le site https://www.holacracy.org/ . En français, on trouvera sur le site d’igipartners (https://igipartners.com/), de nombreuses explications sur le sujet. En particulier, une bande dessinée pour présenter clairement les concepts (https://labdsurlholacracy.com/bande-dessinee-holacracy).

Côté critiques, il est intéressant de lire l’article de quartz de décembre 2016 : https://qz.com/849980/zappos-is-struggling-with-holacracy-because-humans-arent-designed-to-operate-like-software/.
De plus, on peut lire l’article de 2016 Jurgen Appelo dans forbes, https://www.forbes.com/sites/jurgenappelo/2016/07/14/holacracy-is-fundamentally-broken/#7d75f09b1126.
Similaire mais complémentaire, le témoignage de Julie Cullen https://medium.com/@juliaculen/holacracy-not-safe-enough-to-try-434c748238e6. Ainsi que l’article de la Harvard Business Review « https://hbr.org/2016/03/top-down-solutions-like-holacracy-wont-fix-bureaucracy?

Laisser un commentaire

Your email address will not be published.

top