unFIX model ? C’est quoi ?

Comment rendre une organisation aussi adaptable et polyvalente que son environnement ? Comment pouvons-nous préparer une entreprise à survivre et à prospérer au 21e siècle ? De nombreux modèles et frameworks vous proposent des solutions statiques ou pré-packagées. Il est temps de trouver une alternative à SAFe, LeSS, l’holacracy, le “modèle Spotify” ou encore aux organisations matricielles. Nous avons besoin de quelque chose qui porte la flexibilité à un nouveau niveau. Voici ma suggestion. Je l’appelle UNFIX.

Expliquons d’abord ce qu’ unFIX n’est pas.

• unFIX n’est PAS un framework. La définition de « framework » suggère une structure de soutien essentielle. Mais il n’y a rien d’essentiel dans unFIX. Tout est facultatif. Une meilleure description serait une bibliothèque de pattern.
• unFIX ne propose ni ne présente AUCUN processus. Le but d’unFIX est de couvrir uniquement les modèles de conception d’organisation et la structure organisationnelle. Concernant les processus, Il est simple de trouver de bons conseils à partir d’autres sources.
• unFIX n’est PAS réservé à l’informatique. Dans la bibliothèque de pattern présenté par unFIX, tout peut s’appliquer à de nombreux départements, divisions et entreprises différentes.  On ne se limite pas ici au développement de logiciels.
• unFIX n’est PAS descendant ou top-down. Contrairement à certains autres frameworks, la bibliothèque unFIX suggère une approche ascendante ou bottom-up. Vous ne pouvez pas construire quelque chose de grand. Vous devez commencer par quelque chose de petit.
• unFIX ne vient PAS en remplacement d’autre chose. Il y a beaucoup de bonnes choses dans d’autres modèles et frameworks qui ne doivent pas être jetées. Nous espérons simplement qu’avec unFIX, vous réparerez les parties défectueuses et garderez toutes les bonnes parties.

Très bien. Vous venez de voir ce que que UNFIX n’est PAS.

Vous souhaitez savoir ce qu’EST unFix ? Allons-y !

The Crew (Team, Squad) – L’équipage

Dans le modèle unFIX, un équipage ou crew en anglais, est une équipe composée généralement de trois à sept personnes. De plus grandes équipes sont possibles, selon le contexte, mais dans de nombreux cas, je ne le recommanderais pas. Comme je l’ai expliqué dans mon livre Management 3.0, pour moi la taille optimale d’une équipe est de cinq membres. Certains frameworks suggèrent sept, mais je pense que le travail hybride nécessite une taille d’équipe moyenne un peu plus petite. Les membres de l’équipe sont principalement dédiés à leur équipage, mais ce n’est pas grave s’ils réservent une petite partie de leur semaine pour travailler sur un forum. Nous verrons ce qu’est un forum dans le détail ci dessous.

Il existe sept types d’équipages :

• Value Stream Crew (alias stream-aligned team dans le livre Team Topologies)
• Facilitation Crew (alias enabling team dans le livre Team Topologies)
• Capability Crew (alias complicated subsystem team dans le livre Team Topologies )
• Governance Crew (empruntée au Management 3.0)
• Platform Crew (ou platform team dans le livre Team Topologies)
• Experience Crew
• Partnership Crew

Les équipages peuvent appartenir à l’un de ces sept types. Cependant, dans une entreprise, la plupart des équipages devraient probablement être des Value Stream crew. Ces équipes interfonctionnelles et auto-organisées gèrent leurs propres réunions (planification, enregistrement, revues et rétros); ils gèrent leur propre documentation et leurs propres releases, et ils peuvent fonctionner selon un accord d’équipe qui définit l’identité de l’équipe, les règles partagées, etc. Le modèle unFIX autorise les équipages qui ne sont pas alignés sur le flux. Il peut y avoir de bonnes raisons d’adopter l’un des six autres types d’équipage.

