Years ago, I was told not to play golf, without taking some lessons first.  The reason: if you learn to play incorrectly,  then you will spend the rest of your life unlearning all the acquired bad habits. 

But if this axiom is true for golf, I wonder if it true for agile teams as well.  Have we taken on lot of bad habits, so now we have to spend considerable energy unlearning them?  All around us, we see Scrumbuts (for those practicing Scrum, at least).  And we see teams struggling to make progress and never achieving the maturity that puts them in a productive mode to deliver high quality, on time, customer delighting software.

Michael Dubakov (hat tip to Kane Mar for sharing the link) in his post – The Future of Agile Software Development outlines 3 essential problems that software delivery must solve – Do the Right Thing, Do Things Right, and Speed. When teams start on  agile projects, usually speed takes center stage. But, generally not “doing the right things right and fast.”

For many teams, the downward spiral starts when teams commit to stories that are not well understood, which have high degree of unknowns, or have disengaged business or product owners. The team in order to meet the timebox, will sacrifice doing right things (build what customers need) and without doing things right (quality).  And this starts to corrode any trust they have with their customers and stakeholders.  So now the team is doing wrong things wrong but, doing it fast.  And then eventually even the speed suffers.

So how do you refocus teams and help them unlearn behaviors that is directly affecting their agility and stunting their maturity?  Many times, this behavior is a direct result of ingrained company culture, which usually rewards speed, but nothing else.  As I was discussing this with some colleagues, I thought of at least few metrics that teams can use to reboot out of a Scrumbut rut.

A good place to start is usually to revisit and redefine story done criteria.  It is very hard to have a right conversation with product owners or other stakeholders, when teams can’t point to their done criteria and whether they are completing their stories to those standards.

Then next, track committed vs completed story points ratio. This will show how well the team is doing in estimating stories. If this ratio isn’t 1:1, you know that you are over-commiting, stories are not well understood, there are too many unknowns in your stories, or you have disengaged business or product owner.  When teams don’t deliver on their commitments, it starts corroding the goodwill and trust you have built with your stakeholders.  But if you hit 100% of your commitment, then at least the conversation can shift to improving team velocity.  This measure directly or indirectly helps you focus on speed.

The other thing to track is the ratio of new work (or features) against defects. This highlights how much of team’s time is going towards rework. And a corollary one is defects that you let loose in production – the technical debt you are adding to your future backlog.  Both these measures, should interest any product owner or stakeholder, since everyone will want to work on delivering new features and projects instead of correcting the things you didn’t do well in the first place.  Both of these metrics contribute to doing things right.

And lastly, you can gauge the level of customer satisfaction after every release or on a periodic basis. Though this is  a measure of the solution (software and infrastructure), in the end, that is what you are shooting for: having happy, delighted customers. You can design and deploy a simple survey monkey surveys, for example, to continually gage your user base. For external or end users, obtaining customer satisfaction might be lot more difficult and will require more planning and resources.  This is a measure of doing the right thing.

Now these measures, in and off itself wouldn’t get you too far.  Especially, if you have only embraced the scrum rituals, but none of the agile engineering practices or haven’t internalize agility concepts.  But, these metrics could provide a starting point to get your team refocused and work towards better results.

PS: As I have been procrastinating in writing this post for last 2 weeks, I got a tweet from Esther Derby today about her blog post – Metrics for agile.  Though our contexts might be slightly different, two of 4 items on this list are also on her’s.  Great post, as always, she says it so much better!

picture credit – kulichi on flickr