Lorsque nous abordions le Lean pour le mettre en pratique sur nos projets de développement, nous l'abordions selon les axes suivants:
- la définition de la valeur,
- la cartographie du flux de valeur,
- le flux continu,
- le flux tiré et
- le perfectionnement.
Cette approche, très centrée sur le process, nous a amené à reprendre des outils issus du Lean qui ont été efficaces chez d'autres et à les mettre en oeuvre chez nous: value stream mapping, kanban, just in time, autonomation, jidoka, andon, etc ...
Cette démarche s'est greffée sur notre déjà longue pratique du développement logiciel agile, centrée sur l'eXtreme-Programming (d'abord!) et Scrum (pour la forme). Naturellement, le terrain de rencontre de ces deux démarches a été le Lean Software Development.
Nous sommes fiers d'avoir obtenus de très bons résultats sur de gros projets, dans des domaines à priori peu réceptifs à ces pratiques et d'avoir été félicités par nos clients pour la tenue des jalons, la qualité des produits et notre transparence.
Pourtant nous traînons encore des problèmes de longue date (en terme d'années!) qui nous ralentissent, réduisent notre performance et attaquent notre moral.
Comment cela est-il possible alors que nous pratiquons un développement logiciel agile et Lean qui a lentement évolué pour s'adapter à notre domaine? Sommes-nous réellement sur la bonne voie?
Des aides extérieures et des recherches nous ont permis de prendre conscience que nous pratiquions un Lean scolaire. Cette pratique consiste à enrichir notre démarche issue de l'eXtreme-Programming et de Scrum avec des outils du Lean qui ont fait leurs preuves, sans pour autant assimiler le coeur du Lean.
Depuis, nous essayons d'aborder le Lean de la manière suivante:
- visualiser le production pour révéler les problèmes,
- réagir immédiatement,
- puis résoudre les problèmes un à un
- pour améliorer les pratiques.
Nos précédentes initiatives nous ont déjà conduit à "visualiser la production pour révéler les problèmes et réagir immédiatement". Nous continuons à peaufiner cette pratique. Par contre, nous essayons désormais de sérieusement nous attaquer au pan du Lean que nous avons trop négligé, c'est à dire résoudre les problèmes un à un pour améliorer les pratiques.
Attention, il ne s'agit pas là de la rétrospective d'itération ou de la collecte des obstacles par le ScrumMaster lors des réunions quotidiennes dans l'objectif d'aplanir la route devant l'équipe!
Il s'agit d'une discipline de tous les jours, pour tous, à tous les niveaux, qui consiste à avoir toujours un problème à résoudre. Ce problème doit être analysé, décortiqué et compris pour être éventuellement résolu si le retour sur investissement le justifie.
Pour les problèmes coriaces, la démarche est structurée. Par exemple pour nous, cela consiste à suivre les étapes suivantes:
- décrire le problème tel qu'on le perçoit;
- identifier et quantifier les impacts du problème pour notre client et pour notre organisation;
- décrire comment les choses devraient se dérouler, puis décrire comment elles se déroulent réellement. Décrire l'écart entre les deux.
- identifier les causes racines du problème et pondérer leur impact sur le problème;
- pour chaque cause racine, identifier des solutions candidates qui l'élimineraient;
- classifier les solutions candidates en fonction de leur coût de mise en oeuvre et de leur impact sur la résolution du problème;
- mettre en oeuvre les solutions par retour sur investissement décroissant jusqu'à ce que le retour sur investissement n'en vaille plus la peine;
- si elles ont été efficaces, standardiser les nouvelles pratiques mise en oeuvre;
- communiquer les leçons.
Cette discipline individuelle et d'équipe nous aide en ce moment à résoudre (entre autres) un problème que nous traînons depuis un an. Pour la première fois depuis longtemps, nous constatons une réelle amélioration du phénomène et ce pour un très faible investissement. Ceci nous ouvre de belles perspectives d'amélioration!
Le plus motivant à mon avis est que cette discipline est une école d'experts. En effet, puisqu'elle exige de passer par une profonde et complète compréhension des problèmes, elle pousse les acteurs de la démarche à développer leur expertise. Même si la résolution du problème n'est pas déclenchée par manque de retour sur investissement, les acteurs sauront ne pas commettre la même erreur à la prochaine occasion. Puisque tous sont concernés par cette discipline, tous sont amenés à développer leurs compétences.
Finalement, il se s'agit pas plus d'appliquer "un bon processus qui fait un bon produit" mais plutôt "d'appliquer une démarche qui développe des experts qui sauront mettre au point un bon processus qui fait un bon produit" (vous me suivez toujours?). L'effet premier recherché est l'implication et le développement des compétences. L'effet secondaire est l'amélioration des pratiques.
Avec cette nouvelle perspective, nous essayons de passer d'une démarche d'amélioration discontinue faite d'initiatives personnelles basées sur des intuitions à une démarche collective d'amélioration continue rigoureuse et disciplinée.
Cette discipline clarifie également le rôle des "leaders". Pour eux, il s'agit d'enseigner la démarche à leur équipe et à "challenger" leurs équipiers pour qu'ils analysent et résolvent leurs problèmes. Le "leader" est lui-même "challengé" par son leader/coach/manager/mentor, et ainsi de suite ...
Un prochain billet sera d'ailleurs consacré au rôle de leader, tel que décrit par Scrum, par l'eXtreme-Programming, par le Lean et tel que nous le pratiquons.
Merci encore pour l'aide extérieure!
