Quelques années après avoir construit à partir d’une page blanche une banque à distance, j’ai découvert la conduite de projet agile. Quel soulagement ! Il était donc possible d’interagir avec les développeurs sans devoir décrire en 1 000 pages la solution exacte que l’on souhaitait. Exercice d’autant plus difficile que les souhaits sont assez flous lorsque vous êtes pionnière dans le domaine.

Ceci dit, mon point de vue est d’abord lean, avec la supervision de 10 000 jours, en 10 ans, de coaching en Lean et informatique. Mes contacts avec la communauté agile sont fréquents, j’en aime beaucoup l’esprit. J’ai eu notamment la chance de travailler avec @RegisMedina, de faire intervenir @KentBeck et @JeffSutherland dans certaines conférences, et enfin de partager sur le terrain le lean avec des agilistes de haut niveau.

Voici donc trois pratiques que le lean peut apporter à l’agile :

1. Soyez agiles dans vos rétrospectives !

2 semaines, c’est bien trop lent. Si quelque chose ne fonctionne pas comme prévu maintenant, maintenant est aussi le bon moment pour en chercher les causes. Dans deux semaines, on aura oublié le point, ou le détail important, et il sera impossible de se souvenir des conditions dans lesquelles le problème est apparu.

Un exemple tout simple : la courbe réelle du burn down chart s’écarte de la droite tracée. En Lean IT, on chercherait à comprendre tout de suite pourquoi. Environnement de travail insuffisant, tests qui ne passent pas, story moins compréhensible que prévue, estimation de la charge erronée, modèle de données confus ? Tout est possible en matière de cause. Mais si vous ne tracez pas maintenant ce qui s’est passé, vous ne pourrez réfléchir que sur de vagues souvenirs, sable bien inconsistant pour conduire une vraie action d’amélioration.

2. Les pieds et les yeux, les quatre outils au cœur du Lean

Go and see, aller et voir, gemba, genchi genbutsu : on vous le dit dans toutes les langues, faire du Lean c’est d’abord aller à la vraie place, avec les vraies personnes et sur les vrais produits. Et c’est vrai aussi en Lean IT.

Aller et voir quoi ? Le client, bien sûr. Ce sujet est toujours embarrassant pour un coach Lean qui échange avec un agiliste :

« – Comment sais-tu ce qui va rendre service au client / à l’utilisateur ?

– On a un product owner qui s’en charge ». Point.

Quelle drôle d’idée ! Ca ne coute rien, ou trois fois rien, d’aller sur le terrain, on crée des contacts agréables avec des gens ravis de vous accueillir et c’est tellement éclairant. Je me souviens de ce geek (aujourd’hui chez Google quand même !) que j’avais emmené faire un tour dans un back office. 7 mn après s’être assis à côté de l’un des collaborateurs, je l’ai vu devenir mal à son aise et à la fin de l’observation, il était blanc. Il venait de comprendre pourquoi personne n’aime l’informatique…

Je me souviens de cet agiliste travaillant chez un grand du e-commerce et qui n’avait jamais acheté un produit de son entreprise. Nous avons fait l’exercice ensemble et il n’a plus jamais programmé de la même façon.

Je me souviens encore de l’équipe agile de cet éditeur qui me présentait les merveilles prévues dans la prochaine version. J’étais là parce que les clients fuyaient, avec des conséquences difficiles en termes de viabilité de l’entreprise (quel avenir quand les clients partent et/ou n’achètent pas les nouvelles versions ?). Nous avons lu ensemble un paquet de réclamations client pour voir en quoi ces fonctionnalités très chouettes allaient permettre de calmer au moins un client. Et puis on a revu le backlog… Moins glamour mais quel impact !

Etc.

Alors, allez-y : mettez les chaussures de vos clients et ouvrez les yeux. Que voyez-vous ?

3. Quality First

Il y a un mantra guideline simple pour ordonnancer l’amélioration avec le Lean management : « quality first, security always ». Quel sens aurait une organisation qui essaierait de sortir de plus en plus vite des produits de mauvaise qualité, que l’on jette à la poubelle ? Donc, en Lean IT, nous sommes quality first. Et security always parce qu’on ne va pas au travail pour en ressortir abimé.

Chez les agilistes, je le sais, il y a le TDD. Je garde un souvenir très fort d’une visite dans une équipe Thalès dans laquelle les tests étaient tournés en continu et les développeurs s’arrêtaient au 1^er défaut.

Si vous n’en êtes pas là, avez-vous une colonne « bac rouge » dans votre tableau visuel ? C’est déjà un bon début.

On met dans le bac rouge ce qui n’est pas conforme ou ambigu. Puis on applique la démarche décrite au point 1 : chercher à comprendre comment on en est arrivé là, pour que ça (quoi que cela veuille dire) n’arrive plus.

Ca développe le jugement (pièce conforme / pièce non conforme), ça crée de la solidarité (on réfléchit au bac rouge ensemble et ceux qui savent s’y prendre font progresser les autres) et c’est plus efficace (on limite la production de bug et de correction de bug).

En conclusion

Le Lean, c’est d’abord un système de management qui favorise la réflexion individuelle et collective. Le coach Lean n’apporte jamais de préconisation, juste des questions ou un exercice qui conduisent à regarder son travail avec un point de vue un peu différent. A chacun d’accepter ou non l’exercice et de changer ou non sa pratique quotidienne.

J’en propose ici trois, très adaptés à une pratique agile. Je suis prête à partager vos étonnements si vous passez à l’acte.

Et rassurez-vous : toutes les actions que vous pourriez être amené à conduire sont absolument agile friendly.