Et si on mettait des squads ?
Le modèle d’organisation à la Spotify semble être l’apha et l’omega des équipes techniques.
Oui, c’est aussi ce que j’ai tendance à mettre partout mais vous voulez que je vous dise ? Je ne le trouve pas si pertinent pour la plupart des cas que j’ai rencontré.
Dans les structures françaises que j’ai vu ça revient à isoler les équipes avec chacune leur propre product owner. Ça a certainement énormément de sens pour des sociétés structurées avec des groupes produit vraiment distincts qui peuvent avancer relativement isolément, chacune sur un unique enjeu ou un unique produit dédié.
Pour des startup et sociétés de taille raisonnable, je vois plus de dérives que de bénéfices. Certaines ressources sont partagées ou sous-dimensionnées, il y a plus de produits à gérer que d’équipes disponibles et les enjeux qui arrivent sont répartis sur chaque équipe en fonction des disponibilités.
Cette organisation matricielle revient rapidement à guider chaque équipe via sa propre roadmap et faire du puzzle dans les backlog pour remplir chaque itération. Les équipes se marchent sur les pieds, les ressources centrales sont surchargées, les product owners bataillement pour avoir la priorité — ou pour comprendre laquelle est-ce — et chacun est écartelé entre plusieurs demandes contradictoires dont aucune ne cadre parfois avec sa valeur ajoutée personnelle.
Vous connaissez le « ce projet est prioritaire, mais n’oubliez 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 prioritaire, parce que tout est sur une roadmap d’une des équipes ou d’un des grands enjeux, ou un sujet d’attention de tel ou tel directeur, et qu’on s’est entraînés à ne pas prioriser les sujets entre eux.
Souvent ça se traduit par lancer plein de projets en parallèle à l’intérieur même de chaque équipe, puis les laisser en sommeil avant de les finir.
Là dedans les projets transversaux sont à éliminer parce qu’ils occupent les ressources des différentes roadmap. On a à la fois l’impression de ne pas assez investir 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’environnement ne représente qu’une poignée d’équipes et qu’elles jonglent chacune avec plusieurs projets et produits. J’imagine, à l’instar des tribes de Spotify, que sur des environnements plus importants il suffit généralement de découper en mini sociétés mais je n’ai pas envie de trop m’avancer sur ce point.
Dans chaque société où je suis passé, le moment le mieux vécu à la fois par la direction et par les salariés, de très loin, est celui où tout le monde a travaillé en même temps sur la même priorité.
Tout le monde. Réellement, équipes support, marketing et direction inclus. Je ne parle pas ici que de la R&D.
Mon modèle c’est un gros kanban, idéalement avec un minimum de colonnes — souvent trois suffisent. S’il fallait caricaturer, je préfère faire un kanban de kanban qu’un tableau de kanban à plusieurs dimensions
Le kanban global c’est une priorisation commune, c’est permettre à quelqu’un de travailler sur le sujet le plus important où il apportera 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 pertinent sur tous les sujets, mais chacun connait l’ordonnancement des sujets. Chacun sait qui est prioritaire s’il y a un coup de main à donner ou une ressource à monopoliser. Chacun peut visualiser où il est le plus pertinent sans se reposer sur des comités de pilotage et autres responsables projet pour faire proxy.
On reprend les classiques. Une file de grands et petits enjeux, priorisés sans jamais deux projets au même niveau. Oui c’est compliqué, d’autant plus qu’il va falloir prioriser entre eux des enjeux marketing et des enjeux R&D, mais ne pas le faire c’est juste se bander les yeux. Avancer c’est choisir.
Pas besoin de lancer des études sur ces sujets, pas besoin d’estimations détaillée de charges ou de délais. On n’en fait que le strict nécessaire à savoir les prioriser.
Je n’ai même pas besoin de savoir si quelque chose est faisable pour le prioriser. S’il s’avère que ce n’est pas faisable et bien on réagira quand on le saura, soit en retirant l’enjeu soit en priorisant une recherche d’alternative. Entre temps avancer dessus est ou n’est pas la priorité.
Sur chaque sujet ouvert, on a un joli petit kanban habituel limité aux intervenants qui permet de suivre et piloter le projet.
L’idée c’est de gérer le nombre d’enjeux en gardant un degré de liberté suffisant. Il faut que le nombre de sujets ouverts soit trop restreint pour que tout le monde ait une affectation efficace.
Les quelques uns qui ne sont pas sur un des sujets en cours feront avancer les tâches de fond, le support, la documentation, les explorations, les résolutions d’anomalie, l’administratif… tout ce qui est essentiel mais qui ne se formalise 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 pertinent. 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 remplacer.
Enfin, comme dans toute gestion de backlog, c’est la limite qui va forcer les gens à avancer, à collaborer et à clôturer 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 collaborateurs soient prêts à abandonner leurs habitudes, à s’impliquer là où ils sont nécessaires même si ça ne les botte pas toujours sans qu’on ne vienne les chercher. Il faut que tout le monde soit impliqué à prendre des responsabilités.
Mais surtout il faut que la direction soit prête à lâcher les roadmap puzzle, à assurer son rôle de priorisation. Il faut qu’elle soit prêt à lâcher le côté rassurant des plannings détaillés et des affectations de ressources pour passer sur un pilotage par le produit et les besoins.
Pire, il faut que le management soit prêt à lâcher le contrôle et faire confiance. Toute l’organisation se base sur l’idée que chacun va choisir où aller en fonction des besoins et de la collaboration. Il faut tuer dans l’œuf toute idée de chef d’orchestre qui va bouger ses pions avec suffisamment d’agilité.
Bref, il faut que tout le monde soit prêt à changer radicalement. Quand tout va bien on ne voit pas trop l’intérêt (à raison). Quand ça commence à aller mal on prend rarement le risque, d’autant que la confiance nécessaire est souvent en perdition à ce moment là.
Au minimum il faut un mandat pour tout changer, et la confiance qui va avec.
Laisser un commentaire