Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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…

thomas lissajoux

December 19, 2018
Tweet

More Decks by thomas lissajoux

Other Decks in Business

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