Amélioration continue et émulation à l’échelle

Billet par Raphaël Geneteix.

La vision que j’ai de mon job est de travailler avant tout sur ma propre obsolescence. Pour y parvenir, je fais, du moins j’essaye, de contribuer à la création d’environnements de travail où chaque individu prend ses responsabilités de lui-même. Les équipes aspirent à devenir co-responsables, avec un profond sentiment d’appartenance vis-à-vis de leurs sujets, produits et même la stratégie de leur entreprise.

Dans ce billet, je vais baser ma réflexion sur mon expérience passée de “VP Product”, dans le contexte d’une boîte orientée IT/Tech. Je prends ce parti pour mieux illustrer mon retour d’expérience, mais en prenant un peu de hauteur, on imagine que le modèle est agnostique au contexte et au secteur.

Je crois profondément que le rôle “Product” (VP Product, Product Manager, ce que vous voulez…) a un rôle central à jouer pour créer cet environnement créateur de sens pour les individus.

Quand vous jouez ce rôle, combiné à celui de Coach (dites bonjour à la schizophrénie nécessaire pour concilier les deux), travailler sur de multiples produits, avec de multiples équipes peut vite devenir la zizanie. Vous vous retrouvez à devoir (ou croire que vous devez, encore plus intéressant) :

  • Maintenir une roadmap cross-produit.
  • Prendre en compte les goulots d’étranglement.
  • Abreuver chacun de la vision : une vision claire, inspirante, mais pas directive non plus.
  • Maintenir les parties prenantes directes des produits impliquées.
  • Garder le cap avec une vue d’ensemble tout en apportant une attention particulière aux détails.
  • Être sûr que chaque équipe a tout ce dont elle a besoin pour avancer.
  • <Insérer ici d’autres trucs issus des descriptifs de job>

Et bien… Quel programme ! Notamment pour ce terrifiant “<Insérer ici d’autres trucs issus des descriptifs de job>”. Je l’inclus avec une petite touche de sadisme intérieure car tous les Product Managers, VP truc bidule Product etc… savent de quoi je parle. 🙂 

Il est assez connu que si vous ne sélectionnez pas vos batailles présentées dans le vaste catalogue que constitue votre job, vous parviendrez à ne rien réaliser correctement. Si vous êtes exceptionnel, vous ferez partie des 1% qui le font en se maintenant à peine au-dessus du niveau de la mer. Cette stratégie de vouloir tout faire est remplie de bonnes intentions. Mais quand même… Si vous rêvez de porter vos produits, vos équipes et votre organisation au niveau supérieur, vous risquez de faire face à un vrai problème…

… Parce que vous ne pouvez pas le faire seul. Chaque point mentionné plus haut dans votre liste de trucs à faire dans votre job est le méta-sujet inhérent à un job spécifique. Se sentir responsable de toutes ces choses est sain. Mais cela ne signifie aucunement que vous devez le faire vous-même. Entre stratégie, tactique et opérationnel, un choix doit être fait.

Donc la grande question est : comment tout réaliser, sans tout faire ? Evidemment, on pensera à la délégation. Mais… Quelle délégation ?  Comment la rendre vertueuse, puissante, systémique même ?

Un peu de théorie et de retour d’expériences

Pourquoi ne pas s’appuyer sur les équipes produit en leur donnant les clés de leur propre amélioration continue ? Vous n’imaginez pas à quel point des équipes (vraiment) auto-organisées et co-responsables peuvent vertueusement changer votre système.

Considérons la situation suivante, que je base sur une expérience que j’ai pu personnellement vivre :

  • 4 produits à gérer.
  • Chaque équipe est dédiée au développement d’un produit.
  • Il existe un dénominateur commun technique (par exemple : même technos back ou front). Ou à minima, un début de convergence.
  • Les équipes travaillent avec une méthodologie : LeSS (adoptée et implémentée de manière très organique).
  • Et je me retrouve au beau milieu de ce champ de bataille, avec pour rôle officiel de “manager” tout ça.

J’avais besoin de casser ce cercle vicieux dans lequel j’étais coincé : les équipes grandissent, me sollicitent, et plus elles grandissent, plus elles me sollicitent. Plus l’organisation grandit, moins j’ai de temps. Cela semble somme toute assez logique. Pour diverses raisons, une de nos contraintes est de pouvoir “scaler” l’organisation sans pour autant faire “scaler” le Product Management.

