Exemple de complémentarité de l’approche agile et du lean management, notamment dans un contexte de croissance (scale-up).
La semaine dernière j’ai accompagné Marine, CTO d’une société que nous appellerons SPEEDEV, comme régulièrement depuis deux ans. Cette société développe des solutions web et mobiles pour aider leurs clients à résoudre des problèmes business. Depuis le début les équipes utilisent SCRUM comme modèle de production, mais également le Lean management depuis deux ans.
Ses équipes réussissent à délivrer de manière fréquente des applications en utilisant SCRUM avec des sprints d’une semaine. Elles ont atteint un certain niveau de maturité. Pour preuve, chaque équipe livre quotidiennement quelques user stories pour validation par le product owner (PO). A chaque fin de sprint l’équipe demande au PO quel est son niveau de satisfaction et ce qu’il faut améliorer de son point de vue.
La plupart des clients de SPEEDEV sont satisfaits des services de cette organisation qui est en forte croissance avec +100 % en un an.
Cependant certains clients restent sur leur faim, voire manifestent de l’insatisfaction : ils ne sont pas pleinement satisfaits car le produit final délivré en X sprints ne comporte pas toutes les fonctionnalités qu’ils espéraient.
Pourtant les équipes affirment qu’elles ont réussi leurs sprints et délivré tous les story points qui étaient prévus ! En effet, un sprint réussi signifie que tous les story points sur lesquels elle s’est engagée ont été réalisés et que le Sprint Goal a été livré : il s’agit d’une ou plusieurs user stories que le PO considère comme obligatoire dans ce sprint. Évidemment il y avait eu, au fur et à mesure des sprints, des réajustements des contenus de sprint en fonction des découvertes sur la valeur à délivrer, grâce aux tests utilisateurs et leurs feedbacks.
C’est le cas du projet de Yacine, coach agile dans cette organisation. Sophie la PO n’est pas satisfaite de la vitesse des développements. Pourtant l’équipe a « réussi » ses derniers sprints.
Que se passe-t-il donc ?
La cliente serait-elle de mauvaise foi ?
La mesure du story point et la vélocité seraient-elles inadaptées ? Pourtant elle permet d’organiser l’équipe en fonction de la capacité à produire de chacun, en suivant les estimations en nombre de points.
Une visite terrain avec Marine, la CTO, a permis d’identifier plusieurs causes :
- des points ont été utilisés pour corriger des bugs introduits lors des sprints précédents ;
- des points ont été utilisés dans le cadre de tickets d’investigation car l’équipe ne maîtrisait pas certaines des technologies qu’il fallait embarquer dans le produit, et donc se posait beaucoup de questions sur leur mise en œuvre ;
- pour certaines user stories l’équipe a surestimé leur nombre de points pour leur réalisation, par rapport à ce qu’aurait fait l’architecte-développeur du projet.
Le Lean management, par essence, permet de regarder finement une activité avec la perspective du client et ceci de manière très pragmatique :
- La correction de bugs est considérée comme un gaspillage car n’apportant pas de valeur aux clients et aux utilisateurs. Or, ici elle est « masquée » par le comptage en nombre de points : travailler sur un point c’est considéré comme normal, donc traiter sur un bug c’est normal.
- Investiguer c’est nécessaire jusqu’à un certain point. Mais stricto sensu ça n’apporte pas de valeur directement au client. Dans notre cas cela masquait le manque de compétences et de savoir-faire sur une technologie à mettre en œuvre dans le projet, l’appel à une API complexe d’une tierce-partie.
- La surestimation du nombre de points peut également provenir du manque de compétences en règles d’estimation, en connaissance des technologies, et en connaissance du fonctionnel à développer.
Que signifie réussir sa journée ?
Une question Lean se pose alors : que signifie une journée réussie ? Marine la CTO pose la question à différents développeurs et coachs agiles de son organisation et tantôt la réponse est « réussir le nombre de points sur lequel je me suis engagé », tantôt c’est « livrer les features sur lesquelles je me suis engagé ».
La réponse du coach lean est très claire : réussir sa journée c’est livrer au rythme du client, livrer les produits qu’il attend et quand il en a besoin, et avec la qualité requise. La mesure de ce rythme (en moyenne) est appelée « le takt time ». Par exemple chez Toyota c’est livrer une nouvelle voiture (le produit) toutes les 70 secondes (le rythme).
Une question se posait alors à la CTO : quel « produit » considère-t-on ? Un story point, un module logiciel, un ticket, une user story, le produit final ? Après questionnements, la CTO en arriva à considérer que le produit livré régulièrement au Product Owner est la user story. C’est en effet ce qui lui est livré quotidiennement/ hebdomadairement. Ok, mais alors quel est le rythme moyen de user stories à livrer par jour ?
Pour répondre à cette question, l’équipe est aidée grâce à la décomposition du produit final en roadmap/ story mapping dans laquelle chaque sprint contient les user stories à développer. Elle arrive au calcul donnant 2 user stories à livrer au PO chaque jour.
Ainsi l’approche est la suivante :
- Quel est le produit cible ? Quelles sont ses EPICs ? Combien de user stories pour chaque EPIC ? (En Scrum, une « EPIC », ou Epopée, est un ensemble cohérent de fonctionnalités/besoins non fonctionnels dont la taille nécessite un découpage en plusieurs user stories).
- Combien de sprints et journées ouvrées de « production » (hors cérémonies) sont-elles prévues ?
- Le takt time est le ratio entre le nombre de jours ouvrés de production et le nombre de user stories à livrer. Par exemple pour un projet de 40 jours ouvrés de production avec un client qui attend 80 features dans le produit final, le takt time est de 0,5 : une user story doit être livrée toutes les demi-journées, ou 2 à la fin de chaque journée de production.
Un rythme de livraison pour quoi faire ?
Vous allez me dire qu’on ne peut pas au début d’un projet connaitre précisément le nombre de user stories qu’il faut réellement livrer pour obtenir le produit final, et donc que ce takt time est « faux ». Vous avez raison. C’est notamment pour cela que l’agile existe sinon on saurait développer un produit sur la base d’un cahier des charges de centaines de pages… Mais avoir un rythme de livraison est mieux que ne pas en avoir du tout et avancer chaque jour « à l’aveugle ». Ce rythme doit être recalculé en début de chaque sprint à chaque fois que la roadmap est affinée, en fonction du nombre de jours restants et du nombre de user stories à réaliser.
Avec cet objectif de rythme de livraison, les sprints ne peuvent plus être considérés par l’équipe comme réussis si à la fin du sprint toutes les user stories n’ont pas été livrées : l’équipe a livré 5 users stories au dernier sprint au lieu des 8 attendues par le Product Owner. Il y a donc un écart de 3 user stories donc un problème à comprendre.
L’équipe n’est plus « aveugle » : elle voit alors quotidiennement si elle remplit ou non sa mission, et dans le deuxième cas elle peut déclencher une résolution de problème.
Ainsi la CTO a revisité la définition d’un sprint réussi, définition qui est maintenant la suivante :
- l’équipe a livré les user stories sur lesquelles est s’est engagée ;
- l’équipe a respecté la roadmap établie avec le Product Owner (nombre de user stories prévues dans la roadmap) ;
- l’équipe a corrigé tous les bugs à la fin du sprint (première étape dans l’amélioration de la qualité des produits livrés, la cible suivante étant de ne pas créer de bugs ou le moins possible) ;
- l’équipe a levé les obstacles (ex. dépendances) du prochain sprint.
Ce que n’a pas précisé Marine la CTO dans cette définition c’est que les personnes ne doivent pas dépasser le nombre standard d’heures de travail dans la journée (et zéro le weekend).
Le Lean permet aux équipes agiles de mieux comprendre ce qui a de la valeur pour leurs clients
On peut donc conclure qu’utiliser les principes Lean (par exemple le just à temps avec le takt time), permet aux équipes agiles d’identifier les problèmes qu’elles doivent résoudre pour mieux satisfaire leurs clients. Y faire face est nécessaire mais pas suffisant : la résolution de ces problèmes est souvent ardue et nécessite une méthode efficace. Le Lean propose la méthode scientifique de résolution de problème : le PDCA. Mais ceci est le sujet d’un futur article 🙂
Si vous avez des questions, contactez moi sur marc.legru@operaepartners.com ou sur Twitter http://www.twitter.com/MarcLegru A Paris, à Lille, ou ailleurs en France et en Europe, nous vous aidons en Agile et Lean IT / Lean Digital par du coaching et des formations.
Better, faster, together 
Merci pour cet article. Le Lean est super concret là où l’approche Agile reste parfois un peu vague. Donc les 2 ensemble c’est une machine de guerre presque infaillible !
Réflexions que je me fais en lisant votre article sur la compatibilité du takt time avec l’approche Agile : je vois mal comment on peut réussir un sprint avec la liste de critères que vous donner dans votre exemple.
C’est le beurre et l’argent du beurre non 🙂 ? on ne peut pas avoir l’avantage de l’agile sans en avoir certains inconvénients. Ne faut-il pas mieux avoir à la fin d’un projet :
– moins de fonctionnalités que souhaitées au départ (souvent accéssoires)
– mais avoir un coeur d’outil qui correspond précisément au besoin car il s’est construit intelligemment au fur et à mesure
– et avoir un outil de qualité (parce que les équipes ont pris le temps nécessaire à sa bonne réalisation même si celle si dépasse les 1ères estimations, du temps de R&D, du temps pour débuger).
J’ai souvent vu souvent les clients rêver avec leurs SPECs et avec l’agilité on remet les pieds sur terre en challengeant leur backlog et en sensibilisant le client sur la nature même du dev qui est une aventure en terre plus ou moins connue. Il faut jouer le jeu et accepter que sa roadmap n’est qu’un point de départ, une vision sur laquelle travailler mais si ils s’attendent à ce que ce soit respecté c’est pas très honnête intellectuellement de leur vendre ça non ?
J’aimeJ’aime
Merci Anne-Laure, oui Lean + Agile c’est une machine de guerre presque infaillible ! Je connais quelques entreprises (Theodo par exemple, chez qui vous avez travaillé) dont les équipes réussissent régulièrement leurs sprints avec cette liste de critères. Les semaines où elles n’y réussissent pas, elles font une résolution de problème pour découvrir les opportunités d’apprentissage pour être plus fortes. Et elles s’améliorent 🙂 Vous pouvez contacter des personnes chez Theodo pour avoir leur témoignage.
Je vous suggère de vous documenter sur le lean, notamment en lisant ce PDF gratuit http://www.leanagilecamp.fr et https://www.infoq.com/fr/articles/scrum-toyota-production-system . Au plaisir d’échanger si vous voulez. Bonne lecture !
J’aimeJ’aime