This post was first published on www.meagile.com/article/velocity.
This is what I learnt from our most recent Agile meetup and I am apologising upfront for what Mark Twain once wrote “I didn't have time to write a short letter, so I wrote a long one instead.”
It often amazes me how people are emotionally tied to concepts and methodologies, often arguing because they cannot or will not let go of their own biases. How often do you find yourself hearing, but do not listening, solely waiting for that lull to jump in with your version of the truth?
With this in mind during last week’s meetup (http://www.meetup.com/Lean-and-Agile-ME-Dubai-Chapter/) we chose to hold a debate:
‘ is velocity a must have metric and if so why do so many scrum teams avoid it’
What follows are my learnings from this debate.
Let’s start with clearing up what we mean by ‘velocity’. According to Scrum Inc‘velocity’ is ‘…a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories…’
Borrowing from Steve Denning and Jeff Sutherland from their recent banter with HBR https://hbr.org/2016/05/embracing-agile, it’s important to remind ourselves that agile is more mindset than ‘my methodology is better than yours’!
Agile is a focus on delivering customer value not stakeholder value, and this is critical to understanding Agile and is required thinking before debating the pros and cons of velocity.
Back to Basics
What is the core purpose of using a metric such as velocity? Is it to prove to others how damn good we are? Is it hold others to account? Is it the stick to beat that team into doing the ‘right’ thing? Is it a hard measure of performance? Is it to measure value?!
The key appears to lie in the term most associated with metrics. KPI. The ‘K’ and the ‘P’ get all the limelight, they’re Cinderella’s ugly sisters, and as we know Cinderella, the ‘I’ is often forgotten. In the fairytale Cinderella is that one that brings happiness and joy. In my little world the key to successful understanding and deployment of a systematic approach to metrics that matter and growing a sustainable agile business is giving Cinderella the limelight!
The ‘I’ in ‘KPI’ matters most!
‘I’ stands for indicator!
Indicators cannot be a stick nor can they be the end all in a decision process. Why do we have indicators on our cars? Would you prefer a mountain road without those ‘S’s in red triangles warning us of the ‘danger ahead’? A great indicator guarantees success, it gives you insights to take smarter, faster decisions. If your velocity metric isn’t helping you win you need to first ask why before dismissing it.
A KPI is a metric and an indicator of performance and thus a tool that sheds light on something, I will go further and say a metric that matters is a catalyst for thinking and building insights to take smarter, faster decisions.
It was blatantly obvious from our meetup that the new economic reality that is VUCA (VUCA being Volatile, Uncertain, Complex, Ambiguous) often forces an unprepared or inexperienced management to all too often bypass the ‘I’ in KPI for the sake of faster (but not smarter) decision taking.
All too often we use VUCA as an excuse to stop collective thinking because ‘we have not time for this’. In the case of velocity as it is a team metric, the team must drive the discussion, not the manager. If management is old school, then they must evolve or die like the dodo and the team needs to take them out of the team or stop pretending to be agile. The symptoms are easy to spot. For example, ask yourself is velocity (or whatever metric) being looked on in isolation? If so, are the insights enough to take a sound decision on? Of course not, that’s why high performing teams use a balanced approach to KPIs.
The meetup spawned many stories of managers using velocity as a stick, or immature teams misusing the metric and countless examples of velocity being gamed. In all these cases, the team and the business ultimately failed.
Velocity on its own is useless.
In a balanced mix of metrics, Velocity can be a powerful catalyst and supports better smarter retrospectives. As we have seen, a manager who uses velocity to drive performance will fail, but the team that uses Velocity as part of a balanced view of their world will win.
A client who attended our meetup runs a facilities management business (that’s correct, teams outside IT are embracing agile). He spoke of how they are experimenting with velocity as a key metric within their balanced scorecard. He shared how they combine velocity with a team happiness metric, a customer satisfaction metric, a labour efficiency metric, a customer value metric and the obvious financial leading indicators such as cash flow forecasts, SLA performance and collections. For his company the objective in moving towards Scrum is to improve companywide performance through better communications and greater visibility of what needs to be done.
It’s often over looked but great agile teams have a balanced view of their world and will have, during the Sprint retrospectives, a stronger base for powerful collective intelligence debates. By taking better smarter decisions their performance continuously improves.
Here’s a great video from Intrafocus on why a balanced view of the world allows velocity et al to coexist together!
Some teams measured velocity and chose either Team Happiness or Labour Efficiency Ratio (Gross Margin/ Direct Labour Cost) as a counter measure. Others are bogged down arguing over Velocity vs Value. These are totally different, and need to be treated so. That’s why one sits with the Scrum Master and the other with the Product Owner. It’s better to include both for a more balanced view n’est pas?
The same can be said regarding time vs story points for estimating. Oh lord, how we could have argued this point for a millennium! What is evident, is that both work for different teams. Rather than using Planning Poker and story points, hours can be just as effective in measuring velocity.
They are easily understood whereas estimating without time “adds added complexity and therefore inefficiencies”. Teams estimating using time (hours) also set clear guidelines. Example: individual tasks will not be longer than 3 days; Never take the optimal time always take the average estimate of the task.
I also learnt that an agile mindset compliments the original Toyota PDCA (plan–do–check–adjust). If you prefer to use time rather than story points, then it’s OK to do so. Maybe at one of the retrospectives, after some powerful insights and debates the team may decide to try story units, then again it may not.
In conclusion
It does not matter if you use velocity or not, what matters is the team has an agile mindset. Why? Because this means it is focused on providing customer value and is committed to continuously questioning their performance.
I also validated my long standing belief that a team that relies on multiple metrics and a balanced perspective of their world will over time achieve greatness as it iteratively learns and matures.
Personally, I favour velocity as part of a balanced KPI scorecard because it continuously challenges me or my clients, who are mostly CEOs, to find ways to be better and smarter in delivering value to our clients.
Peter Drucker, once said ‘there is nothing so useless as doing efficiently that which should not be done at all’
He also said ‘…the purpose of business is to create a customer…’.
If you keep these two quotes to heart then you will be more likely to be on track to create an agile mindset within your organization, without it you ain’t going to sustain agile, nor continuously evolve and ultimately your customers will find someone else to employ to get their job done faster, better.
Are you looking to improve your company’s performance using Agile?
Would you like to find out more…?
Join me at our biweekly meetups in Dubai, share your experience, see what other teams are doing, or just come in and argue your preferred perspective on the rapidly evolving world that is Agile! Register for the next upcoming meetup at http://www.meetup.com/Lean-and-Agile-ME-Dubai-Chapter/
