J’entend parfois « l’agile, c’est du Design To Cost ! »: je ne suis pas d’accord. Il y a une ressemblance peut être mais aussi une grosse différence entre les deux. Je m’explique.

 

Pourquoi fait-on des projets en agile ? Pour rendre les gens contents tout simplement, pour changer le monde à chaque fois qu’on livre un nouveau produit.

Un projet c’est avant tout un budget et une douleur. Sans budget pas de projet (on estime dans ce cas que la douleur n’est pas si importante), sans douleur pas de projet (on a un budget mais on n’est pas assez riche pour lancer des projets dont on n’a pas vraiment besoin).

Donc quand on lance un projet, c’est qu’on a des utilisateurs à rendre contents. Ces utilisateurs, ils faisaient comment avant qu’on se décide à lancer le projet ? Ils étaient embêtés et ils attendaient qu’on les satisfasse.

 

Souvent la question qu’on leur pose est : « Vous avez combien comme budget ? » (question 1)

Une autre question est tout simplement (ou tout bêtement) : « On doit rendre les utilisateurs contents comment ? Ils devront pouvoir faire quoi avec ce nouveau produit ? » (question 2)

 

Je constate souvent la question 1 : c’est du Design To Cost (un produit pour un coût donné, en français Conception à coût objectif).

La question 2 c’est la maximisation de valeur métier : c’est de l’agile.

 

Le mieux est de poser les deux questions ensembles, dans ce cas le budget se traduit par une simple contrainte budgétaire maximale à l’intérieur de laquelle on priorise.

La démarche agile est la suivante :

  1. on priorise par rapport à la valeur
  2. on ne consomme pas tout tout de suite.

 

Si on pense uniquement Design To Cost, on consomme tout ce budget tout de suite, en une fois, on fige donc tout un périmètre pour un budget. Est-ce que c’est agile ça ?

En gros on se dit « j’en voudrais pour 100 € ! », et on remplit pour 100 €.

L’important est de ne pas oublier la progression itérative dans la limite de ce budget maximum.

Entendez bien cette contrainte maximale : ne remplissez pas tout pour ce montant, sinon on aura tout consommé et donc tout figé, ce qui empêchera de prendre du feedback et donc de créer de la valeur.

 

Dans la question 1 on est efficient : on fige tout pour un montant, on essaie d’être le plus productif possible avec un budget donné, et donc on évacue tout ce qui n’est pas directement productif (l’innovation, l’exploration et le risque).

Dans la question 2 on est efficace : on veut découvrir ce qui va plaire à l’utilisateur : était ce bien ce produit qu’il fallait faire ?

 

Par exemple, je vous livre telle quelle une remarque récente de mon fils : « maman j’ai dépensé tout mon argent de poche ! ». Moi j’ai fait la tête, je ne partageais pas son enthousiasme.

Il est allé dans une librairie et a dépensé au mieux ses 35 €. L’exercice a consisté à prioriser les mangas entre celui qu’il veut absolument (catégorie 1), celui qu’il veut parce qu’il suit la série (catégorie 2), celui qu’il veut parce qu’on lui a conseillé (catégorie 3), celui qu’il veut pour tester (catégorie 4). Avec le budget qu’il avait il a sélectionné les mangas. Conclusion : il en a acheté 5 (2 de la catégorie 1, puis 1 de chaque catégorie).

La suite est évidente : 2 mangas ne lui plaisent pas tant que ça et il regrette de les avoir achetés.

Il était tellement content d’avoir dépensé tout son (mon !) argent !

 

Il a appris que si il avait dépensé moins (moins que le budget maximum) il aurait pu continuer à dépenser correctement son (mon !) argent.

En clair : il n’a pas minimisé son encours et il n’a pas livré souvent.

Il aurait dû se satisfaire de quelques mangas (3 ?), les lire et selon son évaluation améliorer ses décisions pour ses prochains achats.

Il y a un lien direct entre la taille de l’encours et la satisfaction utilisateur : si on minimise l’encours, on accélère le débit donc on livre souvent et donc on recueille des retours plus souvent et on améliore plus souvent.

 

Le Design To Cost maximise l’encours puisqu’on remplit tout pour un montant, maximiser la valeur c’est minimiser l’encours.

 

Maximiser la valeur c’est maximiser les chances d’être content grâce aux retours obtenus à chaque livraison.

Arrêtons de croire que l’on est obligé de tout faire ou de tout dépenser, on ne récoltera pas de retours dans ce cas ou on sera déçu.

 

Le budget maximum est un indicateur. Il traduit une sorte de vision du produit, un niveau de satisfaction à atteindre qui doit aider à prioriser.

 

Le Design To Cost n’est pas agile.

Le Design To Cost a une ressemblance avec l’agile car il commence une conversation : pourquoi ce budget maximum ? Il peut traduire la valeur que l’on veut produire et le ROI, c’est une vision qui doit être expliquée.

 

Développeur, Chef de projet et surtout Scrum Master pendant plusieurs années. J’ai connu un avant et un après l’agilité 🙂
Je crois profondément que ce sont les personnes et les interactions qui font réussir les projets, que les personnes sont importantes et qu’elles veulent bien faire leur travail.
Aujourd’hui Coach agile, j’accompagne les projets et les organisations dans leur transformation agile.

Citations :
« Il est préférable d’être à peu près juste que précisément faux. » (John Maynard Keynes)
« Je sais pourquoi tant de gens aiment couper du bois. C’est une activité où l’on voit tout de suite le résultat. » (Albert Einstein)
« Aucun plan ne survit au premier contact avec l’ennemi » (Von Moltke)
« Soyez insatiable soyez fou » (Steeve Jobs)