Au programme de l’évènement, une présentation du Lean pour le logiciel (votre serviteur), un Casino Game dans un espace ouvert (c’est une première pour moi), et beaucoup de présentations sur le Lean dans toutes ses déclinaisons (Lean et PLM, Lean et ERP, Lean Engineering, Lean Office …).

J’espère bien en apprendre beaucoup

La lecture de cet article (Les étranges dessous de l’affaire Toyota) donne une vision nouvelle de la situation, et qui, même si je ne peux pas juger de sa véracité, me semble très intéressante à lire.

Intox et contre-intox diront certains, pourquoi pas, je ne connais ni le rédacteur de la note, ni la fiabilité du site knowckers.org, mais je vous laisse vous faire votre propre impression (merci pour le pointeur Franck )

Cette approche est un réductrice car si la traque des MUDA (gaspillages en Japonais) est essentielle, elle n’est qu’un des 7 concepts du Lean pour le logiciel, il y en a donc 6 autres (Eliminate Waste, Build Quality In, Defer Commitment, Create Knowledge, Deliver Fast, Optimize the Whole, Respect People).

De plus cette approche par les gaspillages est erronée car elle ne tient pas compte de la notion de maîtrise de la variabilité qui doit arriver AVANT la réduction des gaspillages.

En effet, réduire les gaspillages sur un système à forte variabilité ne conduit pas automatiquement à une amélioration du système et donc à une augmentation de la satisfaction client.

Vous n’êtes pas convaincu ?

Alors essayez ce simple exercice :

• Constituez une chaine de production de 5 ou 6 personnes en séquence.
• Donnez 10 allumettes au premier
• Faites lui lancer un dé à 6 faces.
• Faites lui donner le nombre d’allumettes indiqué sur le dé au 2ème.
• Faites lancer le dé au 2ème, et faites lui donner le nombre d’allumettes indiqué sur le dé au 3ème
• Continuer ainsi jusqu’au bout de la chaîne
• Recommencer jusqu’à ce que les 10 allumettes soient arrivées au bout de la chaîne

La moyenne d’un dé à 6 faces est de 3,5 et on devrait donc voir les 10 allumettes au bout de la chaine en 3 passages … mais la réalité est qu’il faudra 6 ou 7 passages … pourquoi ?

Maintenant doublez la capacité de production de l’équipe en utilisant un dé à 12 faces (si, si cela existe, demandez aux joueurs de jeux de rôles) et refaites l’exercice … et oh surprise … vous constatez qu’il vous faut encore 5 ou 6 passages … soit à peine mieux qu’avant pour un coût double  !!!

L’explication de ce phénomène est dans la variabilité des dés – ou écart type – qui est très forte et qui annihile l’effet bénéfique de l’augmentation de la capacité de production.

Maintenant prenez un dé à 6 faces, mais collez un sticker 3 sur les faces 1 et 2, et un sticker 4 sur les faces 5 et 6. Vous obtenez un dé avec 3 faces à 3 et 3 faces à 4 … la moyenne est toujours de 3,5 mais la variabilité est très faible … et si vous refaites l’exercice, vous constaterez qu’il ne vous faut plus que 3 passages (4 parfois). Et 2 passages avec un dé à 12 faces modifié suivant le même principe (et vous auriez même pu faire passer 12 allumettes au lieu de 10).

De la même façon la recherche et la réduction des gaspillages sur un système à variabilité forte ne va pas forcément conduire à une augmentation de la productivité … donc il est indispensable de commencer par réduire la variabilité puis de chercher à réduire les gaspillages.

Avec Scrum, pour calculer la variabilité, il suffit de mesurer la vélocité produite et de la comparer aux estimations de l’équipe. Lorsque l’équipe produit de façon régulière les points prévus, alors sa variabilité est faible et vous pouvez vous attaquer à la réduction des gaspillages car vous êtes certain d’améliorer le système et de produire plus pour moins cher.

Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.

Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.

