Modèle d’or­ga­ni­sa­tion

Et si on mettait des squads ?

Le modèle d’or­ga­ni­sa­tion à la Spotify semble être l’apha et l’omega des équipes tech­niques.

Oui, c’est aussi ce que j’ai tendance à mettre partout mais vous voulez que je vous dise ? Je ne le trouve pas si perti­nent pour la plupart des cas que j’ai rencon­tré.

Modèle clas­sique Spotify

Dans les struc­tures françaises que j’ai vu ça revient à isoler les équipes avec chacune leur propre product owner. Ça a certai­ne­ment énor­mé­ment de sens pour des socié­tés struc­tu­rées avec des groupes produit vrai­ment distincts qui peuvent avan­cer rela­ti­ve­ment isolé­ment, chacune sur un unique enjeu ou un unique produit dédié.

Pour des star­tup et socié­tés de taille raison­nable, je vois plus de dérives que de béné­fices. Certaines ressources sont parta­gées ou sous-dimen­sion­nées, il y a plus de produits à gérer que d’équipes dispo­nibles et les enjeux qui arrivent sont répar­tis sur chaque équipe en fonc­tion des dispo­ni­bi­li­tés.

Cette orga­ni­sa­tion matri­cielle revient rapi­de­ment à guider chaque équipe via sa propre road­map et faire du puzzle dans les back­log pour remplir chaque itéra­tion. Les équipes se marchent sur les pieds, les ressources centrales sont surchar­gées, les product owners bataille­ment pour avoir la prio­rité — ou pour comprendre laquelle est-ce — et chacun est écar­telé entre plusieurs demandes contra­dic­toires dont aucune ne cadre parfois avec sa valeur ajou­tée person­nelle.

Vous connais­sez le « ce projet est prio­ri­taire, mais n’ou­bliez pas que [l’autre] est tout aussi urgent et qu’on ne peut pas manquer la date de [celui dont on parlait la semaine dernière] ou arrê­ter de travailler sur [la tâche de fond] pour autant » ? Tout est prio­ri­taire, parce que tout est sur une road­map d’une des équipes ou d’un des grands enjeux, ou un sujet d’at­ten­tion de tel ou tel direc­teur, et qu’on s’est entraî­nés à ne pas prio­ri­ser les sujets entre eux.

Souvent ça se traduit par lancer plein de projets en paral­lèle à l’in­té­rieur même de chaque équipe, puis les lais­ser en sommeil avant de les finir.

Là dedans les projets trans­ver­saux sont à élimi­ner parce qu’ils occupent les ressources des diffé­rentes road­map. On a à la fois l’im­pres­sion de ne pas assez inves­tir et d’y passer trop de temps, parce que les équipes tentent de faire tout à la fois, parfois en sous-marin.


Mon modèle idéal ne ressemble pas à celui de Spotify, du moins pas quand l’en­vi­ron­ne­ment ne repré­sente qu’une poignée d’équipes et qu’elles jonglent chacune avec plusieurs projets et produits. J’ima­gine, à l’ins­tar des tribes de Spotify, que sur des envi­ron­ne­ments plus impor­tants il suffit géné­ra­le­ment de décou­per en mini socié­tés mais je n’ai pas envie de trop m’avan­cer sur ce point.

Dans chaque société où je suis passé, le moment le mieux vécu à la fois par la direc­tion et par les sala­riés, de très loin, est celui où tout le monde a travaillé en même temps sur la même prio­rité.

Tout le monde. Réel­le­ment, équipes support, marke­ting et direc­tion inclus. Je ne parle pas ici que de la R&D.

Mon modèle c’est un gros kanban, idéa­le­ment avec un mini­mum de colonnes — souvent trois suffisent. S’il fallait cari­ca­tu­rer, je préfère faire un kanban de kanban qu’un tableau de kanban à plusieurs dimen­sions

Graphique de John Cutler, sur twit­ter

Le kanban global c’est une prio­ri­sa­tion commune, c’est permettre à quelqu’un de travailler sur le sujet le plus impor­tant où il appor­tera quelque chose plutôt que là où c’est indiqué dans le joli puzzle construit de façon macro.