LeSS a été très bien amené par les équipes elles-mêmes, et nous imaginions notre système capable de doubler, même tripler de volume. Sauf le Product Management (la partie visible et évidente) et… L’amélioration continue (celle-ci, invisible). Tout était fait, sauf les rétrospectives inter-équipes. L’amélioration continue était uniquement locale, et juste un peu globale. Nous appliquons LeSS, faisons ces “overall retrospectives”. Donc, d’après la méthode, la question de l’amélioration continue à l’échelle est réglée.

Faire ces “overall retrospectives” est utile. Je ne remets pas ça en question.

Je questionne davantage ce qu’on met à l’intérieur.

Donc je questionne le questionnement auquel l’overall retrospective répond.

Alors je questionne ces frameworks Agile à l’échelle qui ont un peu trop réponse à tout et rassurent.

Mais je le développerai ultérieurement. Il ne s’agit pas de tirer à vue sur les frameworks, mais sur la nature du besoin en lui-même.

Ces overall retrospectives me semblent creuses. Je trouve que les équipes parlent entre elles, mais il manque un liant, un truc… Et ce truc, c’est l’Émulation.

Ce mot, Émulation, est crucial. Avoir des équipes engagées, au sein d’un environnement nutritif dans lequel chacun peut grandir pour soi et pour les autres est la clé des groupes co-responsables. Nous avions donc besoin de créer de l’émulation. Emulation dans l’équipe, animée par l’équipe, pour l’équipe.

La question est : dans quelle partie de cette matrice souhaitez-vous vous situer ?

Si vous souhaitez être dans la partie haute droite, sachez que c’est une montagne à gravir qui vous attend. Une culture collaborative et tournée vers l’innovation peut apparaître si l’environnement est propice. Et encore, ce n’est pas magique. L’environnement doit être maintenu, en facilitant, facilitant, facilitant, en mettant plein d’huile dans la machinerie, en itérant, itérant, itérant.

Allons maintenant à la réalité

Nous devions régler le besoin d’indicateurs.

Une culture durable et forte ne vient pas des outils. Mais tout comme le management visuel apporte des vertus car il est une réponse à un des piliers qui est la transparence, les équipes ont besoin d’éléments viables à inspecter (attention, inspection pas au sens flicage). En d’autres termes, elles ont besoin de KPI.

Ce nouveau joueur entre maintenant dans la danse. La culture collaborative a besoin de cette visibilité nouvelle pour alimenter les équipes : sur quoi elle doit s’adapter et se concentrer. Nous avons donc identifié des dénominateurs communs à suivre sur lesquels chaque équipe trouverait un sens.

Nous ne sommes pas allés chercher loin l’inspiration initiale : Spotify l’a fait via son Squad Health Check Model. Nous avons repris quelques dénominateurs communs présentés chez eux, modifié ou créé d’autres.

Pour plus de visibilité, je ne montre ici que des exemples de meilleur cas et pire cas possible. Mais afin de faciliter la notation par les équipes, nous avons utilisé l’échelle de Likert sur 9 rangs : note de 0 à 8, avec pour chaque incrément de note une phrase aidant à se positionner. On évite ainsi les écarts de sensibilité de notation (ex : certains ne mettront jamais 8 car c’est jamais parfait, d’autres n’hésiteront pas à mettre 8).

Chaque équipe apporte son évaluation sur tous les critères. Puis elles mettent en commun leurs notes, avec toutes les autres équipes. Enfin, c’est là que la magie opère.

Comment l’émulation est-elle apparue ? 

Prenons un exemple pour illustrer cette magie. Nous faisons des releases toutes les deux semaines, chaque équipe est pluridisciplinaire, de la conception à la production. Le graphe ci-après présente une dizaine de notations successives sur notre appréciation de notre capacité à mettre facilement en production nos incréments.

Je prends ici l’exemple avec trois équipes pour maintenir un peu de clarté

Ce qu’on peut constater ici, c’est l’appréciation différente de chaque équipe sur sa propre capacité à effectuer des releases, en dépit du dénominateur commun technique. Elles sont auto-organisées, mais vont dans la même direction, avec trois “comment” différents.

Au début des mesures (sprint 60), nous observons que les équipes B et C souffrent pour faire des releases. L’équipe A se porte plutôt bien.

