Fractales et regard Lean pour simplifier le pilotage d’un train SAFe (Partie 2)

Dans la première partie de l’article, nous avons présenté le contexte et le problème de déconnexion entre la priorité des équipes et la valeur client dans un programme SAFe en croissance rapide. Nous avons aussi présenté la métaphore des fractales pour nous aider à penser plus simplement l’ensemble du dispositif.

Nous vous proposons dans cette seconde partie de :

• mieux distinguer valeur business et valeur opérationnelle (afin de …) ;
• … comprendre comment le lean aide à construire un pilotage plus simple de l’organisation SAFe, sur la conception, le delivery et l’amélioration continue, en concentrant l’attention de l’ensemble de l’organisation sur ces deux notions de valeur.

3. Valeur Opérationnelle et Valeur Business

Avant d’avancer dans la description du modèle proposé, apportons un éclairage nécessaire sur la perspective Lean de la valeur dans le contexte de l’agilité ainsi que ses dimensions opérationnelles et business.

Love (User) Story

La User Story présente cette caractéristique qui la rend si précieuse : elle est organisée autour de la perspective et de la valeur client.

Comme l’explique Mike Cohn dans User Stories Applied, les fonctionnalités que nous avions dans nos spécifications de systèmes d’information du XXème siècle décrivaient le système depuis sa propre perspective, en tant que capabilité : le système sera capable de faire ceci (proposer des billets de train à une date donnée) et de faire cela (le paiement en ligne). Il s’agit d’une vision depuis le système vers l’utilisateur.

La User Story définit la fonctionnalité depuis la perspective de l’utilisateur en rendant tangible la valeur qu’il en retire :

“En tant que voyageur, je peux réserver mon billet de train en deux minutes sur mon mobile pour éviter de perdre deux heures en allant à la gare.”

Cette perspective permet de limiter un des plus gros gaspillages de l’industrie des services numériques (la surproduction - les fonctionnalités non utilisées par les utilisateurs) et de concentrer ses efforts sur l’expérience utilisateur.

En prolongeant cette réflexion, on peut extrapoler que, de la même manière que la User Story est l’unité d’oeuvre à la main d’une équipe pour créer de la valeur, la Feature est l’unité d’oeuvre qui permet de mesurer la valeur produite par un Train SAFe (composé de plusieurs équipes) et l’Epic par un programme SAFe (composé de plusieurs trains).

Valeur opérationnelle et Valeur Business

Une objection fréquemment présentée à cette notion de pilotage par la valeur opérationnelle est que toutes les US, Features et EPIC ne représentent pas la même valeur business, et que ce n’est pas si simple que de compter ces unités d'œuvre pour évaluer la valeur livrée.

Il s’agit d’une objection en partie valide. Le point d’achoppement est que cela ne relève pas de la responsabilité de l’équipe de Delivery de s’assurer qu’ils travaillent sur les bonnes US ou Features en termes de valeur business. Cela relève des rôles qui sont orientés produit.

C’est la responsabilité de cette équipe produit (PO, PM, HoP, GPO) de piloter les outcomes (éléments de valeur business) en considérant chaque Epic comme un mini business plan (lié aux OKRs), et en faisant des hypothèses de résultats attendus. Par exemple : amélioration de la satisfaction utilisateur, réduction du taux d’attrition, augmentation de la part de marché, augmentation du nombre de nouveaux inscrits au service, augmentation du CA etc….

Séparer les deux sujets pour mieux les traiter

Mélanger les deux sujets, à savoir améliorer la valeur opérationnelle et améliorer la valeur business, est le meilleur moyen de n’en traiter aucun correctement.

De la même manière qu’il n’est pas de la responsabilité du PO de s’assurer que les tests unitaires passent sur le système d’intégration et déploiement continus (CI/CD) ou que l’on a les bons jeux de tests sur cette chaîne, on ne peut pas responsabiliser l’équipe de Delivery sur les outcomes de ce qui est livré.

Cela ne veut pas dire qu’elle n’est pas concernée par le sujet : faire accompagner un UX Designer lors des visites utilisateurs par des développeurs, dans le but que ces derniers développent aussi une connaissance plus profonde du métier, est ainsi une excellente initiative. En outre, l’équipe a aussi son mot à dire pour aider à la prise de décision sur la priorisation des différents sujets en fonction d’éventuels points d’architecture ou de tactique de livraison.

