Ce que nous apprend la House of Lean sur SAFe

Dans un précédent billet (L’agilité ou la malédiction de la simplicité), j’évoquais les questions que m’inspiraient “de l’extérieur” (i.e sans y avoir été confronté directement) le framework SAFe (Scaled Agile Framework).

Ce billet propose une perspective davantage informée car j’ai eu l’opportunité de suivre une formation dans le cadre de la préparation à la certification SPC (SAFe Program Consultant, que je n’ai finalement pas passée), ainsi que celle de superviser le coaching d’une équipe qui mettait en oeuvre cette approche de passage à l’échelle de l’agilité.

SAFe ou la Silver Bullet du numérique

Un peu comme les éditeurs de SAP au tournant des 00’s avec l’informatisation des processus, Dean Leffingwell a su rapidement identifier une opportunité en or alors qu’il définissait dès 2008 les premières versions du Scaled Agile Framework : les grandes entreprises vont attendre qu’on leur apporte sur un plateau une solution toute packagée et prête à l’emploi pour intégrer toutes les “bonnes pratiques” (sic) du numérique et (re-sic) devenir une entreprise agile.

Cela présente l’avantage pour les décideurs de s’abstraire de la complexité des systèmes techno-sociaux que sont les organisations en charge de la conception, du développement et de l’opération de solutions numériques alors qu’ils identifient une (re-re-sic) “stratégie” numérique, prête-à-déployer.

En cela SAFe représente un rêve en termes d’offre de conseil. L’intégration de tous les buzzwords du numérique (Lean, Agile, Design Thinking, DevOps, Lean Startup, Extreme Programming, Scrum, etc …) dans une boite à outils nécessitant des rôles spécifiques, formés et certifiés par la maison. Des certifications versionnées, à l’obsolescence programmée (“ah non votre certification 4.6 ne vaut plus en SAFe 5.0”), formations ré-entrantes dans lesquelles on parle bien plus des autres formations (1/2 journée sur les quatre jours de ma formation) que du client. 

SAFe est une redoutable machine de guerre du conseil en entreprise : cela nous rappelle que dans la ruée vers l’or ce sont bien plus les vendeurs d’outils que les chercheurs qui se sont enrichis. L’analogie avec la ruée vers l’eldorado agile est saisissante.

PI Planning, Portfolio Management et la pensée Lean pour passer l’agile à l’échelle

Il demeure toutefois des choses intéressantes dans SAFe. La première est le PI Planning, ce grand raout de trois jours durant lesquels toutes les équipes réfléchissent à leur prochain incrément produit de trois mois. L’équivalent d’un super Sprint Planning qui crée les conditions pour identifier et traiter toutes les éventuelles dépendances entre chacune des équipes. Cela me semble audacieux et mobilisateur même si une vision Lean proposerait de traiter cela en flux, itération après itération plutôt qu’en batch sur un incrément de plusieurs mois.

Le second point dans lequel SAFe semble répondre à un vrai besoin et apporter une valeur intéressante est celui de la gestion de portefeuille avec le Lean Portfolio Management. Bien souvent je constate que les équipes métiers voient la DSI comme un fournisseur et, une fois que le projet a été livré et mis en oeuvre, cette dernière est bien peu informée de la valeur métier apportée par le projet trimestre après trimestre. Cette situation bien peu vertueuse permet aux métiers de ne pas être questionné sur les résultats effectifs apportés par la solution qu’ils jugeaient indispensable. En proposant un cadre simple et clair pour piloter train après train, année après année, la valeur métier apportée par le projets, le Lean Portfolio Management crée les conditions d’un vrai partenariat entre la DSI et les métiers.

Le dernier point qui me semblait prometteur était cette vision du Lean Mindset pour donner une direction et une charpente à l’ensemble du programme de transformation : las ! Quelle ne fut pas ma déception.

Don’t mess with the TPS

