Dean Leffingwell makes a similar point in his book "Agile Software Requirements: Lean requirements practices for teams, projects, and enterprises". He says that if the velocity metric is turned back on the team by managers, the team will do one of three things:
- Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
- Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
- Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.
- Practice continuous improvement to meet management objectives
- Sacrifice quality in the name of speed, or
- Sandbag estimates to create velocity buffers
And, they've got a point about sacrificing velocity if quality is the ultimate driver. But that puts 'better' as the nemesis of 'good', and puts in question the real advantage of agile that, in my mind, is delivering best value (which could be different from best quality, though I've not thought that all the way through).
And, you ask, what's my idea of best value? Simply put:
- Best value is the most valuable outcomes achievable, as judged by the customer, for the investment available from the sponsor
- Best value is the most bang for the buck, a best compromise of scope and quality in context of fixed investment and a critical need date.
By the way, I'm all about throughput. You really can't do a decent job as a agile manager unless you can benchmark for throughput and then hold teams accountable.
Are you on LinkedIn? Share this article with your network by clicking on the link.