Agile and Metrics: friends or foes
Curse your sudden but inevitable betrayal
Hey, congrats! After a lot of time working in traditional, never ending, never delivering projects, you finally started working in an Agile team. You live by the principles of transparency, inspection and adaptation, you do retrospectives and see the product and team evolve as you go.
Inside the team there is healthy conflict, but it all comes to pieces when you have to deal with the rest of the organization (presumably not using Agile) or your clients (almost certainly not using Agile). You get to hear fantastic phrases like:
“Where’s your Gantt chart?”
“When will the product be ready?”
“What’s the project due date?”
“How much will it cost?”
And you feel betrayed! This is not what I signed up for!
But are your clients/stakeholders wrong?
A little spoiler: they are not.
Inspect. Adapt. What was that third thing again?
Deep down inside, at the core of project management, there is one single truth: you can propose the most unrealistic of plans, the craziest schedules, the riskiest approaches… as long as you keep everyone informed the whole time about progress. Yes, that includes failure progress as well. As long as everybody feels part of the decision-making process, you can always take wild guesses at cost, effort and dates, and adjust them along the way, as each problem appears. Sure, you’ll have tons of rework by adjusting all the planning artifacts every time, but you’ll keep everybody calm, because you are in control of the situation, and that’s how projects work.
At this point, all agilist are threatening to jump ship and start picketing, but my point here is to address something I believe we — as a community — are doing wrong.
We lack transparency.
Neat failure x chaotic innovation
Any project manager will confirm that more important than doing the right product is keeping all stakeholders informed. They will produce a never ending paper trail filled with charts and green/yellow/red lights, just so they can keep everybody calm.
That’s the key to why traditional methodologies have strived for so long. They maintain a sense of calm, poise and control even in the face of chaos and disaster.
Now take a peek at your agile team. Does it look like they give a rat’s ass about keeping people calm? On the contrary! If they are fueled-up agilists, they want people to be as engaged and fueled-up as they are. Calm does not apply.
And they are downright messy too! Mountains of post-its hanging from the walls, and mostly oral communication will make a stakeholder wonder what guarantees they are working in the product’s best interest.
Agile allergies
The one thing traditional project management does well is addressing the stakeholders’ expectations. You communicate time and again about how sinkable your ship is, and when it eventually sinks, nobody is caught off guard! Meanwhile, in Agile, we close ourselves in our teams, and focus on work metrics to improve the team’s performance for the team (if we have metrics at all), while advocating Agile is built on trust, so the stakeholders must get off our asses and start putting that effort into helping the PO achieve the best product possible.
But trust, my friends, is not built on words. It’s not built only on actions either. It’s build on communication before both those things.
Imagine you’re walking on the street and I violently push you into a store. You’d probably scream at me and call me names, right?
Now imagine the same scene, with one difference: before pushing you, I shout “look out”, and after I push you, I explain I saw someone with a gun coming your way. What would your reaction be?
We talk a lot about communication, but only towards the team. We lack focus in communicating progress and results to the organization, which is understandable… it’s probably an allergic reaction to the excessive waste of time in creating failure reports in the traditional project management approach.
If you talk the talk…
We constantly reinforce three pillars in Agile adoption, and we are awesome at inspecting and adapting, but when it comes to really living the pillar of transparency, my experience is hearing my colleagues say “making reports is not Agile”, or “this is a waste of time”. That always fascinated me, because I am very curious as to what story the numbers will tell about my work. I see value in valuable metrics. Of course, if your metrics are irrelevant, the problem is not with using metrics per se, but with the metrics you chose.
Above anything else, valuable metrics will give you the best of both worlds: your performance will be tangible. Your path clearer. You’ll be able to spot deviations based on more than subjectivity and feeling. And, as a bonus, you will be able to share that transparency with your stakeholders, managing expectation and making the process of building trust much easier.
Mentoring metrics
If you don’t have any metrics, believe the metrics you do have are not valuable, or that sharing them with your stakeholders will start WWIII, here’s a list of metrics that should help in almost any case and are relatively share-safe.
PBIs x Effort x Value
As a PO, it is paramount to have visibility of cost x aggregated value, and this is a very practical and straight-forward way of showing that.
Bonus points for knowing something went askew, because you’ll easily detect a sudden drop in effort and/or value.
Cumulative value x Sprint
This one allows you to constantly check if your product is still on the rise, and compare it to the product roadmap you have in mind.
Bonus points for showing stakeholders if a product is reaching maturity (the value per sprint decreases) and if you should invest in something more innovative.
Cycle time
This one allows you to constantly check if there are any hiccups with Sprint Backlog prioritization or if you are being insufficient in communicating with your team. Sudden spikes in cycle time show you either priority is changing mid-sprint — which is usually provoked by stakeholder interference, so that’s a good chance for you to address the consequences of unwelcome meddling while using this graph — , a poor business understanding or some kind of impediment. Whatever is causing those spikes, it is something you will want to check on.
Velocity
You can use this to help the team in improving estimates and, therefore, improve your release plan. Building an average of story points the team is able to absorb per sprint will help you ease your stakeholders' hearts as to feature delivery viability in cases time is especially sensitive.
On Product Index
This will show how much work is really being used to build the product. Low ratios if compared to Real Work are something to be checked on, and will usually reveal you have adjustments to make so your team is able to improve on-product performance.
I could go on, but I believe this is already a great Metrics Starter Kit. You will find several other ways of measuring, including the creation of new KPIs for yourself, but keep in mind that if you don’t see the value in measuring (regardless of the metrics you use), you will end up finding metrics something useless, boring and very far from an Agile mindset. So before you implement any of these, ask yourself: what would I like to know more about what I do? That’s what you should be measuring. All else is pointless.