Assez vite durant la formation, on nous parle de learning journey et de relentless improvement – c’est à ce moment là que j’ai commencé à avoir un doute et que j’ai sorti mon Bullshit Detector. Bien vite, malheureusement, on comprend que par “learning“, le formateur entend “nouvelle version de SAFe”, mise à jour pour “tirer les enseignements” des limitations des précédentes versions. J’ai déjà évoqué cette conversation Twitter hilarante de John Cutler (“I found it ! I found it ! I found the CUSTOMER !” ) évoquant ces soi disant apprentissages de la maison SAFe.

Le vrai problème est apparu quand a été présenté la “House of Lean” de SAFe. Cette maison s’inspire ouvertement, dans un premier temps, de la représentation du système de production (le Toyota Production System) sous forme de maison. Dans la version originale de Toyota, la valeur client représente le toit ; le flux tiré et la qualité à chaque étape en sont les piliers ; le lissage de charge, la standardisation et le Kaizen forment la première couche du socle ; la stabilité (suppression de variabilité) la seconde couche du socle. La House of Lean s’inspire dans un second temps du Toyota Way qui, lui, représente les 5 piliers du système de management de Toyota : le Gemba, le Kaizen, le Challenge, le Respect et le Teamwork. [Voir ce superbe article des amis de Operae qui présente les deux].

Ces deux modèles proposés par Toyota représentent une valeur inestimable à plusieurs titres et sont intouchables à nos yeux de coach qui essayons de pratiquer le Lean originel. Si nous essayons de pratiquer ce Lean originel et n’avons que peu de considération pour ses déclinaisons multiples ce n’est pas par dévotion ou intégrisme : c’est en raison de son admirable rigueur intellectuelle, son respect de la valeur travail et du génie de chacun, sa profondeur insondable et parce qu’elle se rapproche le plus d’une vision vertueuse du travail. Et ces deux modèles incarnent ces vertus : ils sont le fruit de décennies de travail dont on connait le résultat éblouissant, non seulement pour Toyota mais pour touts les autres entreprises ou industries qui ont mis ces principes à l’oeuvre avec succès, tout autour du globe.

La seconde raison est que ces deux systèmes représentent ensemble un système d’apprentissage comme l’a très bien expliqué l’ouvrage The Lean Strategy de Ballé, Jones, Chaize et Fiume. Le TPS crée les conditions pour que les opérateurs apprennent en faisant et pour qu’ils découvrent des choses nouvelles sur leurs processus. De la même façon, en les incitant à se confronter à l’inconfortable réalité opérationnelle avec le Gemba et en les encourageant à employer la forme interrogative et à encourager l’initiative personnelle avec le Chalenge et Kaizen, le Toyota Way est tout autant un système d’apprentissage pour le management.

Ces deux maisons sont donc au sommet de la pyramide de TS Elliott : elles représentent la sagesse d’années d’apprentissage et une sorte de pierre philosophale pour nous, les nerds du Lean.

Refactorer Let It Be des Beatles

La House of Lean de SAFe mélange, dans ce qui ressemble beaucoup à un grand fourre-tout démagogique, l’opérationnel et le managérial. Et il se permet de ré-écrire la maison Lean de Toyota. Un peu comme si un consultant en song-writing ré-écrivait “Let It Be” des Beatles pour l’enseigner à ses élèves, en changeant des accords ou la mélodie du Coda, sous prétexte qu’il a fait un atelier avec d’autres amis consultants et que le verdict de post-its en chambre est que “cela sonnerait mieux et plus moderne aujourd’hui”, indépendamment du succès universel de l’original.

Cette initiative est une parfaite illustration de cette propension de l’industrie du conseil, éprise de “néomanie” comme la qualifie Nassim Taleb, à balayer ce qui existe déjà, une sorte de “avant moi le désert”. Cela pourrait être envisageable si la nouvelle approche était validée et sa robustesse et son efficacité (opérationnelle, hein, pas commerciale) démontrée. Regardons de plus près cette SAFe House Of Lean …

La House of Lean de SAFe

Le premier point (qui représente le toit et le but) est la Valeur. On retrouve peu ou prou ce que l’on retrouve sur le toit TOyota en termes d’objectifs. On retrouve ici en plus, une promesse de lendemains qui chantent (High Morale).

