Le stock, c’est un problème.
Je ne parle pas seulement de votre garage probablement aussi encombré que le mien de trucs en instance de départ vers la déchetterie.
Je parle du temps investi dans la fabrication d’un logiciel, rangé à un endroit en attendant d’être livré.
Oui, ce stock-là. Les fonctionnalités inachevées. Le code “presque terminé”.
Mais d’ou vient-il ?
Et bien dans l’univers imaginaire de Jira et de Confluence, tout se déroule merveilleusement selon une valse en 3 temps :
1) on a une idée
2) que l’on exprime dans une spécification (”user story”)
3) dont une équipe s’empare pour améliorer un logiciel.
Mouais. Sauf que dans la vraie vie, ça se passe plutôt comme ça :
Il y a pleins d'étapes intermédiaires, entrecoupées de reprises et de blocages.
Bloqué par la validation de quelqu’un. Par une demande imprécise. Par une difficulté technique ou un test non concluant.
Alors on passe à autre chose en attendant, parce qu’on ne va quand même pas rester oisif.
Et paf, on vient de créer du stock. Animé par cette bonne volonté de paralléliser. De faire avancer d’autres sujets en attendant.
Intuitivement, ça semblait pourtant la bonne option. Optimiser son temps de travail avec la promesse d’une avalanche de produits finis et de sujets clos (quand tout va enfin se débloquer).
Sauf que l’inefficacité de ce mode de fonctionnement est démontrée. Depuis les années 60...
Alors comment faire ?
3 principes simples du Lean.
L’industrie automobile japonaise a en effet prouvé la toxicité du stock au reste du monde (en commençant par les constructeurs américains qui en ont fait les frais).
L’important c’est le flux.
Chaque nouvelle unité de stock révèle un problème de flux qui n’est pas adapté à la demande.
Dans un excellent talk (le lien en fin de cet article), Steve Anavi explique comment Qonto s’est approprié les méthodes du Lean pour délivrer un produit que les utilisateurs aiment. Il faut reconnaître que ça a plutôt bien fonctionné pour eux.
Il présente 3 principes simples d’apparence, et parfaitement à l’opposé des croyances établies dans la tech.
Principe 1 : une seule chose à la fois
Une équipe de taille “pizza” (= qui peut faire un repas avec une grande pizza) ne travaille que sur 1 seule fonctionnalité.
La squad constituée d’un-e pilote produit, d’un-e graphiste UI/UX et d’un-e ou 2 devs sont mono-tâche. Aucun d’entre eux ne passe à autre chose tant que la fonctionnalité sur laquelle ils travaillent n’est pas en production.
Mais quand on est bloqué ?
Principe 2 : L’andon. On arrête tout.
Probablement le principe qui semble à l'opposé de ce que l’on croit nécessaire pour aller vite.
Lorsqu’un des membres de l’équipe est bloqué, dans l’attente de quelqu’un d’autre ou de n’importe quel autre problème, on arrête tout tant que ça n’est pas solutionné.
Si le développeur attend la maquette UI du graphiste qui attend l’avis du PO —> STOP. Les 3 se mettent (immédiatement!) autour de la table et conviennent d’une solution permettant de repartir tout de suite.
Face à un problème, on cherche la cause avant la solution. Personne n’attend la “daily” de demain ni la “rétro” scrum dans 15 jours. C’est tout de suite. Et si besoin, on fait évoluer les standards.
Les quoi ?
Principe 3 : les standards
Un standard, c’est un post-it vivant qui résume en 1 page les points importants pour parvenir au niveau de qualité attendu.
Dit comme ça, on a l’impression de revenir en arrière et de briser tout élan créatif avec des procédures poussiéreuses.
Mais disons-le tout net : votre client s’en fiche de vos états d’âme. Il veut acheter son sandwich maintenant avec son téléphone. Sans bug, sans complexité, sans délai (parce qu’il a faim).
Fabriquer un produit tech, c’est difficile.
Alors si tu sais comment livrer du code de qualité, écris-le et explique-le. N’attend pas que ton CTO ou ton lead le fasse dans un pavé obsolète contre-signé par la moitié du board de la boite.
Si tu sais comment faire une UI exhaustive et facile à intégrer qui ne couvre pas seulement un seul contexte ou tout va bien (mais aussi en cas d'erreur, lorsqu'aucune donnée n'est encore présente, responsive, ...), écris-le et explique-le.
Maintenant.
Un document qui guide notre façon de travailler et auquel on a nous-même contribué, c’est un outil simple et puissant pour accroître la qualité de ce qu’on fait.
Et ça donne confiance.
Passez au Lean.
Le Lean regorge d’outils intéressants qui peuvent être déclinés dans beaucoup d’organisations qui délivrent un produit ou un service. Ils sont à tort cantonnés à l'univers de la production industrielle.
Pourtant, je trouve le Lean très aligné avec les principes du manifeste Agile. Comme s’il s’en était inspiré !
- La stratégie lean chez Qonto : https://www.youtube.com/watch?v=_XHhnQ1BmSc
- Lean and Agile Software because or despite Rising Complexity by Yves Caseau, Group CIO, Michelin : https://www.youtube.com/watch?v=k-I0Qp5Eosw