Mais les unités de valeur sur lesquelles l’équipe a la main (et dont elle se doit d’améliorer le delivery en permanence) ce sont ces unités de valeur opérationnelle, pas le business plan, et il ne faut pas mélanger les deux sujets car cela ne peut que la ralentir.

Accélérer le Delivery pour découvrir plus vite son marché

Le juge de paix reste bien évidemment la valeur business produite (et le lien avec les OKRs) : il ne sert à rien de livrer davantage de valeur opérationnelle (Epic et Features) si on constate que la valeur business attendue n’est pas au rendez-vous. Mais il s’agit d’une réflexion d’une autre nature (voir la section ci-dessous consacrée aux réflexions sur l’amélioration de la valeur business des Epics) qui n’empêche évidemment pas d’avancer sur l’amélioration du Delivery.

Dans le State of DevOps report de 2014, Jez Humble et al. rappellent ainsi que “les entreprises avec des organisations IT performantes ont statistiquement deux fois plus de chance de dépasser leurs objectifs de profitabilité et de part de marché”.

Améliorer la performance opérationnelle de notre programme SAFe en termes de Delivery représente un atout incontestable pour améliorer la valeur business : plus on livre des Epics (qui sont des hypothèses business) en production plus on peut en tester la validité et en mesurer le résultat. Comme l’explique Marc-Antoine Lacroix, le CTO de la FinTech Qonto : Shipping Fast is our Product Strategy.

4. Fractales et regard Lean pour piloter la valeur dans un programme SAFe

Maintenant que nous avons compris le problème de ces équipes, la notion de fractale et que nous avons bien distingué la valeur opérationnelle et la valeur business, regardons ce que le Lean peut apporter dans ce contexte, autour des étapes clef du flux de valeur agile d’un service numérique : conception ; delivery ; amélioration.

4.1 Conception

Lean et arrêt au défaut

Dans la vision Agile, on suit le cycle de vie de réalisation des Features, c'est-à-dire les différents états successifs de cette unité d'œuvre. Exemple :

Cycle de réalisation

Un point qui est essentiel dans ce dispositif est de définir des frontières claires entre les étapes pour être capable de valider qu’une unité d'œuvre (Epic / Feature / US) peut passer à l’étape suivante. La motivation derrière ce principe est d’éviter de perdre du temps en travaillant sur des entrants qui ne sont pas suffisamment mûrs et qui vont causer de nombreux aller-retour entre les équipes. On retrouve ici un principe important de la gestion du flux lean : une “pièce” ne passe pas à l’étape suivante si nous ne sommes pas en mesure de déterminer si elle est OK ou KO. Masaaki Imai parle dans son ouvrage Kaizen de protéger le client (i.e, l’étape suivante dans le processus).

La raison est que l’évolution du coût d’une erreur en fonction de l’étape du processus où elle est identifiée ne suit pas une courbe de croissance linéaire mais exponentielle. Pour illustrer ce point de manière saisissante, Cécile Roche qui travaille pour Thalès explique qu’une erreur coûte beaucoup moins cher pour un satellite si on l’identifie en bureau d’études que si ce dernier est en orbite géostationnaire à 36000 kms au-dessus de nos têtes.

Definition of Ready

Ainsi une User Story n’entrera en phase de développement que si elle est Ready To Dev i.e si sa conception est terminée. Par exemple, on peut imaginer qu’une User Story pour laquelle ne sont pas définis des critères d’acceptation ne pourra pas être prise en charge par les développeurs. De la même manière, cette User Story ne pourra pas partir en production si elle n’est pas DONE - par exemple si l’exécution de l’ensemble des tests unitaires et des tests de performance de l’application n’ont pas été exécutés.

Si l’on transpose ce principe au niveau supérieur (Features), on pourra ainsi avoir le même dispositif : une Feature ne rentre pas dans un sprint tant qu’elle n’est pas Ready To Sprint. Par exemple : les dépendances éventuelles avec des d’autres composants et API sont identifiées. Ces critères d’acceptation sont définis par l’équipe et évoluent à mesure que l’équipe apprend à partir des problèmes rencontrés qu’elle analyse une fois la Feature livrée.