Les points suivants sont les quatre piliers. Le premier est Respect for People and Culture. On retrouve ici un pilier du Toyota Way (Respect for People) et un terme rarement utilisé dans le Lean : Culture. Le Respect for People du Lean est magnifiquement illustré par cette citation de Fuijo Cho : Go See, Ask Why, Show Respect. Il s’agit de pratique de managers et dirigeants qui incitent à aller sur le terrain pour voir les faits tels qu’ils sont ; demander pourquoi aux équipes pour les challenger et solliciter leur expertise sur le sujet ; et montrer du respect en s’intéressant vraiment à leurs problèmes (et les actions d’amélioration menées), ce en n’utilisant que la forme interrogative, sans ne jamais apporter de solution packagée [par exemple : SAFe 5.0 – bon OK c’est facile]. Pour ce qui est de la culture, on n’en parle que très rarement dans le Lean car elle n’est que très peu actionnable : on préfère parler de pratiques et de résolution de problèmes en équipe, car ceux ci-sont à la source de la culture d’entreprise telle que définie par Edgar Schein.

Le second pilier est le Flow. On sent l’influence de Dan Reinertsen (sur lequel on revient un peu plus loin) dans lequel, là encore on mélange tout : delivery, qualité, variabilité, et la notion de produit. Notons l’absence de notion de flux tiré par la demande client, la clef de voûte de l’amélioration continue.

Le troisième pilier est l’Innovation avec, naturellement, Innovative People en premier point. C’est tellement tarte à la crème comme proposition que je ne vais même pas m’attarder dessus.

Le quatrième point est (ne riez pas) Relentless Improvement. Parce qu’en fait, Continous Improvement c’est pour les amateurs (yeux au ciel). Plusieurs éléments ici dont Problem Solving Culture. Dans la formation, aucun des deux formateurs n’a été en mesure de donner une définition de “problème” ni de “résolution de problème” (ne vous en faites pas, thehypertextual a fait le boulot). Ils nous ont proposé plusieurs outils (SAFe problem solving, PDCA sans nous expliquer le quel est à utiliser en quelle situation) et en atelier en groupe on a fait un problem solving dans lequel les personnes supposaient les hypothèses de cause et se sont rapidement énervées quand je leur ai demandé comment ils allaient valider ces hypothèses. Les problèmes ont de beaux jours devant eux.

Quand au socle : le Lean Agile Mindset. Je vous le ré-écris car on retrouve ici l’essence même du vaporware 21ème siècle :

“Leaders apply Lean Thinking as the basis for decision making, model the Lean-Agile mindset in daily activities and teach it to others.”

Le Lean Thinking n’est pas été décrit précisément en quelque chose d’actionnable (hint : c’est le TPS) et accessoirement comment mets-je le Innovative People du Lean-Agile mindset en action chaque jour ?

Voilà le truc. Et cela représente 30% des projets de passage à l’échelle de l’agilité. Pas étonnant de voir la consternation qu’inspire SAFe à Dave Thomas ou Martin Fowler.

A broken mindset

Des oeufs et tout un plat

Et je vous rassure, dans la “pratique” c’est du même ordre de rigueur intellectuelle. Ainsi nous explique-t-on en introduction que “35% des projets qui font du SAFe améliorent la qualité.” Voilà un exemple qui fera beaucoup rire un manager Lean qui vous répondra quelque chose comme “Et dans 45% des équipes qui améliorent la qualité, il y a une personne qui a subit une rupture des ligaments croisés du genou.” S’il n’y a pas de ligne directe de causalité entre une proposition et un résultat, c’est très intéressant et cela veut probablement dire que quelqu’un essaye de vous vendre quelque chose. Mais ce n’est certainement pas du Lean Thinking.

De la même façon Dan Reinertsen, qui fait partie de ceux qui souhaitent que l’on regarde le Lean au delà de Toyota, nous explique dans cette vidéo invraisemblable que le one-piece-flow est une erreur du passé et apporte cette preuve avec laquelle il va être difficile d’argumenter tant on pouffe de rire : vous imaginez acheter les oeufs un par un lorsque vous préparez le petit-déjeuner ? Cette vidéo est présentée durant la formation SAFe.