Trois sprints plus tard, on observe que A (rouge) et B (vert) s’inversent.

  • L’équipe A fait face à de nouvelles difficultés.
  • L’équipe B gère ses problèmes, apprend beaucoup de ses précédents écueils.
  • Statu quo pour l’équipe C, qui stagne dans ses difficultés.

Lorsque les équipes ont, pour la première fois, mis en commun leurs KPI (c’était au sprint 63), le choc généré leur a permis de prendre conscience du manque d’émulation entre elles. Elles ont alors travaillé main dans la main pour réorienter leur organisation et surtout partager leurs retours d’expériences afin d’améliorer ce sujet critique.

A l’issue de la rétrospective du sprint 63, elles ont décidé d’elles-mêmes de stopper cette descente en enfer. Ce n’était plus possible. Les sprints suivants ont été une succession d’améliorations (avec les quelques variations que l’on peut observer sur les sept sprints suivants, il faut bien expérimenter). J’aime observer qu’après plusieurs itérations, l’évaluation des équipes sur ce sujet est quasiment uniforme. C’est une belle convergence issue d’une vraie auto-organisation, menée par les équipes, pour les équipes.

Ce qui s’est passé au jour le jour est finalement rempli de bon sens : plus de communication entre les individus, partage de connaissances, expérimentations sur des petits incréments – mais suffisamment sensés pour en tirer enseignement viable, transparence, inspection, adaptation…

En contribuant et protégeant cette culture orientée sur la collaboration et la co-responsabilisation, les équipes s’emparent de sujets qui normalement étaient officiellement dans votre champ d’action. Vous avez de nombreuses batailles à mener de front, celle-ci est un exemple illustrant que la délégation et la confiance sont bien plus vertueuses et pleines de sens pour accompagner les individus à mûrir, grandir et devenir intrinsèquement motivés. En plus, cette culture  contribue à la création du terrain favorable vers une évolution plus globale, holistique de l’ensemble de l’organisation.

Je peux rentrer dans le détail de chacun des sujets faisant l’objet de KPI entre équipes, mais cela transformerait cet article (qui est déjà long) en un petit livre. Il y a tant de belles histoires de réussites et d’apprentissage à raconter. Un dernier exemple, seulement les courbes, à propos de la “Santé de notre codebase”, autre exemple de convergence notamment avec un effondrement d’une des équipes, qui a su s’appuyer sur le soutien bienveillant des autres.

… Et je peux continuer sans cesse, je me pince le bras pour arrêter. 

Les KPIs, est-ce la clé ?

Les KPI restent un moyen. Atteindre ce niveau d’auto-organisation est un travail de fond qui apporte des bénéfices si et seulement si la culture qui va avec est présente. Créer un sentiment d’appartenance fort autour des produits, de l’organisation et de l’entreprise avec chacun, est un (complexe !) mélange de :

  • Culture d’entreprise, par les individus, pour les individus
  • Bienveillance, quand on échoue, quand on réussit
  • Amélioration continue, ne jamais se reposer sur nos lauriers
  • Feedbacks, à consommer sans modération, entre nous, à 360 degrés
  • Maintenir tout ça, notamment lorsque nous faisons face à des tempêtes qui menacent de tout renverser

Est-ce que ça a réglé le problème de la sur-sollicitation du VP Product ?

Pas à 100%. Mais on touche du doigt une transformation du système qui conduit vers l’obsolescence du rôle sur certains aspects pour lesquels finalement je n’ai pas tant de valeur que ça à apporter.

L’amélioration continue, l’auto-organisation, la stratégie et l’excellence technique sont tombées intégralement dans la zone de contrôle des équipes. D’une part car ce sont les individus qui composent les équipes qui “savent” et “font”. En dépit de toute la meilleure volonté du monde, un “manager” finira par ne plus savoir. Il faut laisser aller, laisser faire, rappeler “Pourquoi”. Un sens que l’on peut partager, diffuser, avec légèreté.

J’ai fait confiance aux équipes. J’ai laissé aller. J’ai laissé faire. Dans les moments difficiles, j’ai rappelé “Pourquoi”. J’ai été incroyablement impressionné par leurs résultats. Jamais, du haut de ma colline, je n’aurais pu espérer autant.

C’est depuis ces évènements que j’ai réellement pris conscience, avec gravité, que le mot “obsolescence” avait un sens profond.

Article Précedent

Les architectures microservice

Article Précedent

La migration Cloud

Articles associés

Shopping Basket