En tant qu’équipes autonomes et auto-organisées, ces Crews ont la responsabilité de leurs rôles, des méthodes qu’ils utilisent, des objectifs qu’ils visent, de leur cadence ou flux continu de production, et de leurs dépendances vis-à-vis des autres Crews. Tant qu’un équipage assume l’entière responsabilité de la valeur qu’il fournit, il a le dernier mot sur la façon dont son travail est effectué. Personne d’autre dans l’entreprise n’est aussi proche de l’expérience client qu’eux.

Certaines personnes appellent ces équipages des squads, des pods ou des cells, ce qui est tout à fait correct. J’aime le mot Crew car ce mot suggère que ses membres gèrent un voyage ensemble. Pour la métaphore, l’équipage d’un navire prend soin du navire et de ses passagers. L’équipage d’une compagnie aérienne est responsable d’un avion et de ses vols. Chaque équipe d’une société de logiciels s’occupe d’une base de code et de ses versions. Suivant le principe du livre dynamic reteaming, nous nous attendons à ce que ces équipages soient stables, mais ils ne sont pas statiques. Il ne devrait pas être difficile pour les gens de changer d’équipage de temps en temps.

The Captain (Team Lead)

Poussant l’analogie des navires et des avions un peu plus loin, je vois souvent émerger le besoin qu’un membre d’équipage agisse en tant que capitaine. Pas trois capitaines, pas deux capitaines, un seul. Cette personne est le contact principal d’un équipage avec le monde extérieur et elle a la responsabilité finale de tout ce qui se passe pendant le voyage. Cela ne veut pas dire que ce Capitaine donne des ordres à tout le monde. Au contraire, dans son excellent livre Turn the Ship Around, David Marquet explique qu’un bon capitaine prend en effet très peu de décisions. Un équipage performant sait s’auto-organiser, et ses membres d’équipage comprennent leurs responsabilités !

Un Crew peut avoir quelques rôles supplémentaires, tels que Product Lead, Tech Lead, etc. Selon le produit et ses dépendances vis-à-vis du monde extérieur, différents membres du Crew peuvent gérer différents canaux de communication. En fait, chaque membre de l’équipage pourrait être un « chef de file » dans certains domaines ! Il n’y a rien de mal à cela. Mais une responsabilité partagée équivaut à ne porter aucune responsabilité. La base (voir ci-dessous) pourrait insister pour qu’une seule personne soit responsable de la manière dont l’ensemble de l’équipage opère pendant son voyage. C’est le Capitaine.

La base peut avoir des règles, des restrictions et des exigences sur qui peut être le capitaine d’un équipage, compte tenu du niveau de compétence, de l’ancienneté, etc. Les capitaines peuvent être nommés ou élus. Cependant, le capitaine n’a jamais de responsabilité hiérarchique sur un équipage. Par exemple, un capitaine ne discute PAS du développement de carrière, de la rémunération ou des promotions avec les membres de son équipage. Selon le contexte, le titre de poste officiel de cette personne peut être Product Manager, Project Manager ou Platform Manager. Quoi qu’il en soit, c’est elle qui dirige le voyage, pas les membres de l’équipage !

The Base (Tribe, Business Unit)

Tous les équipages opèrent à partir d’une base. Une base est constituée d’une poignée  à quelques centaines de personnes. Cette base compte un certain nombre d’équipages organisés autour d’un ou plusieurs flux de valeur. La Base agit comme une entreprise indépendante à part entière. Elle contient toutes les compétences nécessaires pour concevoir, développer et livrer des produits, du Design Thinking au DevOps et du Lean Startup au Lean Manufacturing.

Chaque personne a une Base. C’est leur maison. La Base offre à ses membres un sentiment d’utilité, d’appartenance et de reconnaissance. Elle offre confort, sécurité personnelle, connectivité, culture partagée, ensembles d’outils partagés et opportunités de carrière pour tous les membres qui la constitue.

