AuthorSylvie Ponthus

On veut créer de la valeur

En général quand je dis ça comme ça, ça fait sourire :).

Les informaticiens doivent se dire « oui elle est gentille, elle n’invente rien, tout le monde veut créer de la valeur ».

Sauf que messieurs-dames les informaticiens, je ne sais pas pourquoi vous êtes les seuls à qui il faut expliquer ça. L’informaticien(ne), très poli, peut me demander « bon d’accord mais c’est quoi la valeur pour le client ? ».

La valeur est créée quand les clients sont contents.

Tout « bon » chef de projet vous le dira : le client ne sait pas ce qu’il veut. Et puisque le client ne sait pas ce qu’il veut, on va se protéger de son indécision et en lui faisant valider des spécifications.

D’ailleurs un « bon » chef de projet est celui qui se bat le mieux.

C’est donc une guerre, le développement logiciel.

On entend alors :

  • « monsieur le client, ce que vous demandez n’est pas du tout conforme avec la demande initiale » -> changement
  •  « monsieur le client ce n’est pas ce que nous avions convenu dans les spécifications » -> changement

Et qui dit changement dit facturation supplémentaire, et le chef de projet est content.
L’objectif avoué est donc de faire valider les spécifications et de ne pas produire de bugs en face de ces spécifications. Au passage si on a pu facturer cher les changements c’est super.

Et bien pas du tout.

En agile on dit bienvenue au changement, le changement est une opportunité, une chance d’arriver au bon produit.
La réaction normale au changement devrait être :

  • « super ! ça sera mieux comme ça ! »

 

Rendez vous compte que l’on demande aux clients de valider des spécifications. Le client ne sait pas faire ça ! Le client sait parler de son besoin, pas des spécifications.

Par exemple : prenons mon plombier, lors d’une visite de chantier de ma maison.
Il me demande « Madame, je les mets où les lavabos ? »
Moi je n’en sais rien du tout, et je le lui fais savoir.
Il m’emmène dans la salle de bain et me dit « Vous vivez comment là dedans ? »
Là c’est facile je sais répondre : « On aime bien avoir de la place sous la douche, pour mettre les affaires sèches à proximité. Puis on aime bien être tous devant le miroir pour prendre des photos du brossage de dents c’est rigolo. »
Pendant que je parle il déduit que la table supportant les 2 lavabos doit être à xxx cm du mur 1 et à xxx cm du mur 2.

Nous avons fait une conversation sur mon besoin, et de cette conversation a émergé la spécification.
Mon plombier n’est pas allé me chercher un « plombier spécifieur » pour écrire une spécification qu’il m’aurait faite valider, puis il aurait fait appel à un « plombier développeur» qui aurait réalisé le produit.
Celui qui réalise (le plombier) est le mieux à même de discuter pour savoir comment répondre à mon besoin : nous avons cette conversation ensemble, lui et moi.

 

Les informaticiens sont informaticiens. Les plombiers sont des plombiers. Les plombiers savent que leurs clients ne sont pas plombiers. Pourquoi les informaticiens ne savent ils pas que leurs clients ne sont pas informaticiens ?

J’entends trop souvent « le client ne sait pas ce qu’il veut » : c’est faux. C’est surtout qu’on ne parle pas le même langage, et qu’on ne pose pas les bonnes questions.
Au lieu de « monsieur le client, que voulez vous comme écran ? » , il faut demander « monsieur le client, comment doit on améliorer votre vie ? ».

On doit lui demander quelle valeur métier on doit créer, et avoir une conversation avec lui à ce sujet.

J’ai l’impression que nous autres les informaticiens nous sommes hautains, conscients de notre supériorité face à cet outil, l’informatique, qui est censé être connu de tous et dont nous sommes les experts (les magiciens).

Ou alors on ne se rend pas compte que notre métier dépasse le cadre strict de l’informatique, et que l’on doit chercher à comprendre quelle est la valeur à créer.

 

La question du comment est la question de la spécification.

Bien sûr il y a des spécifications en agile, ne commettez surtout JAMAIS l’erreur de les enlever.
En agile on raconte des histoires pour comprendre le besoin : en tant que xxx je veux xxx afin de xxx.

Afin de : c’est la question de la valeur à créer.

Raconter des histoires, avoir une conversation sur le besoin pour faire émerger la spécification, cela donne du sens aux développeurs. Cela leur permet de comprendre quelle valeur il faut créer et de ne pas se retrouver à la fin à entendre un client pas content dire « non ce n’est pas un changement, c’était implicite ».

L’objectif contractuel de respecter les spécifications doit être remplacé par des objectifs métiers : la valeur doit avoir été créée là, là et là.

 

La question est simplement : quel est votre besoin ? que voulez vous faire ? pourquoi devons nous faire ceci ?

