par 
La question du blog
Suite à un récent gemba walk dans une usine de production, je me suis intéressée à la question du juste-à-temps. L’entreprise a fait beaucoup d’efforts pour mettre en place le flux tiré lissé dans tout l’atelier, cependant je me suis souvenue de ce que les senseis disaient « flow wherever you can, pull where you can’t & level always ». Sur ce gemba, il y avait très peu de flux continus, on aurait dit qu’il était sorti de l’équation bien qu’à certains endroits aucune raison technique ne justifiait d’aller vers un flux tiré plutôt qu’un flux pièce-à-pièce.
Ceci m’amène donc à ma première question : Quelles sont les raisons qui nous empêchent d’aller jusqu’au flux continu ?
La réponse de Régis
Dans le monde des startups en forte croissance, on trouve des situations aux antipodes du flux continu dans les activités de développement logiciel avec des “backlogs” de fonctionnalités “en cours” qui peuvent représenter plus de 6 mois de travail.
La vitesse de développement des produits est pourtant un facteur clef de survie de ces entreprises qui doivent croître très vite pour espérer atteindre la taille critique qui mène à la rentabilité.
Parmi les différents facteurs qui expliquent cette situation, il y a d’abord l’idée selon laquelle l’entreprise va plus vite si chaque individu travaille a fond. Si l’on ramène cette activité à un processus simple à deux étapes, c’est-à-dire 1/ la conception par les product managers et 2/ l’implémentation par les développeurs du logiciel, les product managers sont incités par leur direction à aller toujours plus vite indépendamment de l’avancée des développeurs — c’est-à-dire travailler en flux poussé.
Ensuite la diffusion des méthodes agiles a déjà amené à réduire la taille des fonctionnalités, donc à travailler en petits lots, mais il reste une variabilité importante dans la taille des différentes fonctionnalités et surtout la différence de temps de traitement entre la conception et l’implémentation. La notion de takt est encore difficile à accepter (“toutes les fonctionnalités sont différentes !”), aussi il y a systématiquement des écarts de capacité structurels, soit parce qu’il y a trop de product managers par rapport au nombre de développeurs, soit l’inverse. Cela conduit nécessairement à ce que des fonctionnalités restent en attente quelque part.
La variabilité est renforcée par des problèmes de qualité. On découvre très souvent pendant l’implémentation des erreurs introduites en phase de conception, mais la pression sur la vitesse est telle que les défauts sont vite corrigés et on passe à la fonctionnalité suivante sans rien apprendre.
Et pour finir, dans une entreprise qui grandit vite il y a de nouvelles recrues qui arrivent toutes les semaines. Cela crée des écarts de savoir-faire très importants entre les individus qui alimente encore la variabilité et éloigne les équipes du flux continu.
Tout l’enjeu dans ce monde-là, c’est donc de changer d’avis sur deux sujets. D’abord, la variabilité et la stagnation ne sont pas des fatalités mais des opportunités de comprendre toujours plus en profondeur le metier de l’entreprise et la pratique de conception des logiciels. Ensuite, la montée en puissance des collaborateurs n’est pas juste une affaire de performance en recrutement ou de patience (les responsables techniques tirent parfois de la fierté du fait qu’il faut plus d’un an à un développeur pour commencer à être à l’aise dans l’équipe). La montée en puissance des équipes produit et des équipes techniques est un facteur clef de vitesse et de développement de l’entreprise, qui s’accélère justement… par la recherche constante du flux continu !