Idéalement, la Base couvre un domaine client et non un domaine technique. Elle est similaire dans l’idée à une tribu dans le modèle Spotify ou à un Agile Release Train (ART) dans le Scaled Agile Framework (SAFe). Cependant, la cadence et la synchronisation du travail sont facultatives. Le modèle Spotify ne le prescrit pas, pas plus que le modèle unFIX. Il peut y avoir de bonnes raisons de garder le travail de tous les équipages asynchrone. (Cela serait particulièrement vrai pour les bases faiblement alignées et les bases entièrement séparées.) C’est votre base, votre décision.

Un travail essentiel de la Base consiste à se réorganiser en permanence en fonction des besoins de l’expérience client. Nous savons que la structure organisationnelle est directement liée à l’architecture du produit. Lorsque l’architecture doit changer, l’organisation doit changer. Par conséquent, la Base met tout en œuvre pour aider ses équipages à rester flexibles. Cela inclut le respect des normes et des règles minimales pour tous les équipages afin qu’une re-structuration potentielle des équipes soit la moins douloureuse possible?

The Chiefs (Management Team)

Lorsque j’ai écrit mon récent livre Startup Scaleup Screwup, j’ai parlé avec de nombreuses startups et scaleups à travers l’Europe, notamment Spotify, Flixbus, Wise, Typeform, Zalando, Booking, Intercom et Futurice. J’ai reconnu un pattern commun dans bon nombre de ces jeunes entreprises prospères qui ne sont pas entrées dans le livre. C’était le pattern, très simple, d’une équipe de chefs dirigeant leur entreprise.

L’équipe de direction se compose généralement d’un product manager, d’un responsable de la technologie et d’un chef du marketing. Mais parfois, la répartition des rôles est un peu différente, et parfois, c’est une équipe de quatre ou cinq au lieu de trois. Quels que soient les postes et le nombre, dans la plupart des cas, les chefs ont la responsabilité de la gestion hiérarchique de tous les membres de leur base. Ils sont, littéralement, l’équipe de direction. Selon la façon dont les chefs répartissent les rôles, chacun d’eux aurait entre trois et vingt subalternes directs. En règle générale, tous les développeurs back-end relèvent d’un chef de la technologie, et toutes les personnes UX peuvent relever d’un chef de produit, et ainsi de suite. Mais le contexte devrait dicter ce qui est raisonnable.

Le principal avantage de cette approche (que diverses mises à l’échelle ont découvert bien avant moi) est que la base dispose d’une structure de rapport de gestion stable, peu importe ce qui se passe avec les équipages. Les gens gens passer d’un équipage à l’autre sans  jamais changer de manager. Belle stabilité non ? Seuls les chefs sont responsables du recrutement, de la rémunération, des promotions, etc. Dans le même temps, ils peuvent déléguer les flux de valeur aux capitaines d’équipage et l’alignement fonctionnel aux présidents de forums (voir ci-dessous).

The Forum (Chapter, Guild)

Une petite équipe de deux ou trois Chefs peut facilement gérer une Base d’une dizaine de personnes. Mais les choses deviennent un peu plus problématiques au dela de ce nombre. Lorsque la Base compte 50 personnes ou plus, l’équipe de direction aura délégué une bonne partie de ses responsabilités. Comme je l’ai indiqué précédemment, tout le travail de chaîne de valeur se déroule dans les équipages, mais certaines choses au sein de la base doivent être coordonnées selon des lignes fonctionnelles.

Un Forum est un groupe composé de personnes de différents Crews. Les forums portent le nom de chapitres dans le modèle Spotify, mais je préfère le nom Forum car il indique que son objectif principal est de permettre aux travailleurs partageant les mêmes idées de se réunir, de parler et de prendre des décisions ensemble. Il pourrait y avoir, par exemple, un forum DevOps, un forum UX, etc. Dans les organisations traditionnelles, le Project Management Office (PMO) pourrait être transformé en Forum, et dans les entreprises plus agiles, les Product Managers pourraient avoir leur propre Forum . Les chefs de base peuvent décider quels forums sont nécessaires car certains forums jouent un rôle essentiel dans la structure de l’organisation.