L’objectif est de rendre les gens contents, de réaliser des applications parfaites où les utilisateurs ne passent pas leur temps à chercher la fonction x ou y. Le client doit pouvoir utiliser l’application comme quand j’utilise le lavabo : c’est mon bon produit.

 

On veut changer le monde : le rendre plus heureux pour tous. 

L’objectif est de changer la vie de nos utilisateurs. Avant ils n’avaient pas cette application : pourquoi doit on la faire ? Quelle valeur doit on créer cette fois ci ?

 

L’agile est une démarche disciplinée de création de valeur.

 

 

 

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)

L’agile ce n’est pas du Design To Cost

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)

Le MVP est figé ?

Le MVP (Minimum Viable Produit) n’est pas la liste des exigences obligatoires.

En agile le périmètre est variable, du coup certaines équipes essaient de mesurer cette variabilité pour trouver la part de périmètre non variable. Le MVP ce n’est pas ça.

Bon du coup c’est quoi le MVP ?

Si on pose « bêtement » la question à son client « monsieur le client quel est ton MVP ? » il aura tendance à répondre « tout ! » ou alors « beaucoup ! ».

Evidemment.

Le client en veut pour son argent. Il se dit qu’en demandant beaucoup il sera content.

Toujours cette notion de quantité. On a peur de manquer je ne vois que ça. Pourtant la quantité c’est moins bien que la qualité. Si on analyse la langue française, on peut dire que « beaucoup » est moins bien que « bien » et « beaucoup trop » c’est moche.

Parfois j’observe un duel entre Scrum Master et Product Owner :

« Le MVP est estimé à 80 % du Product Backlog, c’est beaucoup trop ! (dit le Scrum Master inquiet par la faible variabilité du périmètre)

  • Ok je descends à 70% (répond le Product Owner qui ne veut pas tout perdre)
  • C’est encore trop ! » (le Scrum Master est désespéré, décidément le projet ne sera pas agile le Product Owner n’est pas gentil)

La définition de Jeff Patton est claire : le MVP c’est la solution minimale qui crée de l’impact.

Eric Ries, le fondateur du Lean startup dit que le MVP est la version du nouveau produit qui permet à l’équipe de collecter le maximum d’apprentissage validé auprès des clients avec le moins d’effort.

Conclusion : chaque incrément de sprint est un MVP, c’est un produit opérationnel qui créé déjà de l’impact et qui permet d’inspecter et d’adapter.

 

Le MVP est ce qui nous aide à sélectionner les bonnes histoires utilisateurs pour ce sprint.

  • Si l’incrément produit est juste minimum, alors le produit est pourri, on n’en veut pas.  Du coup les utilisateurs ne nous donneront aucun feedback constructif, même si « on n’en veut pas » est déjà un important feedback 🙂
  • Si l’incrément produit est uniquement viable, alors c’est que le client est riche, il a surement payé beaucoup et aurait pu économiser. Du coup de nombreuses fonctionnalités ne seront pas utilisées, c’est ce que l’on veut ?
  • Le MVP est minimum ET viable, c’est ce qui nous permet de voir les choses autrement.

Un exemple : dans ma jolie maison je veux construire un mur.

Solution 1 : je construis la première rangée de brique, puis la deuxième, puis la troisième, … à la fin j’ai le plus joli mur du quartier. En plus comme j’ai tout fait en une fois, j’ai tout pensé en une fois, j’ai surement économisé du temps à me reposer tout le temps la question de ce que je veux, je sais que je veux un mur.

Solution 2 : pourquoi je fais ce mur ? je réponds 3 fois à cette question

  • itération 1 : pour clôturer mon jardin
  • itération 2 : pour me cacher des voisins, en tant que maman je veux être dans mon jardin sans être vue des voisins afin de lire tranquille
  • itération 3 pour être protégée, en tant que maman je veux être dans mon jardin à l’abri du soleil afin de lire sans être gênée

La preuve en image.

Personnellement je préfère le mur de la solution 2 à celui de la solution 1.

J’y ai peut-être passé plus de temps de réflexion, il m’a (peut-être) coûté plus cher et ce n’est même pas sûr. Combien coûte le mur du fond dont je n’aurai finalement jamais besoin ? Le grillage de la première itération, je peux le revendre sur le bon coin et l’arbre de l’itération 3 est peut-être moins cher que de fabriquer le mur du fond de l’itération 2.

Il est évident que le mur de la solution 2 c’est celui que je veux, et en construisant celui de la solution 1 je ne m’en serais pas rendue compte.

Et si on allait plus loin avec le MMP ?

Roman Pichler en parle là : http://www.romanpichler.com/blog/minimum-viable-product-and-minimal-marketable-product/

Question : Quand doit-on arrêter un projet agile ?

Réponse : quand les sprints apportent moins de valeur

Plus précisément quand un MVP ne contribue plus au MMP (Minimum Marketable Product).

Les MVP ont permis d’apprendre suffisamment pour que le produit aille sur le marché, alors c’est le moment d’arrêter les sprints.

