Scrum: The Obsession With Commitment Matching Velocity
The fine line between risk mitigation and falling back into covering your butt.
Join the DZone community and get the full member experience.Join For Free
The team hasn’t met its commitments once. Not once.
The atmosphere was becoming thicker by the minute. The management was displeased with the progress of the project and was looking for answers, starring at a bunch of Jira charts, I prepared earlier. “How can we claim that we are working in Scrum mode, if the team is not sticking with the rules?”
Throughout the majority of projects I have been working on I could observe an obsession with burn-down charts and other Scrum metrics, mainly team commitments. And as a consequence, a side product of backlog grooming, estimation and sprint planning is elevated to the most important management indicator that “Agile” works: The team’s commitment is matching or outperforming its average velocity.
While I do see its value when it comes to risk mitigating—when can X probably be delivered to the customers—, the emphasis on its reporting value escapes me. It’s all playing safe again, corporate style, when it should be about delivering great software that is valuable, usable and feasible.
Why a Team’s Velocity Is Volatile Per Se
There are so many factors that make any team’s velocity volatile per se:
- New team members being onboard,
- Other team members leaving,
- Seniority levels,
- Working in unchartered territory,
- Working on legacy code, probably undocumented,
- Running into unexpected technical debt,
- Holiday & sick leave,
- Executive intervention,
— you get the idea. Actually, you would need to normalize a team’s performance each sprint to derive a value of at least some comparable value. (Which usually is not done.)
The Prime Purpose of Estimation and Grooming
And then there is grooming and estimation. Many of by-the-books Scrum practitioners tend to locate the value of these meetings in delivering an estimate on each user story. To my experience, that’s just a side effect of creating a shared understanding among the team members why they will be building a certain feature. (If you like to brush up your understanding of the Agile Manifesto, now would be a good time.)
In other words: A side figure is correlated to a volatile-by-nature figure of a minor inherent value to determine whether the team’s performance is on track and Agile is working.
Cooking the Agile Books
If that was case, the rational response of a team to this metrics driven “management style” would be to regularly under-commit and over-sell the effort at the same time. Which would leave sufficient buffer to handle the unexpected. It means de facto cooking the (agile) books to provide the middle management with a (perceived) feeling of being in control.
Does it sound waterfall-ish to you? It absolutely is, just with some Scrum sugar coating in top of it. (As I mentioned earlier, stripping Scrum off some unnecessary features—e.g. turning the product owner into a project manager—creates a viable Waterfall 2.0 framework.)
From my perspective, the obsession with “commitment matching velocity” is one of many reasons that lead to the “Peak Scrum” effect and contradicts a lot of what Agile stands for. It’s like introducing socialism through the backdoor: All plans are fulfilled and yet (probably) little or no value is created in the process.
Faux Metrics and the Way Out of This Dead-End
Instead of focusing on faux metrics, learn to appreciate real KPI that indicate that value is being created for customers and the company. And there are plenty of those available, just look for something supporting the successful delivery of valuable, feasible and usable software.
What is your take on “commitment matching velocity”—is it that the predominant metric in your organization? Please share with us in the comments.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.