Dis-moi ce que tu mesures

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…

4b8cccad263c78814bf64482f5f182bb?s=128

thomas lissajoux

December 19, 2018
Tweet

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
  3. None
  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
  11. None
  12. None
  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.
  36. None
  37. Unauthorized propagation prohibited. For internal use only.