Toujours de la même façon, une Epic n’entrera pas dans un Incrément Produit SAFe si elle n’est pas Ready To PI. A titre d’exemple, on pourrait dire que si on n’en n’a pas défini le business canvas et les hypothèses de gains attendus, ou si elle n’est pas explicitement liée à un OKR (Objective & Key Result) alors elle ne pourra entrer en phase de réalisation. Encore une fois, ces critères d’acceptation sont définis par l’équipe en charge des Epics et évoluent à mesure que l’équipe apprend à partir des problèmes rencontrés.

Demi-décision = bordel au carré

Standardiser ensemble les interfaces est un gage de clarté et de fluidité. Le respect de ces interfaces est non-négociable : cela crée les conditions de confiance. Si ces interfaces ne sont pas claires ou partagées, cela laisse la place à l’interprétation et aux tensions.

Comme le dit malicieusement Olivier Bas le VP de Havas : « Demi décision = Bordel au carré ». S’accorder ensemble sur les conditions de passages des US, Features et EPIC sont des décisions collaboratives, pleines et entières qui font partie de la colonne vertébrale des équipes auto-organisées.

4.2 Delivery

Dans une équipe travaillant en suivant le framework Scrum, il existe des rituels tels que le Daily. C’est lors de ce point quotidien que l’ensemble des membres partagent leurs avancées et leurs points de blocage : ils inspectent et adaptent le contenu de leur sprint, avec un focus sur la valeur, à savoir les User Stories qui définissent/constituent l’objectif à atteindre. Jour après jour, l’équipe se questionne sur la valeur livrée, à savoir le nombre de User Stories qui ont été livrées et celles que l’on prévoit de livrer. Existe-t-il des obstacles qui peuvent empêcher l’équipe de réussir ? Ces obstacles peuvent-ils être traités en interne par l’équipe ? S’agit-il de dépendances extérieures et a-t-elle besoin d’un arbitrage au niveau de pilotage supérieur ? Auquel cas, comment faire remonter cet obstacle le plus vite possible ?

Au niveau de pilotage supérieur (Train), on intervient à un niveau tactique. Toujours dans le sprint, jour après jour le questionnement va porter plus sur le nombre de Features qui ont été ou qui seront livrées. En effet, les User Stories livrées par les équipes s’agrègent pour constituer des Features et cette unité d'œuvre opérationnelle est celle qui est importante pour le client car elle représente de la valeur d’usage.

Dans le cadre de ce suivi du Train, les intervenants vont arbitrer sur les obstacles remontés par les équipes afin de les débloquer et leur permettre d’avancer de façon nominale. Les obstacles qui ne sont pas à leur main sont alors escaladés au niveau de pilotage supérieur : le programme SAFe.

Lorsqu’on dézoome pour se positionner à ce niveau supérieur de pilotage (programme SAFe), on intervient alors à un niveau plus stratégique avec les Epics qui composent le portefeuille. Ici, semaine après semaine, on se questionne sur le nombre d’Epics qui sont livrées ainsi que sur la nature des points bloquants qui empêchent de les sortir.  Chaque Epic est composée de Features et une fois l’ensemble de ses dernières livrées, l’Epic est à la disposition du client.

A ce niveau remontent les obstacles identifiés par les différents Trains, obstacles que la direction se doit d’arbitrer pour débloquer les équipes. Tout l'enjeu est de gérer au plus vite ces sujets afin d’accélérer la chaîne de décision et que cela redescende dans chaque programme puis dans chaque équipe.

Cette vision du Delivery peut-être représentée par l’illustration suivante

4.3 Amélioration continue

Adaptation au marché et intégration interne

L’amélioration continue représente le douzième principe Agile : on pourrait avancer qu’il s’agit de la raison d’être de l’agilité. Cette dernière peut être vue comme une stratégie pour s’améliorer de part et d’autre de la frontière de l’entreprise.

Tout d’abord la frontière externe, en s’adaptant au marché alors que l’on livre des versions successives du logiciel qui nous permettent de mieux comprendre ce qu’attendent les utilisateurs (le Quoi).

Ensuite, en interne, avoir un espace pour réfléchir à nos méthodes de travail et s’améliorer pour livrer plus vite le bon produit : c’est le Comment.

