Le chemin et la destination

Recently a client asked me to come up with metrics to show that Agile is better than waterfall (to justify the Agile initiative).

I’ve been quite influenced by Simon Sinek’s Golden Circle recently (Why, How, What: http://www.amazon.com/Start-Why-Leaders-Inspire-Everyone and http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action ), so this time I tried to use his thinking and found the results pretty interesting.

Disclaimer: I think that measuring is an art/science (surveys, statistics, correlation, open/closed questions, leading/lagging metrics…), and I’m not expert, so this post is my current thinking on the topic.

I’m also not going to discuss : - why so many managers seem to like metrics for the sake of collecting metrics. - how poor is their knowledge on that matter.

First let me share a few other influences on that topic:

- This quote from Russel Ackoff:

“Managers who don’t know how to measure what they want settle for wanting what they can measure”.

- Another one from a great influencer, Mary Poppendieck:

"Instead of making sure that people are measured within their span of control it is more effective to measure people one level above their span of control .This is the best way to encourage teamwork, collaboration, and global, rather than local optimization”.

- The “Hawthorne effect” that says that measuring something might influence what you are measuring.

- A consequence is that I believe it is critical to always keep in mind “what behaviours could be created by measuring this or that?”, “Is there an incentive to game the metric?”. A famous example is code coverage where some developers write shitty tests just make sure that the commitement is met. Lines of code written is another good one.

- Mike Griffiths: desirable characteristics of a good metric

The Hawthorne Effect is positive

Simple, self generating

Relevant to the end goal

Ideally, leading, future focused

http://leadinganswers.typepad.com/leading_answers/2010/02/smart-metrics-slides.html

- Henrik Kniberg: what is a good metric?

Good behaviour

Good decisions

Forecasts

Fast feedback

See improvement

Easy to measure

http://blog.crisp.se/2012/05/11/henrikkniberg/metrics-what-to-measure-agila-matetal-i-praktiken

Ok, so no back to the topic of this post, how to use the Golden Circle to come up with metrics?

Why? Why is the company doing what she is doing? This is what really matters. It depends on the company values, vision and mission. How the company knows she achieves her vision?

o   I want my customers to be delighted: Customer / User satisfaction (net promoter score, surveys…)

o   I want my employees to be happy to work for such a company and I want them to stay with us: Employee satisfaction / turnover rate

o   I want to be a market leader within the next five years:  Market share

o   (could also be carbon emissions, number of kids vaccinated, numbers of …)

How? How does the company achieve the above?

o   We need faster ROI so that we can invest earlier: ROI

o   We want to be able to deliver as often as possible and pivot when needed: time to market (number of releases per year…)

o   We want our products to have as few defects as possible to make our customers happy (and if any, we want to fix them as fast as possible): Quality(defects trends and cycle time) 

What? What do we implement to achieve the above?

o   Deliver Value (we want to deliver the highest business value): EV?, EBV?

o   Predictability (we want our release planning to be accurate, we want to respect the SLAs: planned/actual velocity, control chart, burnup (also accepted features rate, sprint goal success rate)

o   Team stability (we know that performance can only be achieved with stable teams): Team structure

o   Quality: Defects trends, support calls (we want to find defects early to reduce the cost of fixing them)

o   Trust: Sponsor confidence, team satisfaction

o   Identify bottlenecks, limit WIP and create flow (we want to deliver as fast as possible): CFD, control chart outliers (cycle time, lead time, process efficiency: value added activities/total time) (also work items count)

We can also measure if the teams use the Agile and Lean practices but it has to be done in a shu ha ri fashion, not in a compliance way of thinking! High performing teams often adapt/tweak the core Agile practices. But at first I think it’s good practice to do things “by the book” for a few weeks to learn and then inspect and adapt :

o   Agile and Lean practices: Stand ups, retros, technical practices…

o   Lean Startup practices: Lean canvas…

This is a work in progress, but I found the exercise very interesting. It really helps to start from the why, and then derive the metrics from there. It also shows that each metric serves a different purpose.

I also noticed that depending on the organisation some metrics can be in different section. For instance employee satisfaction can be considered as part of the vision, but can also be just considered as a “how”.

I suggest that for each metric write you answer the following questions:

the reason: why do we want to implement it?

is it a leading or a lagging metric?

what kind of behaviour could it create?

Facilitated a 2hrs release retro for a client yesterday. Around 15 participants. It went really well, so I thought I would share the agenda.

- Preparation

Whiteboard or flip chart paper on walls. Markers. Post-it notes. Projector. Color dots. Snacks and drinks.

- Check in Draw an arrow with a scale from 1 to 10. Ask each participant to stick a color dot indicating her mood. Ask to say a few words to describe it. Ask to say “check in”.

- Welcome the participants, explain retro is at heart of Agile (inspect and adapt, reflect and learn, continuous improvement). Introduce yourself as the facilitator. Show Prime Directive and the agenda for the retro.

- First set of activities : reflect and learn about the past. #Mood time-line:

Draw a time-line. Ask the PM or SM to plot a few key highlights (ideally prepare it before). Ask participants to plot their mood for each sprints (or 2, but not too many). Ask them to talk while they draw. When everyone is done, you have many dots. Identify patterns. Ask them to comment. Encourage discussion. Draw the average line.

#Mad sad glad :

Draw 3 columns. Ask each participant to come up with 2/3 post-its along these 3 dimensions. Ask to write big and easy to read. When ready they stand-up, put their post-it, and talk. Encourage discussion. Group post-its as people put them.

- 2nd set of activities : the future. #Keep / start / stop / more of / less of. Draw 5 columns. Ask each participant to come up with 2/3 post-it on these 3 dimensions. When ready they stand-up, put their post-it, and talk. Encourage discussion. Group post-it as people put them. Remove duplicates.

#Dot voting :

Ask people to prioritize with dots (rule of thumb : number of dots per participants = 20% of total number of post-its). Identify top 3 or top 5 actions.

- Appreciations Ask participants to form a circle. If they want, this is the moment to express one (or two) appreciations about someone (not the whole team!). Not mandatory.

Thanks the participants for appreciating ppl. Round of applause!

- ROTI : did they enjoy the session and the facilitation? Project the definition of each level of ROTI.

- Check out. Use color dots again, but another color.

- Celebrate! (go for lunch, drinks, champagne …)

Quand on demande à l’IT de réaliser le projet dans des délais non raisonnables (la death march) parce que se poser la vraie question de la valeur du projet serait trop dérangeant...

DeMarco & Lister:

Stratégies pour dire non ou comment dire "no", "I can't" ou "I don't" en dit long sur le contrôle de nos vies.

Parfois on loupe des articles, et en effet je n’étais jamais tombé sur cette tentative de mise a jour du Manifesto par Kent Beck.

Je vous laisse lire l'article qui explique les raisons derrière les reformulations, je mets juste ici le résultat qui me semble très intéressant, révélant les nouveaux enjeux 13 ans après le manifeste:

Team vision and discipline over individuals and interactions (over processes and tools)

Validated learning over working software (over comprehensive documentation)

Customer discovery over customer collaboration (over contract negotiation)

C'est en substance ce que nous relate cet article de CFO: http://ww2.cfo.com/it-value/2014/02/readers-sound-talent-problem/

Je suis tout à fait d'accord: il est important que les profils techniques aient davantage de bagage pour comprendre les problématiques économiques et commerciales, et j'encourage les entreprises et les écoles à développer ces compétences (cours, "vis ma vie", mentoring...). 

Cependant, avec l’émergence de l’agilité et l'importance qu'elle donne aux notions de valeur et de ROI, je vois de plus en plus de "techos" se poser des questions sur l’économie d'un projet, la viabilité d'une fonctionnalité etc... 

J'aimerais en dire autant du marketing ou du commerce, qui me semblent encore avoir des difficultés à saisir l'aspect créatif et émergent de l'industrie logicielle et persistent à voir l'IT comme une chaîne de montage et prendre des engagements sans les consulter.

Comme on pouvait s'y attendre, l'article d'Uncle Bob dont je parlais l'autre jour a fait réagir la communauté. Un second billet vient compléter sa pensée:

http://blog.8thlight.com/uncle-bob/2014/02/23/OhForemanWhereArtThou.html

Je suis tombe il y a quelques jours sur ce billet qui propose d'illustrer des (anti)patterns et valeurs agiles via des illustrations d'un dessinateur danois qui propose ses oeuvres en licence Creative Commons: 

Uncle Bob s'est fendu il y a quelques jours d'un billet intitulé "Where is the foreman?" (foreman = chef d’équipe) ou il explique que les projets informatiques ont besoin d'un rôle de ce type. C'est la vigie des règles de bonne ingénierie, qui s'assure que les tests sont écrits et en particulier qui valide tous les commits.

Je cite, pour donner plus de details:

"Where is the foreman on our software projects? Where's the guy who makes sure all the tests are written. Where's the guy who makes sure that all the exceptions are caught. Where's the guy who makes sure all the errors are checked, and that references can't be null, and that variables are thread-safe? Where's the guy who makes sure that the programmers are pairing enough, talking enough, planning enough? [...]

What would the foreman do on software project? He'd do the same thing he does on a construction project. He'd make sure everything was done, done right, and done on time. He'd be the only one with commit rights. Everybody else would send him pull requests. He'd review each request in turn and reject those that didn't have sufficient test coverage, or that had dirty code, or bad variable names, or functions that were too long. He'd reject those that, in his opinion, did not meet the level of quality he demands for the project."

Ce billet m'a heurte car il me semble l'introduction de ce rôle est potentiellement déresponsabilisant. Il me semble en contradiction avec les notions d'engagement, d'auto-organisation, de responsabilisation chères aux équipes agiles. Autant je pense que les équipes ont besoin de leaders techniques, de mentors, de coaches capable d'instiller les bonnes pratiques, de s'asseoir a cote des développeurs ou testeurs moins expérimentés ou rigoureux et les accompagner, autant je trouve que ce rôle exonère les équipiers de leurs responsabilités. Cela me rappelle de laborieuses sessions de relecture de code avec des allers-retours multiples entre développeur et relecteur pour au final peu de résultats. Je pense que ce rôle doit être accompagne d'autres actions d'apprentissage, car l’idéal est qu'il ne soit pas nécessaire...

Mc Kinsey vient de publier un article sur le Lean incluant 2 exemples concrets d'elimination des etapes inutiles et d'amelioration de processus par le Lean:

C’est par une des histoires de la première saison de Rupture Douce que j’ai fait connaissance du Golden Circle de Simon Sinek.

Ce modèle nous invite à poser la question du pourquoi (l’intention) avant de réfléchir au comment puis au quoi, alors que nous raisonnons souvent de façon inverse.

La conférence TEDx ou Simon Sinek présente le Golden Circle est ci-dessous et je vous invite a la regarder. Un livre explique le modèle: Start With Why (pas lu).

Comme souvent dans ces présentations calibrées, je trouve que l’idée est desservie par certaines exagérations (un peu trop de “tous”, “aucun”, “jamais” a mon goût :-) ), néanmoins le message m’a parle. J’ai en particulier été frappe par quelques exemples de Simon pour montrer la différence entre un produit présente en partant du Pourquoi ou en partant du Quoi. Je constate que je reçois le message complètement différemment, l’un parle au rationnel, l’autre a l’émotionnel.

Comme le dit S. Sinek, les mots de Martin Luther King auraient-ils eus le même impact s’il avait dit “I have a plan” au lieu de “I have a dream”? 

En cela je rapproche ce modèle des théories sur la motivation, en particulier l’importance du sens, ce a quoi le Pourquoi répond à mon avis. Voir par exemple Drive de Daniel Pink.

Cette question du sens me semble aussi liée au besoin de leaders dans nos organisations, en lieu et place des managers gestionnaires. “Most corporations today are over managed and under led” (John P. Kotter).