Lors de la visite du site Toyota de Tsutsumi, j’ai été frappé par la diversité des voitures sur la ligne de production : une Prius, deux Camry, une Prius PHV, tout en mélangeant les variantes et les options.

C’est la conséquence de ce que l’on appelle, chez Toyota, le heijunka.

Ce lissage de la production, qui semble contre-intuitif, à priori, est un mélange bien étudié de la demande client, du temps de production de chaque modèle et la capacité des fournisseurs à livrer.

En sortant de la visite, je me suis demandé si le heijunka (terme japonais Lean littéralement lissage ou harmonisation.) pouvait être appliqué à l’IT.

Je me suis posé plusieurs questions :

• Pouvons-nous appliquer le heijunka dans le monde IT ?
• Qu’avons-nous besoin de lisser dans notre production ?
• Ferions-nous déjà du heijunka sans le savoir ou pas du tout ?
• Ces réflexions feront probablement l’objet de plusieurs articles.

Dans celui-ci, je propose de chercher si Scrum (en anglais : la mêlée) et le heijunka (japonais : le lissage) sont compatibles.

Dans un projet waterfall (mode traditionnel), le projet est vu comme un tout et le processus de production consiste à enchainer des séquences de travail — conception, développement, test — dans le but d’arriver à la fin à la production de l’ensemble. Cela permet de garantir un cadre de production stable à l’équipe mais cela ne permet absolument pas de gérer le changement : les découvertes et les apprentissages en cours de projet ne sont pas acceptés ou sont difficiles à gérer car ils mettent en danger la promesse de coût, délai et qualité définis au début du projet.

Le heijunka est une répétition de cycles de même taille qui permettent à l’équipe d’avoir une production lissée.

Je pense que c’est bien ce que Scrum propose : lisser la production d’un projet en lots de deux semaines de travail, les sprints. 

Scrum propose de réaliser le projet de manière itérative et incrémentale. C’est à dire que le projet doit être découpé en éléments de production plus petits qui permettent de livrer le plus vite possible une valeur au client (cette valeur n’étant pas forcément un outil utilisable en production, elle peut être également, par exemple, la validation d’une hypothèse).

Le product owner est l’ordonnanceur du projet. A partir des demandes du client et de la capacité de l’équipe, il va structurer le projet en sprints.

Par rapport à l’ordonnancement de Toyota, le product owner ne lisse pas une demande de produits mixés, il lisse et mixe une demande de valeur, des risques liés à la découverte et l’innovation, des changements dans le besoin du client, des changements de technologies, etc, qui peuvent correspondre à des niveaux de maturité différents.

Le découpage du projet en lots de même taille (en complexité moyenne et en temps) permet à la fois d’absorber la variabilité du projet (changements dus à l’apprentissage et la découverte) tout en proposant à l’équipe un cadre stable : une production lissée, un cadre structuré par des rituels et des standards. Chaque sprint va comprendre l’ensemble des tâches de la production : conception, développement et test. Le projet est donc bien ordonnancé en lots de production standardisés, de même taille, réalisable sur la même « chaine de production ».

Un projet IT n’est jamais un projet figé, ça tombe bien, le heijunka est conçu pour absorber la variabilité. Dans notre cas, celle-ci n’est pas liée aux ventes de produits mais à la conception d’un produit.

Dans le fond, les produits sont différents, mais la logique est la même. Scrum permet donc de mettre en place la logique du heijunka.