Lean Principe #4 : Production constante et lissée (Heijunka)

Chez Captive, nous avons décidé de partager avec vous chaque semaine les enseignements que nous tirons du Lean dans notre activité quotidienne d'agence de développement.

La semaine dernière, nous avions abordé le troisième principe du Lean : Fluidité, le pièce à pièce. Cette semaine, nous allons abordé le troisième principe du Lean : la production constante et lissée, aussi appelée heijunka.

Le mot heijunka signifie en japonais "nivellement". Le principe est donc de procéder à un nivellement de la production à partir de la demande du client afin de la rendre la plus constante et la plus lisse possible.

Dans l'industrie traditionnelle, ce mode de production apporte les bénéfices suivants :

• Réduction des stocks : la valeur étant régulièrement livrée aux clients, il n'y a donc pas besoin d'avoir de grand stocks
• Rythme soutenable pour les équipes : couplé avec le principe de production par flux, la pratique du heijunka permet de s'assurer à la fois que toutes les commandes soient honorées à temps tout en évitant un effet de sur-sollicitation

Les deux axes du heijunka pour prévoir le plan de production

Rappel des précédents articles : nous utilisons le mot "pièce" pour qualifier l'unité de production. Par exemple, dans notre métier d'agence de développement cela peut être des user story, pull request, etc

Il existe deux axes principaux pour appliquer le nivellement : le volume et le type des pièces.

Le plan de production basé sur le volume de pièces: le plus utilisé dans l'industrie

Afin de mettre en place le heijunka par volume de pièce, il faut :

1. Connaitre son volume moyen de pièce à réaliser pour les clients
2. Calculer un rythme de production (Takt Time) à partir de ce volume  pour satisfaire toutes les demandes

Exemple : Pour satisfaire un volume moyen de commande de 10 voitures / semaine (5jour ouvrés), l'équipe va s'imposer un takt de 10/5 = 2 voitures par jour.

Le plan de production basé sur le type de pièces: le plus utilisé dans le développement informatique

Le heijunka par type de pièce repose sur la production de types de pièces différentes sur une même ligne de production. L'intention est la même que pour le nivellement par volume, mais ici il faudra prendre particulièrement en compte variabilité des pièces.
C'est un sujet qui intéressera tout particulièrement la tech, car la plupart des pièces sont différentes entre les projets, les clients, les technologies (front/back).

On réalise alors que le monde de la tech doit alors faire face à deux challenges :

• Comment faire des estimations fiables des pièces à produire ?
• Comment prioriser les pièces dans la roadmap ?

Estimer de manière fiable les pièces à produire 

Dans la tech, le heijunka va changer la manière de voir les choses, notamment pour les pratiquant du SCRUM et du poker planning.

Le constat observé est le suivant : plus une estimation est grosse moins elle est précise. Le poker planning est donc dangereux dans le sens où on "autorise" des user stories "grosses" qui ne seront jamais livrées à temps.

Partant de cette observation, on comprend qu'on va devoir limiter arbitrairement tous les tickets au delà d'un certain score. Mais dans ce cas pourquoi choisir un score si on peut tout de suite parler de temps (Lead Time) ? 

On va progressivement se rendre compte que l'on a plus besoin de passer de longues heures à chiffrer, mais plutôt un réel travail de découpage des pièces "compliquées" en plus petites et plus faciles :

• Chaque pièce ne doit pas dépasser l'étalon maximum choisi par l'équipe (ex: chaque user-story doit prendre 1 jour maximum)
• L'amélioration continue va permettre de baisser progressivement cet étalon pour gagner en précision (jour > demi-journée > heure > minutes)
• Plus l'étalon est petit, plus l'équipe est réactive en cas de problème de production ou de retard :  le Team Leader sait que lui et/ou l'équipe doivent agir immédiatement.

Prioriser les pièces à produire dans la roadmap de développement

A partir du moment où on arrive à améliorer les estimations en découpant au maximum le travail en petites pièces, de nouveaux problèmes vont émerger liés à l'organisation et la priorisation du Kanban.

1/ Le Product Owner a plus de difficultés pour prioriser les pièces et les développeurs plus de difficultés à lier une pièce à son contexte global.
Le Product Owner et/ou les Team Leaders vont donc devoir améliorer la représentations des pièces composites (groupe de pièce nécessaire à l'assemblage d'une pièce plus grosse) en utilisant les outils graphiques plus adaptés : Epics, Initiative, Bento, etc.

2/ Certaines pièces dépassant largement l'étalon que l'équipe s'était fixée surviennent encore régulièrement (ex: 1 semaine vs 1journée prévue). La cause la plus commune est souvent le fait que les développeurs acceptent de travailler sur une pièce sans savoir réellement comment faire. Cela part d'une bonne intention, mais en réalité il est rare que le Product Owner ou le client ait réellement compris le risque que représentait la pièce. Il peut être pertinent de séparer plus explicitement les investigations techniques (Proof Of Concept, spikes, etc), du reste de la production. Ces expérimentations peuvent être traitées également comme des pièces à produire avec des caractéristiques propres (livrable, standard, etc)

Utiliser le Heijunka comme plan de production dans la tech et en particulier le développement informatique

D'un point de vue strictement méthodologique, un heijunka peut se mettre très simplement en place avec un simple tableau avec les jours de la semaines et le type de pièce correspondant que l'on va produire.

Malheureusement, on prend conscience que dans la tech, le heijunka requiert une certaine maturité des équipes en terme d'estimation et de priorisation. Ces deux problématiques sont parmi les plus difficiles de l'industrie et obtenir un vrai tableau de lissage peut paraître décourageant, voire inatteignable.

L'important n'est pas forcément d'y arriver mais d'essayer de tendre vers cet idéal et de s'adapter à la situation de l'entreprise. Je recommanderais pour cela deux axes de progression :

• Réduire la variabilité des pièces en standardisant les gestes, cataloguant les types de pièces, etc
• Réduire la variabilité du Lead Time en faisant de la résolution de problème (PDCA) sur ceux qui créent les variations les plus importantes

C'est à partir d'un Lead Time stable et de pièces correctement cataloguées que l'on pourra alors mettre en place le Heijunka au plus proche des attentes. 

Captive est une agence de développement informatique qui pratique le Lean. Vous avez un projet ? N'hésitez pas à nous contacter !