Ce que ne comprend pas Reinertsen à travers cet exemple c’est que lorsque l’on parle de one-piece-flow, on parle d’une unité de valeur pour le client. Et en l’occurence, le one piece flow apporté à la chaine de production correspond à l’ensemble des pièces dont a besoin un opérateur pour traiter l’unité de valeur (la voiture) sur son poste, maintenant. Donc dans l’exemple de Reinertsen, le One Piece n’est pas un oeuf, mais l’ensemble d’oeufs nécessaires pour faire un petit-déjeuner familial (l’unité de valeur pour le client : la famille). Et acheter chaque jour les 8 oeufs nécessaires pour un petit-déjeuner peut présenter de nombreux avantages si on souhaite en améliorer le processus (ce qui n’est peut-être pas le sujet principal de la famille en question). Des oeufs frais chaque jour ; moins besoin d’espace de rangement et, surtout : dès qu’il manque un oeuf, ou si un oeuf n’est pas de bonne qualité, on le voit tout de suite. On peut alors tirer l’Andon et réfléchir tous ensemble à ce qu’il s’est passé, aux causes du problème et, comme dirait Steven J. Spear, à ce que le processus est en train de nous murmurer à l’oreille. La base de l’amélioration continue. Bien évidemment il faut inscrire cela dans une transaction commerciale (car cela fait alors du sens d’optimiser la chaine logistique) mais vous voyez où je veux en venir.

Bref : avec une telle compréhension du Lean, pas étonnant que Reinertsen souhaite aller au delà. Je me rappelle une conférence du bonhomme et je ne me souviens pas avoir vu autant de formules mathématiques et aussi peu de références au client dans un diaporama affilié au Lean. Cela ne veut pas dire que son travail n’est pas pertinent. Cela veut juste dire que ce n’est pas du Lean.

Lead Time et Productivité

On retrouve d’autres incompréhensions plus opérationnelles. Exemple : utiliser le Lead Time comme indicateur de productivité. C’est ainsi qu’on se retrouve avec des équipes qui livrent vite des fonctionnalités qui comportent des bugs.

Dans le Lean nous avons une définition très précise de la productivité : le nombre de pièces qui représentent de la valeur pour le client, livrées sans défaut durant une unité de temps, par personne. Exemple dans le contexte de l’agilité : le nombre de User Stories livrées au client durant notre sprint de deux ou trois semaines sur le nombre de jours homme travaillés.

Bien évidemment, si on travaille sur la réduction du Lead Time, cela va avoir (sous réserve que le niveau de qualité reste aux attendus du client) un impact indirect sur la productivité. Mais lorsqu’on améliore le Lead Time on travaille sur les délais et par sur la productivité. Il est important de conserver à l’esprit cette différence sans quoi on finit par placer la qualité sur le pilier du flux. Oh wait … Mal nommer les choses c’est ajouter au malheurs du monde disait Camus.

Ce que nous apprend la House of Lean sur SAFe

Rien que nous ne supposions déjà. SAFe est un produit de conseil et de formation, admirable d’opportunisme et d’agilité marketing. Le bon produit au bon moment, comme SAP dans les 2000 ou le offshore en Inde dans les 2010. Il apporte quelques pratiques audacieuses pour mobiliser les équipes d’un programme (PI Planning) ou un très bon outil de pilotage du portefeuille projet. On peut imaginer qu’il puisse enfin aider des grandes organisations à sortir quelque chose même si le taux de Corporate BS de sa communication est particulièrement élevé.

Mais sa vision qui n’est qu’englobante quand elle se veut systémique ne résiste pas à une analyse rigoureuse de sa structure intellectuelle : la House of Lean en est une parfaite illustration. C’est ainsi que ce même bon produit va causer un nombre incalculable de nouveaux problèmes aux organisations, avec des employés qui ne trouvent toujours pas de sens à leur travail et des clients qui ne sont toujours pas satisfaits des produits ou services qui leur sont livrés.

Cet article a été pulbié dans Culture Kaizen – La transformation des petits matin, livre blanc d’OCTO Technology.