Les chefs peuvent déléguer des tâches aux forums, telles que la standardisation, les modèles, les ensembles d’outils, l’infrastructure, le développement personnel, la coordination inter-équipes, etc. Ils peuvent s’attendre à ce que chaque travailleur de la base soit membre d’au moins un forum et participe aux conversations et aux décisions qui comptent pour leurs domaines fonctionnels. Le rôle des Forums est d’être le tissu conjonctif entre les Équipages.

Maintenant, avant de dire que c’est la même chose que ce que font les chapitres dans le modèle Spotify, permettez-moi d’insister sur une différence cruciale : il n’y a AUCUNE gestion de ligne dans le Forum ! Le recrutement, la rémunération, le développement de carrière et les évaluations de performance ne font PAS partie du mandat d’un forum. Le but d’un forum est que les personnes occupant des rôles similaires s’entendent sur la façon dont le travail est effectué au sein de la base de manière auto-organisée afin que les changements d’équipes potentiels soit aussi indolore que possible.

The Chair (Moderator)

Le Président est le gestionnaire du Forum et NON le gestionnaire des collaborateurs. Permettez-moi de répéter cela. La personne qui modère un Forum est responsable du fonctionnement du Forum. Il n’est pas le gestionnaire des personnes qui participent au Forum. Le rôle de président est un emploi à temps partiel, généralement occupé par une personne ayant une certaine ancienneté dans la base. Il gère les discussions et les décisions, mais il n’a rien à dire sur les rémunérations ou les promotions. On peut dire que le président est le « premier parmi ses pairs ».

La principale raison de ne pas avoir de gestion de ligne dans les forums est, encore une fois, de garder l’entreprise flexible. La dernière chose que nous souhaitons, c’est une réintroduction de départements fonctionnels ! Lorsque les dirigeants des Forums obtiennent la responsabilité de la gestion des personnes, les personnes deviennent une partie de leur territoire. Cela rend beaucoup plus difficile la réduction, la division ou la fusion des forums. De plus, vous vous retrouveriez avec une organisation matricielle. Et ce n’est absolument pas ce que nous voulons.

Le modèle unFIX n’est pas une organisation matricielle. Bien sûr, différents membres d’équipage participent à différents forums et ils peuvent avoir différents chefs en tant que managers. Mais quel que soit l’équipage que vous regardez, les chefs travaillent toujours sur le même équipage de gouvernance. Les managers ont les mêmes objectifs. Lorsqu’il y a un conflit au sein d’un équipage, il ne peut s’étendre qu’à une seule équipe de direction ! Adieu matrice.

Scaling Up

De nombreuses organisations comptent plus de quelques centaines de personnes. Dans de tels environnements, les travailleurs doivent collaborer avec des collègues au-delà des limites d’une Base. Le modèle unFIX propose des suggestions de mise à l’échelle dans lesquelles tout ce qui est discuté précédemment s’applique également, de manière fractale, à des niveaux organisationnels plus élevés.

Des dizaines de bases peuvent collaborer dans une ligue. Au sein d’une ligue, ils peuvent former des clusters (semblables aux personnes formant des équipages). Certaines Bases pourraient s’auto-organiser en Value Stream Cluster, d’autres en Facilitation Cluster, Platform Cluster, Capability Cluster, etc. expériences clients.

De même, la coordination inter-Bases peut être gérée dans les Assemblées (comme les personnes coordonnant leur travail dans les Forums). Ces Assemblées sont des structures volontaires qui permettent aux représentants des Bases de coordonner les modes de fonctionnement au-delà des frontières d’une même Base.

