1. "CONTRÔLEZ-VOUS CE
QUE VOUS MESUREZ ?
Jonathan Scher – Thomas Lissajoux
OCTO Technology

2. QUI ETES-VOUS ?
Quelle est la taille de votre projet ?
0-5 / 5-15 / 15-50 / +50

3. QUI ETES-VOUS ?
Depuis combien de temps, traitez vous vos
projets selon un mode agile ?
0 / moins de 2ans / moins de 5ans / plus de 5 ans

4. “YOU CAN’T CONTROL WHAT
YOU CAN’T MEASURE”
Controlling Software Projects:
Management, Measurement, and Estimation, Tom

5. QUE MESUREZ-VOUS ?
Vélocité ?
Cout global ?
Couverture de tests ?

6. 0 20 40 60 80 100
accélerer le time to market
intégrer le changement
améliorer la productivité
meilleur alignement IT/métier
améliorer la qualité
améliorer la visibilité
réduire le risque
simplifier le processus
réduire les couts
motiver les équipes
améliorer la maintenabilité
discipline technique
gérer des équipes distribuées
State of Agile Development Survey, Version One, 2011

7. 0 20 40 60 80 100
intégrer le changement 78
améliorer la qualité 62
motiver les équipes 61
livrer plus fréquemment 49
réduire les risques 45
respecter les délais 38
réduire le Time To Market 35
satisfaction des utilisateurs
augmenter la productivité
respecter les budgets
étude Scrum User Group France, 2009

9. -0- DELIVERY
Quand avez-vous livré une version de votre
produit aux clients finaux pour la dernière fois ?

10. -1- SATISFACTION
UTILISATEURS
Sur une échelle allant de 0 à
10, recommanderiez vous le produit à vos amis
ou à vos collègues de travail ?
0 Tout à1 improbable3
fait 2 4 5 6 7 Tout 8 fait probable 10
à 9 10
détracteurs passifs promoteurs
Reichheld, One Number You Need to
Grow, Harvard Business Review, Dec 2003 .

11. -0- DELIVERY
Quand avez-vous vu un client final utiliser votre
produit pour la dernière fois ?

12. "Many projects have proceeded without much control but managed to
produce wonderful products […] To my mind, the question that’s much more
important than how to control a software project is, why on earth are we
doing so many projects that deliver such marginal value? […]
Tom De Marco, Software Engineering: An Idea
Whose Time Has Come and Gone?, IEEE
Software, July/August 2009, pp. 96, 95

13. -2- VALEUR
Quel(s) type(s) de besoin ou capacité avez-vous
servi par cette livraison ?
– Amélioration du service
– Contraintes règlementaires ou légales
– Positionnement marché
– Réduction des couts
Combien cela aurait-il couté si vous n'aviez pas livré
(visites, conversions, $, opérationnels) ?
Reinertsen, The Principles of Product
Development Flow: Second Generation Lean
Product Development, Celeritas 2009.

14. -3- COUT
Combien a coutée votre dernière livraison ?
Quel est le cout total Build + Run de votre
produit ?

15. "Many projects have proceeded without much control but managed to
produce wonderful products […] To my mind, the question that’s much more
important than how to control a software project is, why on earth are we
doing so many projects that deliver such marginal value? …
Can I really be saying that it’s OK to run projects without control or with
relatively little control? Almost. I’m suggesting that first we need to select
projects where precise control won’t matter so much. Then we need to
reduce our expectations for exactly how much we’re going to be able to
control them, no matter how assiduously we apply ourselves to control."

16. -4- LEAD TIME
Quand le besoin correspondant à la dernière
livraison a-t-il été exprimé pour la première fois
?

17. -5- FRÉQUENCE
Quand avez-vous livré précédemment ?

18. -6- FAILURE DEMAND
Lors de votre dernière livraison, quel part ne
correspondait pas à des besoins, mais à des
corrections ?

19. -7- DEFECTS
Parmi ceux-ci, quelle part a été découverte en
production ?

20. WTF

21. -8- RISQUE
Pour livrer un produit satisfaisant, quelle
confiance avez-vous, sur une échelle allant de 0
à 10, dans votre capacité,
sur le plan métier / technique / humain ?

22. -9- SATISFACTION DE
L'EQUIPE
Sur une échelle allant de 0 à
10, recommanderiez vous de travailler sur ce
produit à vos amis ou à vos collègues de travail ?

23. -10- COMMENT ?
Quelles pratiques/patterns avez-vous mises en
œuvre pour obtenir ces résultats ?
Reinertsen, The Principles of Product
Development Flow: Second Generation Lean
Product Development, Celeritas 2009.

25. FAITES-VOUS ?
Du test continu ?
De l'intégration continue ?
De la livraison continue ?
De l'amélioration continue ?
Et les résultats sont visibles de tous ?

26. POURQUOI VOS MESURES
NE SERAIENT-ELLES PAS ?
-1- CONTINUES
-2- OUVERTES

27. OBSERVATOIRE AGILE
Une plateforme ouverte pour mesurer et
evaluer les performances IT
Permettre aux équipes de recueillir des données
factuelles pour évaluer leur performance et se
benchmarker.
Des mesures faciles, continues et ouvertes.

28. INSCRIVEZ-VOUS !
WWW.OBSERVATOIRE-
AGILE.COM