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...
   

   View Slide

2. “You can’t control what
   you can’t measure”
   Controlling Software Projects:
   Management, Measurement and Estimation,
   Tom DeMarco
   

   View Slide

3. View Slide

4. 22 Questions
   

   View Slide

5. Quelle est la taille de votre
   équipe / département ?
   <5
   5-15
   15-30
   >30
   1
   

   View Slide

6. Quelle est votre expérience
   dans une approche agile ?
   <1 an
   1-2 ans
   2-5 ans
   >5 ans
   2
   

   View Slide

7. Que mesurez-vous ?
   Respect des deadlines
   Respect du périmètre
   Coût des projets
   Vélocité
   3
   

   View Slide

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
   

   View Slide

9. Quel était le délai par rapport
   à la précédente livraison ?
   < 1 semaine
   < 1 mois
   < 3 mois
   > 3 mois
   5
   

   View Slide

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
    

    View Slide

11. View Slide

12. View Slide

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
    

    View Slide

14. Quelle part ne correspondait
    pas à un besoin, mais à de
    l'attente / rework /
    corrections ?
    > 40%
    20-40%
    10-20%
    < 10%
    8
    

    View Slide

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
    

    View Slide

16. Combien cela aurait-il coûté
    par mois si vous n'aviez pas
    livré ?
    < 5 k€
    < 50 k€
    < 500 k€
    > 500 k€
    10
    

    View Slide

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
    

    View Slide

18. Sur une échelle de 0-10,
    vos utilisateurs
    recommanderaient-ils le
    produit à leurs collègues ?
    <=6
    7-8
    9-10
    11
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

22. Pour livrer un produit
    satisfaisant quelle confiance
    avez-vous sur le plan
    métier/tech/humain ?
    10
    8-9
    6-7
    < 5
    15
    

    View Slide

23. Recommanderiez-vous de
    travailler sur ce
    produit/équipe à vos
    collégues ?
    10
    8-9
    6-7
    < 5
    16
    

    View Slide

24. Pouvez-vous exprimer à votre
    patron une sous-estimation de
    50% ou votre désaccord en
    équipe ?
    Jamais
    Rarement
    Fréquemment
    Systématiquement
    17
    

    View Slide

25. Mon équipe améliore son
    fonctionnement/process
    (en explicitant ses hypothèses
    et modèles) ?
    Systématiquement
    Fréquemment
    Parfois
    Rarement
    18
    

    View Slide

26. Les membres de mon équipe
    s'entraident (pour progresser
    dans leurs domaines
    d'expertise respectifs) ?
    Systématiquement
    Fréquemment
    Parfois
    Rarement
    19
    

    View Slide

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
    

    View Slide

28. Quelles pratiques vous sont
    les plus utiles pour obtenir ces
    résultats ?
    21
    

    View Slide

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
    ...
    

    View Slide

30. Quelles principes sous-tendent
    le choix et l’application
    de ces pratiques ?
    22
    

    View Slide

31. 1. Leadtime
    2. Feedback
    3. Collaboration
    

    View Slide

32. Références
    

    View Slide

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.
    

    View Slide

34. Unauthorized propagation prohibited. For internal use only.
    

    View Slide

35. R.O.T.I
    Return on time invested
    From
    1 5
    To
    Unauthorized propagation prohibited. For internal use only.
    

    View Slide

36. View Slide

37. Unauthorized propagation prohibited. For internal use only.
    

    View Slide