Nous pouvons même monter d’un niveau et dire que des dizaines de ligues pourraient former une foule. Les ligues pourraient s’auto-organiser et collaborer dans des coalitions et coordonner leur travail dans les congrès. Encore une fois, tous les modèles antérieurs se répètent aux niveaux supérieurs, ce qui rend le modèle unFIX auto-similaire à toutes les échelles. C’est un modèle fractal.

Pour être honnête, la plupart de cette mise à l’échelle vers le haut avec unFIX est encore hypothétique. Nous savons que les modèles fonctionnent à petite échelle ; nous pensons qu’ils peuvent également fonctionner à grande échelle. Mais comme je l’ai dit au début. Il vaut mieux commencer petit, au niveau de la Base.

Dynamic Reteaming

Les patterns du modèle unFIX ont de nombreuses sources. Une «pièce du puzzle» est le concept de dynamic reteaming, tel que décrit dans le livre du même nom de Heidi Helfand. Le livre d’Heidi m’a aidé à réaliser que les équipes statiques ne sont pas agiles. Il y a au moins quatre raisons pour lesquelles les managers doivent permettre aux travailleurs de se réorganiser facilement et sans douleur en différentes équipes :

• Le rythme accéléré des changements environnementaux et le défi d’une crise suivie d’une autre nécessitent une capacité à former rapidement de nouvelles équipes. Lorsque votre entreprise est touchée par une fuite de données, une attaque de ransomware, un virus Covid paralysant la moitié de vos équipes ou un mouvement stratégique d’un concurrent, vous n’avez pas le temps pour votre équipe d’intervention de traverser un épisode de formation de six semaines , d’assaut, de normalisation et de performance.

• Il n’y a pas moyen de contourner la loi de Conway. Votre entreprise fabriquera des produits avec des architectures qui ressemblent à votre structure organisationnelle. Si vous souhaitez rester flexible en proposant un ensemble dynamique de produits et de services, vous devez avoir une structure d’équipe polyvalente et tout mettre en œuvre pour éviter les silos et l’ossification. Seules des structures d’équipe flexibles produisent des architectures de produits flexibles.
• Comme le montre “la grande démission”, en plus d’offrir une excellente expérience client (CX), vous êtes également responsable de l’amélioration de l’expérience employé (EX). Bien sûr, les employés veulent un sentiment d’appartenance, d’amitié et de loyauté, mais ils sont également motivés par la curiosité, la créativité et la compétence. (Voir la grille des 25 moteurs.) Une excellente expérience employé inclut le développement personnel et la croissance de carrière au-delà d’une seule équipe.
• Enfin, des suggestions bien intentionnées pour mesurer les performances de l’équipe plutôt que les performances individuelles, et pour récompenser les équipes plutôt que les individus, conduisent facilement à une sous-optimisation au niveau de l’équipe. Vous pourriez vous retrouver avec une compétition entre équipes ! Si vous souhaitez que les équipes se soucient davantage de l’expérience client dans son ensemble que de leurs performances locales, vous devrez faire des efforts pour collaborer entre les équipes.

Ne vous méprenez pas. Je ne dis pas que vous devez mélanger les gens chaque mois. Il y a en effet des avantages essentiels à avoir des équipes stables. Mais stable n’est pas statique ! Commencer, arrêter et changer d’équipe est une opportunité, pas un risque. C’est pourquoi la rééquipe dynamique était un principe essentiel pour unFIX.

Team Topologies

La deuxième source digne de mention est le livre Team Topologies de Matthew Skelton et Manuel Pais. Dans leur travail, ils soulignent que les responsabilités d’une équipe ne doivent jamais dépasser la charge cognitive des membres de son équipe. Les équipes doivent toujours comprendre chaque partie du travail qui leur appartient, sinon le réapprentissage constant les ralentit énormément. (Avec ma mémoire terrible et mon portefeuille surdimensionné, j’en souffre personnellement tous les jours !)

Le livre décrit également quatre types d’équipe fondamentaux :

