App Dev Pros Have Been Using Metrics For The Wrong Reason: Control. It's Time To Use Metrics To Validate And Improve Delivery!

Within the modern applications era, regardless of whether new software applications are being developed and delivered for mobile, tablets, or the Web, the truly successful app-dev leaders will be those who focus on delivering constant value and incremental improvement to their business. That is a totally different perspective from “I need to keep control of my team’s productivity to make sure that we stick to our estimated costs, scope, and project dates.” Of course, the interest in cost is never going away, but app-dev leaders today have a great chance to enhance their conversation with executives and business stakeholders and add value to the conversation.

However, as the recent research I just published, Agile Metrics That Matter, proves, while some of the most advanced Agile teams do use new progress, quality, efficiency, and value/benefits metrics (these to a lesser degree), some software development industry luminaries have worked and are working on new methods to measure value in software development. But it’s still early days!

I’d like to summarize here some good old practices on establishing metrics that count together with some of the new findings of the research:

  • There is no common approach to metrics. One size does not fit all. The complexity of your context matters to succeed with metrics. Take a look at the simple Cynefin framework toolkit attached to the research to determine your complexity and get some suggestions on metrics that might work for that level of complexity. An example: it is possible to define and relate business value to software development if you are in the “simple” domain of our framework, but it’s impossible if you’re in the “complex” or “chaotic” domain (for exmaple, your primary goal in chaotic is to stabilize first, so a better metric would be “mean time to repair.”
  • Always define clear goals for your metrics. We’ve written about this many times. Once you know your complexity, you should then define the goals you need to measure and for whom. Use the goal question metric (GQM) method to do that. GQM is a simple, pragmatic approach that I’ve used many times with my clients. Clear goals and a proper context for metrics will help avoid teams and management misbehavior (see the figure below).

  • Agile teams remix old metrics with new ones. Cycle time, technical debt, velocity (on the same team), burndown/burnup charts, risk, and quality in terms of automation, but also defects in production and mean time to repair, are the raising stars of metrics. Satisfaction of both customers and teams are also tracked, although in different ways.

The time has come not only to define the right metrics, but to use them in the right way: to improve, fix and adapt your AD&D delivery process to increase value to the business!

BTW, this is the last report of the Agile and Lean playbook to go live. The playbook is now complete, and we will soon start updating and refreshing it. Your comments on what you would like to see us work on in the playbook are really welcome!

Comments

Similar thinking to my Seven Deadly Sins of Agile Measurement

Great post, Diego. I was struck at the parallels between this and my Seven Deadly Sins of Agile Measurement series. Your title is about using metrics to improve yourself rather than for control which is essentially sin #1 (http://www.rallydev.com/community/agile/seven-deadly-sins-agile-measurem...). Your reference to GQM is essentially ODIM which I talk about in Sin #5 (http://www.rallydev.com/community/agile/seven-deadly-sins-agile-measurem...)

Post new comment

If you have an account on Forrester.com, please login.

Or complete the information below to post a comment.

(Your name will appear next to your comment.)
(We will not display your email.)
Email me when:
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.