Despite decades-long efforts of the whole agile community—books, blogs, conferences, webinars, videos, meetups; you name it—we are still confronted in many supposedly agile organizations with output-metric driven reporting systems. At the heart of these reporting systems, stuck in the industrial age when the management believed it needed to protect the organization from slacking workers, there is typically a performance metric: velocity.
In the hands of an experienced team, velocity might be useful team-internal metric. But, when combined with some managers’ wrong interpretation of commitment, it becomes a tool of oppression. So when did it all go so wrong?
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
The team hasn’t met its commitments once. Not once.
The atmosphere was becoming thicker by the minute. The management was displeased with the project’s progress and was looking for answers, starring at a bunch of Jira charts the Scrum Master prepared earlier. “How can we claim that we are practicing Scrum if the team is not sticking with the rules?”
Throughout most projects I have been working on, I could observe a management obsession with burn-down charts and other metrics, namely a team’s commitment. Consequently, the management interprets “commitment” as a list of work items the Scrum team promises to deliver during a Sprint. (Of course, the Developers only commit to achieving the Sprint Goal, not to a batch of specific work items.)
And as a consequence, the Developers’ forecast—in combination with their previous performance—is elevated to the most critical management indicator that “Agile” works: The team’s commitment is matching or outperforming its average velocity.
While I do see value in a projection regarding risk-mitigating—when can X probably be delivered to the customers—, the emphasis on its reporting value escapes me, though. It’s all playing safe again, corporate style when it should be about delivering excellent products that are valuable, usable, and feasible. It is no longer about maximizing the value of the team’s work in a complex environment with all its uncertainties. Instead, it is about disciplining the workforce to make accurate predictions. (Which isn’t possible in complex environments anyway.)
Cannot see the form?
Please click here
There are so many factors that make any team’s velocity volatile per se:
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 given the complexity of the underlying model.)
And then, there is Product Backlog refinement and estimation. Many by-the-books Scrum practitioners tend to locate the value of these meetings in delivering an estimate on each Product Backlog item. However, in my experience, an estimate is just a side effect of the ensuing conversation. The refinement's purpose is to create a shared understanding among the Scrum team members on the why, the what, and the how.
The result of this is plain wrong: In a distortion of reality, a volatile-by-nature figure of minor inherent value is compounded by a misinterpretation of the Scrum Guide to determine whether the team’s performance is on track and Agile is working.
In such a scenario, the rational response of a Scrum 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. (Read more: The Hawthorne Effect.)
Does it sound waterfall-ish to you? It is, just with some Scrum sugar coating on top of it. (As I mentioned earlier, stripping Scrum off some “unnecessary” features, such as turning the Product Owner into a proxy or a scribe, creates a kind of 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 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.
Instead of focusing on faux metrics, learn to appreciate actual KPIs that indicate value creation 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. The Evidence-Based Management Guide features plenty of examples of such metrics.
What is your take on “commitment matching velocity?” Is it probably the predominant metric in your organization? Please share with us in the comments.
Estimates Are Useful, Just Ditch the Numbers
Agile Failure Patterns In Organizations
Hiring: 54 Scrum Master Interview Questions To Avoid Agile Imposters
Cargo Cult Agile: The ‘State Of Agile’ Checklist For Your Organization
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
If you like to learn more about velocity and commitment, consider attending Stefan’s Professional Scrum Master classes.
TL; DR: Introducing the “Anti-Patterns Canvas” Join me in developing the Anti-Patterns Canvas, a dynamic…
TL; DR: Technical Product Ownership Dive deep into the benefits—or the lack thereof—of the technical…
TL; DR: System-Level Scrum Stakeholder Anti-Patterns Learn how outdated organizational structures manifest themselves in system-level…