Tout le monde n’est pas perti­nent sur tous les sujets, mais chacun connait l’or­don­nan­ce­ment des sujets. Chacun sait qui est prio­ri­taire s’il y a un coup de main à donner ou une ressource à mono­po­li­ser. Chacun peut visua­li­ser où il est le plus perti­nent sans se repo­ser sur des comi­tés de pilo­tage et autres respon­sables projet pour faire proxy.


On reprend les clas­siques. Une file de grands et petits enjeux, prio­ri­sés sans jamais deux projets au même niveau. Oui c’est compliqué, d’au­tant plus qu’il va falloir prio­ri­ser entre eux des enjeux marke­ting et des enjeux R&D, mais ne pas le faire c’est juste se bander les yeux. Avan­cer c’est choi­sir.

Pas besoin de lancer des études sur ces sujets, pas besoin d’es­ti­ma­tions détaillée de charges ou de délais. On n’en fait que le strict néces­saire à savoir les prio­ri­ser.

Je n’ai même pas besoin de savoir si quelque chose est faisable pour le prio­ri­ser. S’il s’avère que ce n’est pas faisable et bien on réagira quand on le saura, soit en reti­rant l’enjeu soit en prio­ri­sant une recherche d’al­ter­na­tive. Entre temps avan­cer dessus est ou n’est pas la prio­rité.


Sur chaque sujet ouvert, on a un joli petit kanban habi­tuel limité aux inter­ve­nants qui permet de suivre et pilo­ter le projet.

L’idée c’est de gérer le nombre d’enjeux en gardant un degré de liberté suffi­sant. Il faut que le nombre de sujets ouverts soit trop restreint pour que tout le monde ait une affec­ta­tion effi­cace.

Les quelques uns qui ne sont pas sur un des sujets en cours feront avan­cer les tâches de fond, le support, la docu­men­ta­tion, les explo­ra­tions, les réso­lu­tions d’ano­ma­lie, l’ad­mi­nis­tra­tif… tout ce qui est essen­tiel mais qui ne se forma­lise pas en tant que tel.

C’est ce qui va permettre aux gens de ne pas être quelque part par besoin mais parce que c’est là qu’ils sont le plus perti­nent. C’est aussi ce qui va permettre que l’équipe d’un projet qui se ferme ne soit pas forcé­ment la même que celle du sujet qui s’ouvre pour le rempla­cer.

Enfin, comme dans toute gestion de back­log, c’est la limite qui va forcer les gens à avan­cer, à colla­bo­rer et à clôtu­rer les sujets.


Mais alors pourquoi est-ce j’ai dit mettre encore partout ce vieux modèle Spotify ?

Parfois ça reste ce qui est adapté aux besoins mais souvent c’est surtout que pour mettre en place le grand Kanban il faut que les gens soient prêts.

Il faut que les colla­bo­ra­teurs soient prêts à aban­don­ner leurs habi­tudes, à s’im­pliquer là où ils sont néces­saires même si ça ne les botte pas toujours sans qu’on ne vienne les cher­cher. Il faut que tout le monde soit impliqué à prendre des respon­sa­bi­li­tés.

Mais surtout il faut que la direc­tion soit prête à lâcher les road­map puzzle, à assu­rer son rôle de prio­ri­sa­tion. Il faut qu’elle soit prêt à lâcher le côté rassu­rant des plan­nings détaillés et des affec­ta­tions de ressources pour passer sur un pilo­tage par le produit et les besoins.

Pire, il faut que le mana­ge­ment soit prêt à lâcher le contrôle et faire confiance. Toute l’or­ga­ni­sa­tion se base sur l’idée que chacun va choi­sir où aller en fonc­tion des besoins et de la colla­bo­ra­tion. Il faut tuer dans l’œuf toute idée de chef d’or­chestre qui va bouger ses pions avec suffi­sam­ment d’agi­lité.

Bref, il faut que tout le monde soit prêt à chan­ger radi­ca­le­ment. Quand tout va bien on ne voit pas trop l’in­té­rêt (à raison). Quand ça commence à aller mal on prend rare­ment le risque, d’au­tant que la confiance néces­saire est souvent en perdi­tion à ce moment là.

Au mini­mum il faut un mandat pour tout chan­ger, et la confiance qui va avec.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.