Le Chapter Lead, un rôle agile à tester ?

Les cadres agiles sont un mode de gestion de produit qui repose sur un constat simple : il est contre-productif de définir et de planifier la totalité des fonctionnalités du produit, dans les moindres détails, avant de le développer. En effet, il est rare que tout se passe exactement comme prévu. Souvent, des aléas surviennent et obligent les parties prenantes à revoir la planification. De plus, les besoins évoluent parfois très vite et les fonctionnalités spécifiées plusieurs mois plus tôt peuvent devenir obsolètes. Enfin, les retours des utilisateurs vont permettre d’aiguiller le produit, et pas toujours dans la direction que l’on imaginait au départ.

L’agile se veut donc itératif, incrémental et adaptatif. Le développement du produit a lieu par “sprints” successifs amenant chacun de nouvelles évolutions. Ainsi, le produit peut être testé et amélioré en continu. Les premiers retours et les adaptations qui en découlent sont très rapides, contrairement au cycle en V.

Le grand parapluie agile abrite plusieurs modèles, tels que Scrum ou Kanban. Les rôles les plus connus sont le Product Owner, le Scrum Master et les membres de l’équipe. La famille agile s’est agrandie, notamment pour répondre à des problématiques de mise à l’échelle. C’est dans ce contexte que sont apparus d’autres cadres comme SAFe, Nexus, LeSS… L’entreprise Spotify a fait parler d’elle en expérimentant sa propre organisation d’agilité à l’échelle, au sein de laquelle elle a testé ses propres concepts et rôles, dont celui de Chapter Lead.

Spotify – Ceci n’est pas un modèle

Spotify est une entreprise de la tech suédoise qui domine le domaine du streaming musical dans le monde. En 2012, elle publie l’article « Scaling Agile @ Spotify », un arrêt sur image de son expérimentation agile à l’échelle. Aussitôt, le document est érigé au rang de modèle par ceux qui croient y déceler la recette magique du succès. Nombreux sont ceux qui l’ont implémenté sans le questionner, et nombreux sont ceux qui l’ont regretté puis âprement critiqué.

Pourtant l’avertissement en 1ère page était on ne peut plus clair :

Disclaimer: Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working – a journey in progress, not a journey completed. By the time you read this, things have already changed.

Avertissement : Spotify (comme toute bonne entreprise agile) évolue rapidement. Cet article n’est qu’un instantané de notre manière actuelle de travailler – un cheminement en cours, pas un cheminement achevé. Lorsque vous lirez ceci, les choses auront déjà changé.

Qu’importe. Certains essaient toujours de l’implémenter tel quel. Et chez Spotify, on s’en désole :

The co-author of the Spotify model and multiple agile coaches who worked at Spotify have been telling people to not copy it for years. Unfortunately, truth doesn’t spread as quickly or as widely as an idea people want to believe in.

“Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.”

—Joakim Sundén, agile coach at Spotify 2011–2017

“It worries me when people look at what we do and think it’s a framework they can just copy and implement. […] We are really trying hard now to emphasize we have problems as well. It’s not all ‘shiny and everything works well and all our squads are super amazing’.”

—Anders Ivarsson, co-author of the Spotify whitepaper

https://www.jeremiahlee.com/posts/failed-squad-goals/

Le co-auteur du modèle Spotify et de multiples coachs agiles qui travaillaient chez Spotify ne cessent dire aux gens de ne pas le copier, depuis des années. Malheureusement, la vérité ne se répand pas aussi rapidement et aussi largement qu’une idée en laquelle les gens veulent croire.

“Même à l’époque où nous l’avons écrit, nous n’étions pas en train de le faire. C’était en partie de l’ambition et en partie de l’approximation. Les gens ont vraiment eu du mal à copier une chose qui n’existait pas réellement.”

—Joakim Sundén, coach agile chez Spotify 2011–2017

“Cela m’inquiète quand les gens regardent ce que nous faisons et pensent que c’est un cadre de travail qu’ils peuvent juste copier et implémenter. […] Maintenant, nous nous efforçons vraiment de souligner que nous avons des problèmes aussi. Tout n’est pas ‘tout beau et tout fonctionne bien et toutes nos squads sont incroyables’.”

—Anders Ivarsson, co-auteur du livre blanc the Spotify

https://www.jeremiahlee.com/posts/failed-squad-goals/

Alors, sans tomber dans l’écueil de croire en l’existence d’un modèle Spotify miraculeux et immuable, peut-on s’en inspirer ?

Bien sûr. En gardant à l’esprit le principe agile d’adaptation, toute expérimentation est possible. Si l’expérimentation n’est pas concluante, on en tirera les leçons pour trouver des manières de travailler plus adaptées à chaque contexte.

Voici les différents regroupements de collaborateurs introduits par Spotify.

• Les “squads”

Les squads sont de petites équipes interfonctionnelles de 6 à 12 personnes qui sont responsables d’un produit ou d’une fonctionnalité spécifique. Chaque équipe est habilitée à prendre des décisions sur la façon dont elle travaille et sur ce qu’elle livre.

