Dis-moi ce que tu mesures

A temps, dans le budget, avec tout le périmètre. Voilà les critères habituels de succès d'un projet. Dans un fonctionnement Agile, ces mesures sont-elles encore pertinentes ?
Quelles autres mesures pourriez-vous utiliser ? Comment vérifiez-vous que vous avancez dans la bonne direction ?
A partir de là, quelles pratiques et traits culturels contribuent aux résultats que vous obtenez ?
Essayons d'élargir le regard que vous portez sur vos projets, vos équipes, vos pratiques…

Transcript

1. DIS-MOI CE QUE TU MESURES...
2. “You can’t control what you can’t measure” Controlling Software Projects: Management, Measurement and Estimation, Tom DeMarco
4. 22 Questions
5. Quelle est la taille de votre équipe / département ? <5 5-15 15-30 >30 1
6. Quelle est votre expérience dans une approche agile ? <1 an 1-2 ans 2-5 ans >5 ans 2
7. Que mesurez-vous ? Respect des deadlines Respect du périmètre Coût des projets Vélocité 3
8. Quand avez-vous livré (une version de) votre produit aux clients finaux pour la dernière fois ? < 1 jour < 1 semaine < 1 mois > 1 mois 4
9. Quel était le délai par rapport à la précédente livraison ? < 1 semaine < 1 mois < 3 mois > 3 mois 5
10. Quand ce besoin / idée / opportunité a-t-il été exprimé pour la première fois ? < 1 mois avant < 3 mois avant < 6 mois avant > 6 mois avant 6
13. Quel a été l'effort nécessaire pour cette livraison ? < 5 jours/homme < 1 équipe / 2 semaines 1 équipe / 3 mois > 1 équipe / 3 mois 7
14. Quelle part ne correspondait pas à un besoin, mais à de l'attente / rework / corrections ? > 40% 20-40% 10-20% < 10% 8
15. Quel type de besoin/capacité a été servi par cette livraison ? amélioration du service contraintes réglementaires positionnement marché réduction des coûts 9
16. Combien cela aurait-il coûté par mois si vous n'aviez pas livré ? < 5 k€ < 50 k€ < 500 k€ > 500 k€ 10
17. “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? “ DeMarco Reflects on 40 Years of Software Engineering Evolution, InfoQ
18. Sur une échelle de 0-10, vos utilisateurs recommanderaient-ils le produit à leurs collègues ? <=6 7-8 9-10 11
19. Quand avez-vous vu un utilisateur final utilisant votre produit pour la dernière fois ? < 1 semaine < 1 mois < 3 mois > 3 mois 12
20. Dans l'équipe tout le monde est d'accord sur les 2 prochaines priorités (pour ces utilisateurs) ? C'est évident On peut arriver à un consensus Une personne tranchera facilement Il faudra un arbitrage 13
21. Avez-vous la garantie d’avoir 2j d’affilé et 2h de travail ininterrompues chaque jour pour ça ? Assurément Difficile mais faisable Dans mes rêves 14
22. Pour livrer un produit satisfaisant quelle confiance avez-vous sur le plan métier/tech/humain ? 10 8-9 6-7 < 5 15
23. Recommanderiez-vous de travailler sur ce produit/équipe à vos collégues ? 10 8-9 6-7 < 5 16
24. Pouvez-vous exprimer à votre patron une sous-estimation de 50% ou votre désaccord en équipe ? Jamais Rarement Fréquemment Systématiquement 17
25. Mon équipe améliore son fonctionnement/process (en explicitant ses hypothèses et modèles) ? Systématiquement Fréquemment Parfois Rarement 18
26. Les membres de mon équipe s'entraident (pour progresser dans leurs domaines d'expertise respectifs) ? Systématiquement Fréquemment Parfois Rarement 19
27. Mon équipe se synchronise, coopère & partage généreusement avec d'autres équipes/départements ? Généreusement Parfois A minima Jamais 20
28. Quelles pratiques vous sont les plus utiles pour obtenir ces résultats ? 21
29. Quelles pratiques vous sont les + utiles pour obtenir ces résultats ? Equipe stable multidisciplinaire Client dédié / Product owner Colocalisation Iterations courtes Releases fréquentes Rythme soutenable Daily standup Planning d'itération Planning de release Planning poker / estimation d'équipe Démo Rétrospectives Tests unitaires Standards de code Integration continue Déploiement continu TDD+refactoring Revues de code BDD, Tres Amigos Tests d'acceptance automatisés Propriété commune du code Design émergent Event Storming / DDD Pair programming Mob Programming Agile/Lean UX Design Thinking / Design Sprint Storymapping Lean Startup Hypothesis-Driven Development Scrum SAFe, DaD, LeSS… Kanban Portfolio Kanban Management Visuel #NoEstimates #NoProjects Self-Selection / Dynamic Reteaming Coaching Management 3.O Core Protocols Clean Language AgendaShift Wardley Mapping Sociacracie / Holacracie Jira (ALM) Autres outils ...
30. Quelles principes sous-tendent le choix et l’application de ces pratiques ? 22
31. 1. Leadtime 2. Feedback 3. Collaboration
32. Références
33. Flux Fréquence, Leadtime Flow Efficiency ❏ The Busy Bee Paradox Hakan Forss. ❏ This is Lean Niklas Mödig. ❏ Low Flow Efficiency: Resist temptation to design out waste David J. Anderson. Valeur Cost of Delay ❏ The Principles of Product Development Flow: 2nd Gen Lean Product Development Don Reinertsen. ❏ Cost of Delay, Black Swan Farming Joshua Arnold. Client NPS, Failure Demand, UX ❏ One Number you Need to Grow, HBR Dec 2003 Fred Reichheld. ❏ Is Net Promoter Score the right measure to improve customer service? Vanguard Blog. Equipe 5 Dysfunctions, Psychological Safety ❏ The Five Dysfunctions of a Team Patrick Lencioni. ❏ Crystal Clear - 7 propriétés pour des projets couronnés de succès Alistair Cockburn. ❏ Of Course Psychological Safety…But How? John Cutler. ❏ Re:Work, Understand team effectiveness, Google. ❏ The Fearless Organization Amy Edmondson.
34. Unauthorized propagation prohibited. For internal use only.
35. R.O.T.I Return on time invested From 1 5 To Unauthorized propagation prohibited. For internal use only.
37. Unauthorized propagation prohibited. For internal use only.