Construire et piloter une plateforme agile de production logiciel avec le Lean
« Le Lean, ce n’est que pour l’industrie manufacturière ». Voilà une phrase que l’on entend fréquemment, induite par l’origine de cette approche : l’industrie automobile. C’est en effet de Toyota que tout est parti : un système de production (le Toyota Production System) né dans les années 50, puis un système de management (le Toyota Way), qui seront nommés "Lean" en 1988 par John Krafcik, (chercheur au MIT), un mot qui n’a pas de traduction exacte en français, ce qui nous obligera à conserver le terme anglais.
Cette compréhension est on ne peut plus réductrice : avec nos accompagnements, nous montrons jour après jour que cette approche permet également aux acteurs du numérique d’améliorer leur efficacité, la qualité de leur production, et la satisfaction de leurs clients de manière significative.
Je propose aujourd’hui de partager avec vous une expérience chez un acteur important du domaine de la cosmétique. Dans sa division “Research & Innovation”, environ 300 personnes travaillent dans la production de logiciels dans le but d'aider la recherche scientifique en laboratoire. L’ambition est de structurer ces 300 personnes en environ 30 équipes réparties sur 3 plateformes de production. Lors de notre arrivée, les plateformes sont encore en réflexion et notre mission est justement d’aider l’organisation à 1/ constituer ces plateformes, et 2/ piloter leur production.
Piloter la constitution des équipes de la plateforme avec le management visuel
Comprendre ce que l'on doit réussir
En Lean, on sait que notre processus fonctionne lorsque celui-ci produit de bonnes pièces. A l’aune de ce principe, on saura que l’on sait constituer une plateforme à partir du moment où des équipes seront enrôlées sur celle-ci, et qu’elles délivreront de la valeur à leurs utilisateurs. Nous commençons donc par une et une seule plateforme avant de lancer les deux suivantes.
Comme expliqué dans l’article “Comprendre, voir et Agir avec le Lean”, la première action consiste à comprendre ce que l’on souhaite réussir, ainsi que la situation dans laquelle on se trouve, afin de créer une compréhension partagée avec toute l’organisation. Cela commence invariablement par l'identification des unités d'œuvre, qui dans le cas de la création de notre plateforme, sont les équipes elles-mêmes.
Nous commençons donc par chercher les réponses à des questions qui peuvent sembler triviales, mais qui s’avèrent pourtant essentielles :
Combien d'équipes attendues dans la plateforme ?
Quels sont les rôles attendus dans une équipe ?
Comment sait-on qu’une équipe est prête pour le delivery ou non (DoD) ?
Ces questions ont trouvé leur réponse lors de plusieurs entretiens passés avec les parties prenantes.
Clarifier la situation
Pour clarifier les enjeux de la création de cette plateforme, nous mettons en place un management visuel. Ce qui facilitera la prise de décision par la direction de la plateforme pour combler les écarts rendus visibles.
En orange à gauche, la liste des équipes :
13 équipes au total à constituer
7 sont prioritaires.
En violet sur la première ligne, la liste des rôles identifiés pour chacune des équipes sur 3 niveaux différents :
L’équipe cœur, indispensable au fonctionnement de l’équipe (développeurs, Product Owner, Scrum Master, Dev Lead, QA, etc.)
L’équipe étendue, composée de personnes sur lesquelles l’équipe cœur peut s’appuyer, mais qui ne sont pas nécessairement à plein temps sur ses sujets
L’équipe plateforme qui est en support au niveau plateforme (Direction de plateforme, management, etc.)
A la croisée des rôles et des équipes :
En vert : les personnes dont le recrutement au sein de l’équipe est d'ores et déjà acté
En rouge : les rôles à pourvoir
De l’aveux même de la responsable de la transformation « grâce à cela, on a vu à quel point on était loin de là où on voulait aller, et on a réellement cranté la matérialisation de la plateforme ».
Passer à l'action
La situation rendue explicite par le management visuel est une révélation pour la direction de la plateforme qui comprend rapidement l'écart entre la situation actuelle et la situation souhaitée. Cela lui permet de prioriser les équipes les plus importantes et de prendre des dispositions pour les lancer.
Dernière réflexion venant du Lean : identifier les unités d’œuvres « simples » pour pouvoir les traiter en premier et apporter rapidement de la valeur. La direction s'empare du sujet. Elle identifie et traite les équipes prioritaires « simples » en premier (ayant seulement besoin d’un ou deux membres supplémentaires). Elle effectue les recrutements, et lance les premières équipes 1 mois et demi après le début de la mission. Durant les 3 mois suivants (qui comptent juillet et août), 5 autres équipes sont engagées sur la plateforme. Elle est alors prête pour commencer le delivery.
Piloter le delivery
Les premières équipes enrôlées, il nous faut maintenant mettre en place le pilotage du delivery. L’organisation a les yeux rivés sur la valeur business que les équipes doivent produire. C'est-à-dire la valeur réellement livrée et constatée par les utilisateurs. Mesurer cette valeur est indispensable mais est loin d'être facile. Ceux qui s’y sont frottés savent à quel point la tâche est périlleuse : comment mesurer la performance business d’une équipe ? À quel moment ?
Comprendre quoi piloter
Comme expliqué dans l'article "Fractales et regard Lean pour simplifier le pilotage d'un train SAFe (Partie 2)", dans le Lean, nous distinguons la valeur opérationnelle et la valeur business pour piloter le delivery.
La valeur opérationnelle correspond aux unités d'œuvre logicielles que l'équipe construit et qui représente une hypothèse de valeur business pour les utilisateurs (User Stories, Epics, etc.). La production de cette valeur peut être pilotée de manière volontariste, et les actions d’amélioration qui en découlent sont principalement à la main des équipes. C'est ce qu’on appelle un “Leading Indicator” qui permet de piloter la production chaque jour (ou chaque semaine). En revanche, la valeur business est davantage liée à la conception en amont (par le PO, le PM ou le HoP) et ne peut être mesurée qu’en aval du processus de production, un certain temps après la mise à disposition des fonctionnalités aux utilisateurs. C'est un “Lagging Indicator” qui rend délicat le pilotage volontariste du delivery d'une équipe sur des temps courts. De plus, les actions d’amélioration qui en découlent relèvent souvent de réflexion business : positionnement, segment de public visé, etc.
C’est donc la valeur opérationnelle que les équipes vont piloter chaque jour, afin de leur permettre d’améliorer leur processus, leur delivery et par conséquent le coût et la rapidité d’expérimentation d’une hypothèse de valeur. Cela permettra aux PO de tester plus souvent, et d’ajuster plus rapidement la manière dont ils pensent leurs hypothèses. Ce qui aura pour conséquence d’améliorer, sur le moyen terme, la valeur business.
Définir les conditions de réussite
Pour commencer la mise en place de ce pilotage, nous devons comprendre ce que les équipes engagées sur la plateforme ont à réussir. A ce moment-là, elles sont six. Les unités d’œuvre de haut niveau qui arrivent sur la plateforme sont des Initiatives. Nous réalisons donc un gemba sur les quatre initiatives déjà lancées pour comprendre ce qu’elles représentent. Rapidement, nous constatons de nombreuses dépendances. En effet, sur les quatres Initiatives, trois sont réparties sur deux équipes, et une autre sur trois équipes. En dehors de ces dépendances internes à la plateforme, chaque équipe doit se synchroniser avec au moins 3 équipes externes. Les équipes sont donc régulièrement bloquées par celles dont elles dépendent. Ce qui engendre une forte insatisfaction au niveau des collaborateurs. Ils ne se sentent pas autonomes et ont la sensation de ne rien pouvoir terminer (et contrôler).
Comprendre, c’est savoir où l'on veut aller, mais également l’organisation mise en place pour y arriver. Il devient essentiel de faire communiquer toutes ces équipes afin qu’elles puissent se mettre en situation de réussir la livraison des éléments souhaités. Ce constat partagé entre tous, la direction et les équipes décident d’organiser une rencontre d'une journée afin de définir les conditions de réussite de la plateforme sur les trois prochains mois. Cette journée a deux buts :
Définir le challenge en terme de réussites opérationnelles (en nombre d’unité d’œuvre à produire)
Permettre aux équipes de la plateforme d’échanger avec les acteurs avec qui elles devront travailler pour réussir leur objectif d’équipe. Et par là même, celui de la plateforme.
À l’issue de cette journée, la situation est moins confuse. L’objectif est clair (et chiffré) :
23 Epics à sortir sur les 6 prochains sprints par les 6 équipes engagées
211 Features (qui constituent les 23 Epics)
17 dépendances internes à la plateforme
43 dépendances externes
Mise en place du pilotage
Chaque équipe a clarifié ses conditions de réussite en lien avec la stratégie de la plateforme. Elles ont partagé leurs Features, ainsi que leurs dépendances. Elles détailleront par la suite leurs Features en User Stories peu avant leur développement. Et ces User Stories deviendront alors les unités d'œuvre pilotées au niveau des sprints de chaque équipe.
Équipes et sponsors ont compris le challenge et sont alignés sur l’organisation mise en place. Ils vont donc maintenant pouvoir voir ensemble la situation et les écarts. Pour enfin agir et apprendre sur le fonctionnement de la plateforme.
Voir les écarts
Les conditions de réussite des équipes et de la plateforme sont maintenant claires. Il est temps de piloter le delivery, de mesurer, et de voir les écarts. Cela permettra d'identifier ce qui freine les équipes pour leur permettre de s’améliorer en phase avec l’objectif de réussite de la plateforme.
Les équipes pilotent leurs User Stories quotidiennement grâce au daily. Nous proposons aux acteurs de la plateforme de piloter leurs features (et leurs dépendances) grâce à un point hebdomadaire (“weekly”). Chaque fin de semaine, Product Owners, Scrum Masters, Managers et Directeur de plateforme se retrouvent autour de ces quelques questions :
Que devions-nous réussir cette semaine (combien de features, lesquelles) ? (visibles dans le management visuel)
Qu’avons-nous réussi (combien de features, lesquelles) ? S’il y a un écart, qu’est-ce qui nous en a empêché ?
Que devons-nous sortir la semaine prochaine (combien de features, lesquelles) ?
Quelles sont les dépendances ? Comment nous organiser pour réussir ?
Qu’est-ce qui peut nous en empêcher ? Comment nous organiser pour gérer ces risques ?
Toutes les personnes sont présentes autour d’une situation partagée, afin de 1/ apprendre des écarts entre ce que nous avions prévu et ce que nous avons constaté en comprenant les causes, et 2/ s’organiser et demander de l’aide le cas échéant pour la semaine qui suit.
Voilà qui représente un exemple réussi de passage à l’échelle de l’agilité autour du pilotage de la valeur opérationnelle.
Résultats
Les premiers résultats ne se font pas attendre. On constate rapidement les premiers écarts engendrés par de réels problèmes de synchronisation avec des équipes hors de la plateforme. Cela a conduit à l’inclusion de ces équipes dans le point de pilotage hebdomadaire (le weekly). On a également mis en lumière un problème de conception empêchant les équipes de faire bon du premier coup. Cela a entraîné une réflexion poussée sur ce qu’est une bonne conception en amont de la production afin de mettre les équipes en situation de réussite (DOR d’initiative, DOR d’Epic). On a également repéré des éléments très structurels. Comme par exemple, une équipe de développeurs aux États-Unis qui utilisait une plateforme hébergée en France. En cas de panne de cette plateforme à partir de 14h (heure USA), l’équipe USA devait attendre le lendemain que l’équipe en France arrive et dépanne l’environnement (à cause du décalage horaire).
Ces problèmes rendus visibles et partagés ont permis à la plateforme d’apprendre par elle-même et de développer une connaissance de son environnement de travail lui permettant d’améliorer de 41% son delivery entre le premier sprint et le dernier.
La maîtrise grandissante du processus de production par les équipes a également eu un autre impact, celui d’améliorer leur prédictibilité, c’est à dire le ratio entre ce qu’elles prévoient de faire et ce qu’elles arrivent effectivement à livrer :
Conclusion
Que ce soit pour la production de pièces automobiles sur une chaîne de production ou la mise en place d’une plateforme de production de 15 équipes, la pensée Lean permet de clarifier la situation pour engager l’ensemble des acteurs à améliorer son flux de valeur. La mise en place du pilotage de la valeur opérationnelle permet à l’ensemble des parties prenantes d’identifier chaque jour les obstacles qui empêchent les équipes de réussir, et de les transformer en opportunités d’amélioration. Que l’unité d’œuvre soit une feature à livrer à un client, ou une équipe à enrôler sur une plateforme, la réponse Lean est la même : comprendre, voir, agir.
« Une mise en place en douceur avec un pilotage clair et pragmatique. »
Feedback du Directeur de la plateforme
« Une approche très opérationnelle qui clarifie la situation et engage les acteurs de la plateforme »
Feedback de la Directrice de la transformation Agile