L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.

Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement (« Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !

Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de  passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.

Et vous, comment trouvez vous du temps pour réduire votre dette technique ?

.

.

.

.

.

.

.

.

.

.

.

Excellente idée de l’équipe organisatrice de l’évènement sur Valence que d’avoir mis des grands papiers à la sortie des salles sur lesquels chacun pouvait mettre une note entre 1 et 5 pour donner un feedback immédiat à l’orateur sur la façon dont son intervention avait été appréciée.

Pour les 2 miennes (« Lean Sofwtare Development : La vision des Poppendiecks » et « Artistes et Spécifieurs« ) que des 4 et des 5 … et une majorité de 5 … et j’arrête car mes chevilles et mes doigts enflent et je n’arrive plus à taper sur le clavier correctement

J’aime beaucoup cette idée pour 2 raisons principales :

• Elle est simple et donc très KISS (Keep It Simple Stupid), ce que les agilistes aiment particulièrement
• Elle est immédiate … et globalement, agilistes ou pas, nous n’aimons pas attendre

Bravo aux organisateurs Valentinois pour la conférence et pour cette idée

Vendredi dernier était le jour choisi par mon client pour la session de VSM. Toute l’équipe était réunie dans une même salle avec pour seuls outils un tableau blanc, des marqueurs et des cerveaux prêts à fonctionner … il ne me restait plus qu’à faire « prendre la mayonnaise »

… 2h00 plus tard, le VSM était réalisé et la discussion était vive sur les ratios obtenus pour les 2 cycles de vie analysés (12% et 3 %) et quelques idées d’amélioration étaient même déjà discutés.

Le fait de rendre le gaspillage temporel visible sur un tableau permet à l’équipe de s’appuyer sur ce support pour discuter, évaluer des pistes de solutions et inviter simplement d’autres acteurs à la réflexion.

Cela confirme que le VSM est un outil particulièrement performant et comme il est plutôt simple à mettre en place, pourquoi s’en priver.

(*)VSM : Technique qui consiste à partir du client et de son besoin, puis d’identifier toutes les opérations « utiles » qui s’enchaînent avant de revenir au client avec un besoin satisfait. La durée de chaque opération est notée, de même que les temps pour passer d’une opération à une autre et le ratio final est calculé en divisant la somme des temps utiles par le temps total. La difficulté réside dans l’évaluation des durées moyennes et la notion d’opérations « utiles pour le client ». (Wikipedia en anglais)

Regardez la vidéo, trouvée par hasard sur DailyMotion, des équipes valentinoises de Thales qui mettent en application avec succès les approches Lean et Agile.

En plus ILS SONT BEAUX … bon d’accord, je ne suis plus crédible

L’approche Lean se focalise sur la satisfaction du client final, et en particulier cherche a éliminer les gaspillages de temps et donc à livrer le plus rapidement possible au client final.

Il m’a toujours semblé qu’il n’y avait pas d’antinomie entre les 2 approches … et pourtant !

En Scrum, lorsque les items du Backlog sont déclinés en tâches lors du Sprint Planning Meeting, il est recommandé à l’équipe de choisir en premier les tâches associées aux items de priorités les plus fortes et de respecter ces choix quoi qu’il arrive. Le Product Backlog est renseigné avec différents éléments, des exigences fonctionnelles, des besoins non-fonctionnel et des bugs.

Cette façon de procéder est basée sur quelques principes :

• Répondre aux attentes du Product Owner qui cherche à produire de la valeur ajoutée rapidement
• Éviter les changements de contexte qui consomme beaucoup de temps à l’équipe
• Assurer que des items du Backlog seront réellement terminés et qu’il ne sera pas nécessaire de revenir dessus

De plus,à titre personnel, je note bien souvent un intérêt grandissant au sein de l’équipe lorsque tous les membres travaillent sur le même item, l’écoute et l’entraide sont alors nettement meilleurs.

Pour le Lean, la satisfaction du client et la réduction des coûts passent en premier, et il est donc nécessaire de chercher à réduire les temps moyens d’attente. Lors du XP Days, Marie-Pia nous a présenté un exercice simple pour illustrer ce principe qui consistait à faire passer 15 passagers à la douane avec le moins d’attente possible sachant que les certains passagers passent en 1′, d’autres en 4′ à 7′, et certains entre 15′ et 25′. La solution optimum pour réduire le temps d’attente moyen des passagers consiste à spécialiser un douanier dans les passagers rapides.

En général, la correction des bugs prend moins de temps que la réalisation des exigences fonctionnelles, dans la logique du Lean, il serait plus efficace de gérer un backlog de bugs indépendant et dédier 1 ou 2 membres de l’équipe à leur correction. De plus, cela pemettrait d’éviter de dire aux utilisateurs que leur « petit » bug ne sera corrigé que dans 4 sprints compte tenu des priorités existantes, ce qu’en général il ne comprend pas … à juste titre.

Coté méthode Scrum, la recommandation est de gérer les priorités de tout ce qui est à faire – bugs inclus – à un seul endroit, le Product Backlog, puis de respecter les priorités … et donc de ne pas choisir la solution qui réduit le temps d’attente moyen des clients au minimum.

Etonnant non, comme dirait Mr Cyclopède

Mais le Product Backlog ne contient pas seulement des User Story puisque l’on y trouve également des exigences non fonctionnelles (souvent des demandes techniques demandées par l’équipe) et des bugs.

Alors les questions qui se posent sont :

• Est-ce que la vélocité d’une exigence non fonctionnelle ou d’un bug a un sens ?
• Doit-on estimer ces vélocités avec les mêmes pratiques ?

Si l’on revient à ce qu’est une User Story, l’aspect création de VALEUR pour l’utilisateur en est un aspect essentiel. Si l’on suit cette logique, les exigences non fonctionnelles apportent généralement de la valeur car ce sont souvent des améliorations du code qui permettent de gagner en temps de réponse, en vitesse d’exécution, en qualité du produit et en stabilité. De plus les exigences non-fonctionnelles peuvent être évaluées par la méthode du Poker Planning de la même façon que les User Story.

Compte tenu de ces éléments, il semble rationnel de comptabiliser les points des exigences non fonctionnelles dans la vélocité de l’équipe.

Pour ce qui est des bugs, il en est différemment puisque l’utilisateur n’a jamais eu besoin d’un bug et il n’y a aucune valeur ajoutée à lui livrer des bugs (sauf pour dilbert qui vend des versions +1 pour corriger les bugs, et comme le client accepte, Dilbert appelle l’équipe technique pour lui demander de rajouter des bugs).

Donc dans cette logique, les bugs ne doivent ni être évalués en points ni être comptabilisés dans la vélocité.

Une itération lors de laquelle l’équipe corrige beaucoup de bugs aura une vélocité faible, ce qui est un signal de dysfonctionnement du système. L’équipe devra alors mener un plan d’action pour réduire les bugs au minimum, comme par exemple employer les bonnes pratiques d’ingénierie venant de XP … qui est aussi une méthode

Le Lean propose une approche inverse et plus simple à mettre en œuvre puisque le Lean considère que tout gaspillage augmente de fait le coût de production. Pour réduire les coûts il faut donc identifier les gaspillages, qui sont au nombre de 7, et les réduire au minimum (les faire disparaître est quasiment impossible).

Donc, plutôt que de chercher la cause de la dépense il faut identifier et réduire chacun des 7 gaspillages.

Il est très difficile de relier directement un des gaspillages à un coût de production, même avec une approche analytique, mais pourtant si vous réduisez vos gaspillages, le Lean vous le garanti, vous obtiendrez une réduction de vos coûts globaux.

Encore sceptique … rien que de bien naturel … mais pourquoi ne pas essayer ?