• Les “chapters”

Les chapters sont des groupes de personnes travaillant au sein de la même discipline ou spécialité, comme des développeurs ou des recetteurs. Les chapters permettent de partager les connaissances et de collaborer avec d’autres personnes ayant des compétences similaires. Les membres d’un chapitre ont un supérieur hiérarchique appelé “Chapter Lead”, qui est responsable du développement de l’équipe et des événements qui se déroulent au sein du chapter.

• Les “tribes”

Les tribes sont des ensembles de squads qui travaillent sur des produits ou des fonctionnalités connexes. Les tribes sont généralement composées de 100 à 150 personnes et sont dirigées par un “Tribe Lead” qui est chargé de coordonner le travail des squads au sein de la tribe.

• Les guildes

Les guildes sont des communautés informelles qui traversent les tribes et les chapters. Les guildes permettent aux personnes de partager leurs connaissances et leurs meilleures pratiques de façon transverse, au sein de l’organisation.

De l’intérêt du Chapter Lead

Nous venons de le voir, le Chapter Lead est le coordinateur d’un chapter, soit une communauté d’experts de la même spécialité. Le principe de communautés d’experts n’est pas propre à Spotify. Mais ce qui est notable dans la description du Chapter Lead, c’est la notion de supérieur hiérarchique. Les modèles agiles donnent généralement peu d’indication sur l’organisation managériale. On sait que les rôles de Product Owner et de Scrum Master ne possèdent aucun pouvoir hiérarchique sur l’équipe. Et on sait par ailleurs qu’il existe des managers dans les entreprises. Le résultat peut donc aboutir à des aberrations du type :

Le Product Owner est en outre le supérieur hiérarchique des business analysts et le Scrum Master celui des développeurs. Parfois ils s’expriment dans le cadre de leur rôle, parfois dans le cadre de leur fonction. Mais ne vous inquiétez pas, tout le monde fait bien la part des choses…

On sombre dans une hybridation intenable. Par exemple, si je suis membre de l’équipe, et que mon Product Owner/manager me communique une vision du produit incohérente, dans quelle mesure puis-je m’y opposer ? Est-ce qu’il me parle en tant que Product Owner ou en tant que manager ? Est-ce que je risque ma carrière ?

Et si je suis Product Owner/manager, comment savoir si l’équipe challenge réellement les éléments que je lui apporte ? Est-ce que tout le monde est sciemment en train de me laisser faire route par peur de répercussions ?

Autrement dit, si on vient simplement plaquer des rôles sur une organisation hiérarchique pré-existante, on court le risque de passer totalement à côté des principes d’autonomie, d’auto-organisation et de prise de décision décentralisée.

Dans une transformation agile, les liens hiérarchiques doivent être repensés. L’intérêt du Chapter Lead est qu’il est un manager déporté. Il n’intervient pas dans la vie quotidienne de l’équipe. Elle peut donc prendre de façon autonome les décisions qu’elle juge les meilleures pour le client et le produit, sans pression ni interférence. Pour comprendre l’avantage d’un tel fonctionnement, il faut naturellement être convaincu que les meilleures décisions opérationnelles sont prises par ceux qui savent, et que ceux qui savent le mieux sont ceux qui font.

Déchargé du micro-management quotidien, le manager déporté peut se focaliser sur les tâches à valeur ajoutée : apporter son soutien, son assistance, accompagner le salarié dans son évolution professionnelle, le faire grandir. Autrement dit, on s’affranchit du manager de proximité qui dit “quoi faire” pour adopter celui qui aide sur le “comment faire”.

L’esprit du rôle de Chapter Lead est de soutenir le travail des experts de sa communauté, tant au niveau collectif qu’individuel. Au niveau individuel, il favorise l’acquisition des compétences. Au niveau collectif, il contribue à éliminer les obstacles en lien avec les autres chapter leads et les scrum masters. Il s’assure que tous les moyens sont mis à disposition pour favoriser l’efficacité et la productivité, au service de l’objectif commun de la tribu à laquelle il appartient lui aussi.

Pas besoin d’être Einstein

Cette proposition de donner la responsabilité hiérarchique au coordinateur d’une communauté d’experts est une des idées qu’il est possible d’expérimenter, en s’inspirant du livre blanc Spotify. Certains l’ont déjà fait avec succès. En tout cas, une chose est sûre : les hybridations du type Product Owner/manager ou Scrum Master/manager sont une approche catastrophique. Ce non-sens est même une des raisons principales de l’échec agile de nombreuses entreprises.

Albert Einstein n’a jamais dit : « La folie, c’est de faire toujours la même chose et de s’attendre à un résultat différent ». Cette phrase est en réalité l’œuvre de Rita Mae Brown, écrivaine américaine de romans policiers, ce qui ne change en rien sa profondeur et sa pertinence.

Alors armons-nous des valeurs agiles de courage et d’ouverture : osons, tentons, testons.