Temps de lecture moyen : 4 mn
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 :
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.
Afin de mettre en place le heijunka par volume de pièce, il faut :
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 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 :
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 :
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)
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 :
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 !