• Une équipe alignée sur le flux a la responsabilité de bout en bout de l’ensemble d’un flux de valeur
  (J’appelle cela un Value Stream Crew);
• Une équipe habilitante est une équipe qui aide temporairement d’autres équipes à accélérer
  (J’appelle cela une équipe de facilitation);
• Une équipe de sous-système complexe regroupe des compétences rares et uniques au sein d’une seule équipe
  (J’appelle cela un équipage de capacité);
• Et une équipe de plate-forme propose une infrastructure ou une architecture comme s’il s’agissait d’un fournisseur
  (J’appelle cela un équipage de plate-forme).

Ces quatre types sont aussi simples que puissants. Dans mes travaux antérieurs, je ne suis jamais allé plus loin que de suggérer que chaque équipe ou unité de valeur doit offrir une valeur définie à ses clients (qui peuvent être des clients ou d’autres équipes), mais le langage et les images des topologies d’équipe rendent soudainement ma vague idée beaucoup plus pratique, et je lui en suis très reconnaissant.

(Notez que j’ai augmenté les types existants avec trois types d’équipe supplémentaires : Équipe de gouvernance, Équipe d’expérience et Équipe de partenariat).

Virtual and Hybrid

Ma troisième source d’inspiration est, curieusement, un concept informatique. La virtualisation est l’acte de créer une version virtuelle de quelque chose, y compris du matériel, des logiciels et des interfaces. Une machine virtuelle est un logiciel qui imite une machine physique. Une équipe virtuelle est un groupe de personnes agissant comme si elles étaient physiquement situées ensemble.

Si vous voulez une structure organisationnelle capable de relever les défis du 21e siècle, vous devez vous assurer qu’il n’y a pratiquement aucune différence entre une équipe physique et une équipe virtuelle. Vous devez être capable de créer des équipes virtuelles presque instantanément, avec des membres d’équipe dédiés travaillant de n’importe où, dans un groupe plus large, qui sait comment faire gonfler leurs équipes.

Cela devient encore plus important de nos jours avec l’émergence du travail hybride. Certains membres de l’équipe sont au bureau tandis que d’autres travaillent à domicile ou ailleurs. Ils entrent et sortent tout le temps, et le travail de bureau ne redeviendra jamais comme avant. Quiconque suggère que «les équipes doivent être colocalisées» est toujours bloqué à l’époque pré-Covid!

La virtualisation est le troisième principe que j’ai appliqué dans le modèle décrit ci-dessous. Votre structure organisationnelle doit fonctionner à la fois physiquement et virtuellement, permettant aux gens de travailler de manière hybride. Chacune de vos équipes virtuelles est une instance créée par un groupe plus important, et elles pourraient travailler partout sur la planète.

Let’s Wrap It All Up / Pour résumer

L’approche des topologies d’équipe nous a donné un langage pour parler des différents types d’équipe. C’est à vous de dessiner des structures organisationnelles composées de ces quatre types d’une manière qui a du sens pour vous. Avec le modèle unFIX, c’est pareil. J’ai ressenti le besoin d’ajouter trois types d’équipe supplémentaires et je vous propose les concepts d’équipages, de forums et de bases. Maintenant, c’est à vous de mettre à profit vos compétences LEGO et de commencer à construire la structure qui répond à vos besoins.

Et comment unFIX se compare-t-il aux alternatives mentionnées ci-dessus ?

En ce qui concerne le modèle Spotify, je soupçonne que chaque entreprise qui l’implémentera se heurtera au problème de la matrice : les membres de l’équipe rendent compte à différents dirigeants qui ne siègent pas les uns avec les autres dans la même équipe et qui pourraient travailler vers des objectifs différents. De plus, le modèle Spotify n’offre aucune suggestion pour la couche au-dessus de la tribu. J’ai abordé les deux problèmes avec le modèle dans cet article. (Lire : Unfixons le modèle Spotify)

