samedi 22 janvier 2011

RÉSOUDRE LES PROBLÈMES UN A UN POUR AMÉLIORER LES PRATIQUES

Lorsque nous abordions le Lean pour le mettre en pratique sur nos projets de développement, nous l'abordions selon les axes suivants:
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!

16 commentaires:

  1. Heureux retour, avec un post intéressant.

    RépondreSupprimer
  2. Emmanuel, le retour,
    Du vrai retour d'expérience et le gout du partage.
    MERCI!

    RépondreSupprimer
  3. Content de voir ce blog revivre !

    RépondreSupprimer
  4. Eh déconne pas Manu
    Continue ton beau blog
    Un billet de pondu
    C'est dix copains qui se r'loguent
    (d'après Renaud)

    Sur le fond du billet, je ne vois pas pourquoi ces problèmes seraient différents de ceux remontés au jour le jour et lors des rétrospectives.

    RépondreSupprimer
  5. Chouette .... de la (bonne) lecture :))
    Welcome back :)

    RépondreSupprimer
  6. Merci Emmanuel pour cet article.

    Pourrais tu cependant donner un exemple afin de plus expliciter la manière dont vous appréhender les problèmes?

    RépondreSupprimer
  7. Merci, et à bientôt pour un nouveau billet!

    RépondreSupprimer
  8. Je suis un peu d'accord avec la remarque de Claude : la démarche structurée pour les problèmes coriaces que tu décris n'est-elle pas celle que l'on emploie lors des rétrospectives ?

    RépondreSupprimer
  9. Félicitations, car cela demande beaucoup de rigueur et de professionnalisme. Cela me confirme (1) qu'il faut miser sur le gens et (2) chercher la perfection.

    RépondreSupprimer
  10. Claude & Sfui
    Ce que j'en pense:

    Une rétrospective mensuelle est de l'amélioration mensuelle, pas continue. Une rétrospective toutes les 2 semaines est de l'amélioration bi-mensuelle ... C'est TRES bien!
    Mais, les problèmes doivent-ils attendre la rétrospective pour être traités?

    Il n'est pas forcément optimal d'attendre la rétrospective pour traiter les problèmes et leur résolution. Je pense plutôt que c'est une bonne occasion pour communiquer sur les problèmes du moment et leur résolution. Par contre, je ne trouve pas efficace de chercher à y résoudre les problèmes.

    Scrum institutionnalise des moments pour identifier et résoudre les problèmes, et c'est TRES bien.

    Ceci dit, il me semble que ce que le Lean peut apporter (entre autres!) est une démarche CONTINUE et STRUCTURÉE de résolution de problème, élevée en discipline personnelle et d'équipe.

    Il ne s'agit pas d'une étape du processus qui arrive en fin d'itération, mais plutôt le coeur du process.

    RépondreSupprimer
  11. Il me semble que la rétrospective d'itération est un outil un peu léger pour devenir une organisation apprenante.
    Si tel est l'objectif, la résolution structurée des problèmes, élevée en discipline continue, personnelle et collective me semble plus efficace.

    RépondreSupprimer
  12. Est-ce à dire que tu ne fais plus de rétrospective ? (ou que tu en fais tous les jours…)

    RépondreSupprimer
  13. Bien sur que nous pratiquons encore la rétrospective.
    Nous pratiquons la rétrospective à plusieurs niveaux: en sous-équipe puis en équipe complète. Mais on ne peut y résoudre les problèmes. On ne peut que les remonter, lancer des chantiers de résolution de problème et faire le point sur les chantiers en cours.

    RépondreSupprimer
  14. Merci, un article intéressant comme toujours !

    RépondreSupprimer
  15. Pour moi la rétro est importante car elle ancre un moment fort de réflexion en équipe. Elle permet de synthétiser les sentiments/idées/remarques de chacun et de décider d'action à mener dans l'itération suivante (donc qu'on résoudra "en continue" dans l'itération, pas pendant la rétro). On est dans la logique PDCA : on planifie, on fait pendant les 2 semaines et à la rétro suivante on check et on act la réussite/l'échec, la nécessité de continuer ou d'aller plus loin.
    Après je suis entièrement d'accord que cela ne doit pas empêcher de résoudre les problèmes dès qu'on les identifient (si on ne le fait pas c'est qu'on a pas compris la philosophie recherchée). Mais la difficulté c'est qu'un vrai problème est souvent identifié par la somme des observations d'une équipe et qu'un "espace" pour se concentre là dessus est une vraie opportunité d'en prendre conscience.

    Pour la fréquence des rétros, dans mon expérience, au delà de 2 semaines (allez, sans doute jusqu'à 3 semaines ça doit pouvoir dans certains cas passer... ) on n'est plus dans un tempo continue...

    Sinon oui, Emmanuel, on compte tous sur toi pour continuer longtemps à partager tes idées :)

    RépondreSupprimer