Le MMP est la somme de tous les MVP, chaque MVP a validé un impact auprès des utilisateurs. Le MMP est le minimum pour aller sur le marché. Ce MMP n’aurait pas été obtenu en figeant dès le début du projet 80% du besoin, l’inspection et l’adaptation de tous les MVP ont construit ce MMP. Grâce à chaque MVP, le produit a gagné en feedbacks et a permis de réduire le gaspillage des fonctions initialement dites obligatoires.

Arrêtez de figer le MVP, le MVP c’est ce qui permet de construire le bon produit.

 

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)

Scrum ça marche ?

A la maison je constate un (léger) dysfonctionnement.

Des habits trainent, c’est moi qui m’occupe du linge (et c’est très long dès qu’on est une famille), les parents sont vite irrités quand c’est toujours les mêmes qui vident la poubelle, nettoient la table, vident le lave-vaisselle, … je suis sûre que je ne suis pas la seule et que beaucoup me comprennent.

J’ai deux formidables adolescents qui curieusement ne se jettent pas sur les tâches ménagères en rentrant le soir de l’école. De plus pas facile de convaincre Monsieur que j’en fais beaucoup plus que lui, et c’est un autre problème.

Le résultat que l’on obtient ? ça crie. Dès que l’un des deux parents de la maison sature dans cet univers de tâches ménagères.

Bon du coup j’ai fait simple.

J’ai peint la porte du garage avec de la peinture magnétique (10 couches pour les amateurs) et j’ai placé des post-it magnétiques.

J’ai exprimé ma vision : « on doit pouvoir vivre dans une maison propre sans crier »

L’avantage avec les ados c’est qu’on se lève à la même heure le week-end (environ 10h). J’ai dit « samedi matin dès qu’on est ensemble au petit déjeuner, on s’affecte les taches ».

Je ne dis pas que c’est un Sprint planning et je demande le plus calmement possible :

« Que faut-il faire pour que la maison soit propre ?

Je voyais tout le monde sur ses gardes, ils croyaient que j’allais encore les embêter. Je dois être une mère tyrannique je ne vois que ça.

  • Laver le sol !
  • Ranger les habits (ça c’est moi qui l’ai dit, ça m’irritait depuis longtemps déjà)
  • Sortir les poubelles !! (ça avait l’air génial comme c’était dit)
  • Passer l’aspirateur !!! (ça devenait euphorique, j’exagère à peine) »

Nous faisons collectivement la liste.

Je ne dis pas que c’est un Daily Scrum meeting et je demande :

« qui veut faire quoi ? »

Là ils sont tous un peu dubitatifs, ils doivent se dire qu’ils se sont fait avoir. Je répète :

« le premier qui veut faire quelque chose il prend un post it, il met son nom et c’est bon

  • Je prends les habits !!! (je n’ai pas compris pourquoi ma fille a sauté sur cette tâche, ça fait quand même des jours ou des semaines qu’ils ne sont pas rangés ces habits et ça n’avait pas l’air de la déranger du tout)
  • Moi les poubelles !!!  (mon fils a trouvé sa passion, je ne vois que ça) »

A la fin il restait quelques post-it non pris, j’ai ajouté « ça suffit vous croyez ?» et là c’est rigolo tout le monde se regarde du genre on verra qui craquera le premier et là mon fils « ok je plie le linge », moi ça m’a surpris je ne savais pas qu’il savait le faire.

 

Revue le dimanche soir : on se demande pourquoi certaines taches ne sont pas finies (« oui mais j’avais théâtre », « et bien dans ce cas ne dis pas que tu peux le faire »).

Et cela fait 3 mois que cela dure.

Les rétrospectives (non timeboxées) ont apporté les améliorations suivantes :

  • La couleur verte des post it permet d’identifier les taches « autre » comme appeler le docteur pour un rdv, …
  • On a ajouté le poids de chaque tache, en les chiffrant par analogie bien sur (pour info sortir les poubelles c’est aussi facile que ranger les habits)
  • On vérifie lors de l’affectation des taches que tout le monde a environ le même nombre de points (je n’en suis pas fière, ça manque encore de bienveillance)
  • Mon fils a reconnu que plier le linge c’était fastidieux, il rechigne à prendre la tache maintenant, il a insisté pour attribuer un gros poids à cette tache
  • Il y a une collaboration forte pour passer la serpillière, c’est plus compliqué que prévu et il y a de l’entraide

La preuve en image.

 

La satisfaction de la maison : chaque dimanche soir c’est fini et moi-même je n’ai pas de raison de crier puisque tout ce qui a été défini est fait.

L’objectif est commun, la réalisation est commune, la charge est partagée et l’avancement est visible de tous.

Je donne un peu l’impression d’être obsédée par mon travail, ce n’est pas grave. SCRUM ça marche et ça permet de faire émerger des compétences ?

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)

© 2019 Agile by Example

Theme by Anders NorénUp ↑