A Universal Truth
In the world of software development, one thing remains true no matter where you work.
There is always more to do than there is time available.
The Thing With Metrics
I get it. Metrics are sexy. They are cool. Quite often they are so easy to collect and then analyze. Impressive looking dashboards can be created. But therein lies the catch.
Just because you can doesn’t always mean you should.
Tell me how you will measure me, and then I will tell you how I will behave. If you measure me in an illogical way, don’t complain about illogical behavior.
Eli Goldratt
You Get What You Measure
The quote above by Eli Goldratt is one of my all time favorites. Stop and think about it and you will probably understand why.
In the work environment people are conditioned to perform based on how they are measured. This is most commonly reinforced by yearly individual performance evaluations. These evaluations are used to determine promotions, raises and often bonuses. People are very in tune with delivering what is being measured. Even if, in some cases, it makes little sense to do so.
Back when I started as a Scrum Master, years ago now, I collected data. A lot of data. I made very impressive graphs and charts from the data. I became an Excel guru. Being proud of my charts I showed them to management.
Because I had read blogs and books that indicated a Scrum Team’s Velocity should increase 10% per Sprint, my data measured that. And more. So management began tracking team velocity and penalizing teams if theirs didn’t increase sprint over sprint. This of course led to teams gaming their numbers. Hmmm.
Common Vanity Metrics
A couple of the most common vanity metrics for teams are:
- Velocity – Velocity is the average number of Story Points a team completes in a Sprint. It is probably the most misused and abused measure in Scrum. For more on that see this article: Beware The Agile Speed Trap
- Feature Count – Completing Features can be a very good thing, as long as you take care to ensure the Features represent a Desired Outcome or other unit of Value. Blinding focusing on pushing as many Features through the system, without ensuring they are of high value, can simply create a never ending treadmill of coding.
Discover What’s Important
I cannot tell you exactly what will be of value in your organization. I’m not there, I do not know your context. But there are a group of people who can tell you what is valuable – your current and potential customers. So meet with them, ask them questions. Discover what problems they face, what challenges them. Ask probing questions to discover better ways to solve their problems or impact their world.
A radical idea to some, but of great importance, is to have your team members also meet your customers. Take an XP approach and embed a customer within the development team!
With the correct product or service, you will make their lives much better. They will thank you for that with repeated business over and over.
Improving people’s lives is the reason you are in business, right?
If you measure and value output the team will surely deliver many outputs.
Just make sure what the team creates is of value to your customers.
Value Outcome delivery over simply more output.
Measure Only What Matters
Once you discover what is of value to your customers, focus on metrics that measure the impact your product has on them. How often do they use the software, what is your Net Promoter Score (NPS)? If you are a referral based business, how often do your customers refer others?
There are also other metrics that can be very useful to understand, such as:
- Cycle Time – how long does it take the team to deliver an item of value?
- Lead Time – how long does it take your organization to take an item “from concept to cash”?
- Defect count – what is the quality of your code base?
- Releases per calendar period – how often are you releasing new value?
- The time it takes to release, to production, a 1-line code change.
A great book to read on this subject is Accelerate.
Wrapping Up
For a more in-depth look at Agile Product Management and avoiding the Feature Factory trap, check out this excellent book by Melissa Perri: Escaping the Build Trap.
For a more in-depth look at actionable metrics, check out this great read from Daniel Vacanti: Actionable Agile Metrics for Predictability.
Leave the volume maximizers in the hair care aisle where they belong!
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