Une équipe de delivery consacre ainsi du temps, chaque sprint, afin d’inspecter et d’adapter ses pratiques dans l’objectif d’être plus efficace. Elle peut s’appuyer notamment sur certains indicateurs comme le nombre de User Stories initialement prévues versus le nombre réellement livrées. L’équipe se questionne sur les causes premières de cet écart. Quels sont les problèmes qu’elle a rencontrés ; à quelle étape du cycle de vie ; en raison de quelles causes spécifiques ; quelles contre-mesures a-t-elle mises en place ; qu’est-ce qui a fonctionné et qui n’a pas fonctionné ; quels enseignements en a-t-elle tirés ?

Mike Rother, l’auteur de Toyota Kata, explique ainsi que l’apprentissage de l’équipe réside dans l’exploration de cet écart chiffré. En complément de la rétrospective, où l’on traite davantage de sujets liés à des soft skills (qualité de la collaboration), cette partie plus opérationnelle de l’amélioration permet, en explorant des causes spécifiques, d’identifier des contre-mesures actionnables pour y remédier, ensemble.

Notons que Edgar Schein, l’universitaire qui a défini pour la première fois le terme de culture d’entreprise dans les années 1950 - une définition adoubée par des personnalités telles que Jeffrey Liker ou Clayton Christensen -  la résume ainsi dans son ouvrage Organizational Culture and Leadership : “Un ensemble d’hypothèses basiques apprises par un groupe alors qu’il résout des problèmes d’adaptation externe et d’intégration interne : le produit d’un apprentissage commun” : ce travail sur l’amélioration continue peut donc être vu comme un levier majeur pour influer sur la culture de l’équipe.

Questionner le client

Dans une organisation à l’échelle, l’amélioration continue ne doit pas se limiter aux équipes de Delivery. De la même manière, au niveau du pilotage du Train, on doit procéder au même exercice en prenant pour matériel l’unité d'œuvre qui représente de la valeur pour le client : les Features livrées. Combien ont été livrées par rapport à ce qui était prévu ? Quels problèmes rencontrés pour expliquer l’écart ; à quelle étape du processus ; en raison de quelles causes racines ? Que cela nous apprend-il sur notre processus de réalisation de Features ?

Au niveau de la Feature on doit aller plus loin dans l’exploration et se positionner sur les outcomes en allant chercher le niveau de satisfaction des utilisateurs : est-il au niveau attendu ? Quels sont les points de satisfaction remontés par les utilisateurs ? Quels sont les axes d’amélioration ?

On peut aussi explorer aussi le volet coût : combien (de points ou de jours de charge) avions-nous prévus pour livrer ces Features ? Y-a-t-il des écarts ? En raison de quelles causes ?

Construire une connaissance validée du marché

Enfin, si on dézoome dans notre organisation à l’échelle, on peut procéder aux mêmes exercices au niveau du Programme SAFe et des Epic. Un questionnement tour à tour :

1. opérationnel : questionner le nombre livré sur l’incrément (ou la release) ; creuser les causes d’écart, identifier des contre mesures, etc …) ;
2. orienté coût ; en regardant le consommé (points ou jours) sur les Epics sorties vs le prévu ;
3. orienté satisfaction client : quelle note sur le Store mobile ? Quelle nature de  commentaires de clients insatisfaits ?
4. business : les retombées business identifiées dans les hypothèses amont sont-elles validées ? Qu’y a-t-il à apprendre sur notre marché ? Quelle contribution à nos OKRs ? C’est dans cette réflexion que réside le cœur de l’apprentissage business.

L’auteur de The Lean Startup, Eric Ries, dirait qu’ainsi l’entreprise construit une connaissance validée de son marché. Un sujet qui n’est que simplement effleuré ici et qui nécessiterait lui aussi un long article.

L’entreprise agile

Avec cette approche Lean qui regarde le système opérationnel comme une fractale, avec les mêmes principes et le même questionnement, l’entreprise développe alors sa culture agile à tous les niveaux de l’organisation grâce aux boucles de rétroaction et d’amélioration sur chacune des unités d'œuvre.

Le Lean Mindset que SAFe appelle de ses voeux (sans tout à fait le comprendre) est alors omniprésent dans l’ensemble de l’organisation : les collaboratrices et collaborateurs font abstraction des couches de complexité inutile du dispositif pour restreindre leur champ d’attention à la valeur opérationnelle et ce qu’elles et ils peuvent faire, ensemble, pour l’améliorer.

Merci à Brieuc, Yvan et Cédric pour la relecture et les propositions pertinentes d'édition.

Le support Slideshare correspondant à l'article est disponible.