Article complet: Devenez des chercheurs d'or agiles

Je viens de voir cette annonce de la dernière nouvelle de Clarke Ching, Rocks into Gold. Clarke Ching, souvenez-vous, j'ai parlé de lui à l'occasion de mon premier dojo agile où j'avais animé son exercice sur le task-switching, afin de sensibiliser les participants au coût élevé de cette façon de travailler.

J'aime assez ces auteurs qui présentent des sujets sérieux sous forme de romans. En fait c'est essentiellement Goldratt qui me vient à l'esprit, avec Le but : un processus de progrès permanent, Réussir n'est pas une question de chance, Critical Chain pour ceux que je connais, mais récemment j'ai découvert aussi The Gold Mine: A Novel of Lean Turnaround, par Freddy et Michel Balle (auteurs français, mais hélas leur livre n'existe qu'en anglais).

Rocks into Gold est une courte nouvelle, que vous pouvez acheter pour un prix modique, mais que vous pouvez aussi lire en ligne gratuitement, sous la forme de 238 (!) courts transparents (en anglais). La lecture prend de 20 à 40 minutes.

Si vous comptez la lire vous-même, ne lisez pas la suite de ce billet pour l'instant !

[Suite:]

L'idée essentielle de Rocks into Gold tourne autour des bénéfices de réaliser (et surtout LIVRER) les logiciels par incréments, au lieu d'attendre un an ou plus d'avoir un logiciel complet. Rien de très surprenant pour ceux qui sont déjà familiers avec les principes des méthodes agiles, me direz-vous. En effet, mais pour l'instant je vois peu de Product Owner Scrum capables d'assumer la LIVRAISON par incréments. Ils comprennent tous facilement la réalisation par incréments, mais peu se sentent capables d'aller sur le marché avec un produit qui lui paraît incomplet.

C'est pourtant là le coeur d'une méthode agile, à mon avis. Certes les équipes de développeurs doivent faire des progrès dans la maîtrise de leurs pratiques d'ingénierie, mais ces progrès ne valent pas grand chose tant que le logiciel n'est pas utilisé par des clients. Le Product Owner doit donc faire un gros effort de réflexion et d'analyse des besoins clients pour imaginer comment sortir son produit par incréments. Martin Fowler a donné un brillant (et extrême) exemple de cette démarche dans RollerSkateImplementation, où une entreprise doit mettre un site web pour certaines transactions financières. Le site web a été mis en place très rapidement sur le marché en trois étapes :

1. page statique décrivant le produit et indiquant un numéro de téléphone. Des intérimaires répondent au téléphone et saisissent les infos du client.
2. formulaire permettant au client de saisir ses informations. Mais le formulaire n'est pas connecté au reste du système. Il provoque la génération d'un fax, que les intérimaires resaisissent dans le système.
3. formulaire parfaitement intégré au reste du système.

Voilà un exemple qui paraît aberrant à nombre de Product owners, mais pourtant sur lequel ils devraient se pencher sérieusement !

En tout cas c'est l'idée "géniale" du personnage principal de Rocks into Gold, lequel parvient au cours de ses cogitations au graphique suivant (que vous pouvez découvrir sur le transparent 157) :

En vert c'est l'argent que coûte puis rapporte le projet s'il est livré par incréments, et en rouge la même chose s'il est livré en une seule fois. Le graphique montre également que le projet version verte rapporte de l'argent plus tôt, et que l'écart entre la courbe verte et la courbe rouge ne sera jamais compensé dans le temps ! Et bien sûr le projet version rouge creuse beaucoup plus le déficit dans les comptes de l'entreprise, et donc court le fort risque d'être annulé en ces temps de crise et de difficulté à emprunter (c'est le point de départ de Rocks into Gold).

Le graphique ci-dessus est a rapprocher de celui-ci, tirée de Why does Agile Software Development pay? :

Dans ce dernier graphique, la valeur totale générée par un projet livré par petits incréments est la surface en rouge PLUS la surface en bleu, tandis que la valeur générée par le même projet en version non incrémentale est la surface en bleu uniquement.

Voilà donc deux références qui peuvent vous être utiles si vous devez démontrer l'intérêt de méthodes agiles dans votre entreprise.

Enfin, j'ai noté les deux points suivants durant la lecture de la nouvelle :

• l'entreprise qui réalise le logiciel de l'histoire gagnait traditionnellement beaucoup d'argent en exploitant l'écart entre les besoins exprimés par le client et ses besoins réels (j'ai entendu dire que c'était une pratique courante dans les sociétés de service... les fameux avenants au contrat...). Dans une réalisation "agile" cette source d'argent va disparaître, ce qui est une source d'inquiétude. Clarke Ching mentionne que cette pratique est une forte source de friction entre l'entreprise et son client, et que faire disparaître cette friction sera plutôt un bénéfice mutuel.
• dans l'histoire c'est un développeur qui trouve l'idée "géniale". Cela me renforce dans la conviction acquise à la lecture des livres des Poppendieck que les équipes de développement agiles doivent avoir accès aux métriques financières de leurs projets. En effet nombre de décisions peuvent et doivent se prendre par les équipes, mais pour cela il faut avoir accès à des indicateurs pertinents. La mise à disposition de telles informations se heurte à beaucoup de difficultés en pratique, mais je retiens de Rocks into Gold que ce ne doit pas être un obstacle. En effet il est tout à fait possible d'estimer ces chiffres si difficiles à obtenir - c'est l'ordre de grandeur qui compte bien souvent pour la prise de décisions.

Et le titre ? Pourquoi ces rochers et l'or ? Ce sont des métaphores courantes dans la littérature Lean. Par exemple dans The Gold Mine: A Novel of Lean Turnaround, le principe est d'inspecter un processus de fabrication pour y détecter les "pépites d'or" qui y sont actuellement bloquées. Et le lac et les rochers servent à expliquer qu'en faisant baisser le niveau d'inventaires (au sens large) on fait apparaître des "rochers" qui bloquent l'écoulent du flux - voir The Gold Mine ou ce billet pour plus de détails.

Le mot de la fin : cherchons  les pépites d'or bloquées dans nos processus et nos manières de penser actuels !