Aller au delà des estimations, se concentrer sur l'essentiel

1. #NOESTIMATES
ALLER AU DELÀ DES ESTIMATIONS,
SE CONCENTRER SUR L’ESSENTIEL
DRAGOS DREPTATE - COACH
BENEXT
1.4.13.4.23.19
© Olgaç Bozalp

2. POSTULATS
Nous sommes mauvais à estimer.
L'environnement VUCA (volatile, incertain, complexe, ambigu) rends l’estimation
impossible.
Le processus d’estimation nous détournent de la création de valeur.
Estimation nécessite un descriptif très détaillé : fastidieux et source de gaspillage.
Le monde est devenu complexe. La création de valeur va venir de l’implication des
personnes et de la capacité à apprendre rapidement.

3. NOUS SOMMES MAUVAIS A ESTIMER

4. LE PIÈGE DU DÉTAIL
“Il s'avère que l'estimation est fractale. Plus
vous décomposez les exigences, plus vous
découvrirez de "contours". Cela signifie que
plus votre estimation est détaillée, plus le total
tendra vers l'infini, simplement en raison des
erreurs d'arrondi et des facteurs de peur que
nous multiplions en estimations à grain fin.”
— Dan North
https://dannorth.net/2009/07/01/the-perils-of-estimatio
n/
Total distance : 230,63 km

5. LA PARALYSIE D’ANALYSE
Alan Kelly - “Software Development is upside down” - http://www.allankelly.net/presentations/

7. POURQUOI ESTIMER ?
A quelle question on veut répondre ?
Quelle décision on veut prendre ?

8. POURQUOI ESTIMER ?
A quelle question on veut répondre ?
Quelle décision on veut prendre ?
“Est-ce rentable de développer cette fonctionnalité au regard du gain attendu ?”

9. L'ÉQUATION
Est-ce rentable de développer cette fonctionnalité au regard du gain attendu ?
ROI

10. L'ÉQUATION
Est-ce rentable de développer cette fonctionnalité au regard du gain attendu ?
ROI ⇔
GAIN
INVESTISSEMENT

11. L'ÉQUATION
Est-ce rentable de développer cette fonctionnalité au regard du gain attendu ?
ROI ⇔ ⇔
GAIN
INVESTISSEMENT
PROBLÈME
SOLUTION

12. L'ÉQUATION
Est-ce rentable de développer cette fonctionnalité au regard du gain attendu ?
ROI ⇔ ⇔ ⇔
GAIN
INVESTISSEMENT
PROBLÈME
SOLUTION
PRODUCT VISION,
LEAN CANVAS,
IMPACT MAPPING,
MVP,
STORY MAPPING

13. #NOESTIMATES
Nom complet : #NOESTIMATES - Focus on what matters
Délivrer régulièrement de petits morceaux qui font sens, prioriser par valeur,
l’estimation devient stérile (Nécessite la capacité métier à bien appréhender cette
approche).
Meilleur focus (donc meilleure productivité)
S’interroger plus sur la valeur générée que sur le coût
“Quand on suit le coût on génère des coûts, quand on suit la valeur, on génère de la
valeur”
-- Peter Drucker

14. #NOESTIMATES EN ACTION

15. EXTREME QUOTATION
© Pablo Pernot https://pablopernot.fr/2017/09/estimation-visuelle/

16. PROJECTION VS. ESTIMATION

17. PROJECTION VS. ESTIMATION

18. COST OF DELAY
“If you only quantify one thing, quantify the Cost of Delay.”
—Don Reinertsen (The Principles of Product Development Flow)
Le coût du retard est une façon de communiquer l'impact du
temps sur les résultats que nous espérons atteindre

19. COST OF DELAY
Vous disposez d’une seule équipe qui doit
réaliser 3 features.
Quelle est la meilleure priorisation d’un point de
vue économique ?
OPTIONS :
1 - Faire tout en parallèle A // B // C
2 - Les plus courtes d’abord A puis B puis C
3 - Les plus de valeur d’abord C puis B puis A
4 - Autre ?
Durée Valeur /
semaine
Feature A 3 semaines 3 k€
Feature B 4 semaines 8 k€
Feature C 6 semaines 9 k€

20. COST OF DELAY
Vous disposez d’une seule équipe qui doit
réaliser 3 features.
Quelle est la meilleure priorisation d’un point de
vue économique ?
OPTIONS :
Durée Valeur /
semaine
CD3
Feature A 3 semaines 3 k€ 1
Feature B 4 semaines 8 k€ 2
Feature C 6 semaines 9 k€ 1,5
1 - Faire tout en parallèle A // B // C
2 - Les plus courtes d’abord A puis B puis C
3 - Les plus de valeur d’abord C puis B puis A
4 - Autre Réponse : B puis C puis A
(*) CD3 : Cost of Delay Divided by Duration

21. COST OF DELAY
L’impact du profil de l’urgence sur le CoD

22. #NOESTIMATES - FOCUS ON WHAT MATTERS
Délivrer régulièrement de petits morceaux qui font sens, prioriser par valeur.
Découper juste à temps.
Observer la cadence.
Projeter plutôt qu’estimer : croire les données pas les estimations
S’interroger plus sur la valeur générée que sur le coût
Pas d’économie d’échelle dans le développement logiciel (science molle, complexe,
changeante). Faire de gros projets sur de longues durées : c’est l’inverse d’une économie d’
échelle, c’est une accentuation des coûts.
La valeur change selon la date de livraison.