Le Scaled Agile Framework a une portée beaucoup plus large que le modèle unFIX. Son public cible est constitué de grandes entreprises traditionnelles. SAFe est trop grand et bureaucratique pour les entreprises plus jeunes et plus petites. En plus de cela, SAFe est intentionnellement agnostique en matière de gestion de ligne. Cela signifie que toute mise en œuvre de SAFe au-dessus d’une structure de gestion existante est une invitation ouverte à un énorme malaise dans la matrice. (Lire : Unfixons le cadre agile à l’échelle)

Le site Web LeSS suggère la colocalisation d’équipes qui devraient «rester ensemble pour toujours» et n’offre aucune place pour les équipes habilitantes, les équipes de plate-forme ou les équipes de sous-systèmes complexes. Le travail hybride, les topologies d’équipe et la rééquipe dynamique ne reçoivent aucun amour du framework LeSS. Il me semble que ce cadre n’est pas prêt pour l’avenir. (Lire : Unfixons Scrum à grande échelle)

L’holacratie était à la mode il y a huit ans, mais peu de gens en parlent encore. Il offrait des idées novatrices, mais Holacracy a échoué parce qu’il était trop bizarre, trop abstrait et trop technique. Le modèle unFIX est plus proche de la réalité actuelle telle que vécue par de nombreux travailleurs à travers le monde. Par conséquent, il devrait être plus facile d’évaluer les changements organisationnels qui aideraient une entreprise à se rapprocher de l’image idéalisée. (Lire : Unfix Holacracy)

Et enfin, qu’en est-il du Management 3.0 ? Eh bien, je n’ai jamais osé proposer un modèle d’organisation spécifique dans mes travaux antérieurs, à part la suggestion que toutes les équipes devraient devenir des unités de valeur. La gestion 3.0 a toujours été une philosophie de gestion et une boîte à outils de pratiques précieuses. Je n’ai jamais voulu que ce soit un cadre. Mais le modèle que j’ai décrit dans cet article offre enfin une structure qui a toujours fait défaut au Management 3.0 et qui pourrait relier toute la boîte à outils.

Conclusion

Il m’a fallu douze ans pour le faire.

Il est absurde que cela m’ait pris autant de temps car la solution que j’ai montrée ici semble assez évidente. En fait, cela existe déjà depuis des années et je connais des entreprises qui l’appliquent avec succès. Il semble juste que personne ne l’ait documenté, visualisé et nommé auparavant. Au meilleur de ma connaissance, le modèle organisationnel décrit dans cet article est le plus polyvalent qui soit. La structure n’est pas nouvelle, mais cette description l’est très certainement.

Et soyons clairs : presque aucune des idées de cet article ne m’appartient. Je n’ai pu dessiner et décrire ce modèle que grâce à des suggestions que j’ai empruntées à de nombreuses sources, que j’ai laissé mijoter et se mêler dans ma tête pendant de nombreuses années. L’image est nouvelle; les idées ne le sont pas. Je connais des startups et des scale-ups à croissance rapide qui suivent déjà la plupart de ce que j’ai décrit dans cet article. Ils pourraient dire tribus au lieu de bases, équipes au lieu d’équipages ou unités fonctionnelles au lieu de forums. La terminologie n’a pas d’importance. Je propose des mots différents parce qu’ils peuvent aider les gens à distinguer le nouveau de l’ancien. En fin de compte, une structure organisationnelle ne concerne pas la dénomination ; il s’agit d’intention, de responsabilités et de prise de décision.

Je crois que le modèle unFIX tel que décrit ici est prêt pour un avenir empli de dynamic reteaming, de team topologies et d’hybrid working. Elle permet à une entreprise de devenir une véritable organisation polyvalente. Peut-être que vous saviez déjà la plupart de cela parce que vous avez vu des conseils similaires dans d’autres endroits. C’est génial. Mais je suis sûr que mes photos sont plus jolies. 🤓