TL; DR: Maximizing Utilization as a Relic from the Industrial Management Past
There are plenty of failure possibilities with Scrum. Since Scrum is an intentionally incomplete framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, what if the focus of the organization is on the maximizing utilization of the “workers” of the Scrum teams? What if the organization is still stuck deeply in industrial paradigm thinking, ignoring the benefits of slack time for the creation of value in the field of knowledge work?
Join me and delve into the effects of this outdated management principle in 60 seconds.
🗳 Update: Join the poll and its lively discussion on output and utilization focus in Agile.
🗞 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 Scrum Guide on Maximizing Utilization or Picking Work Items
Let’s refresh our memories regarding the organization of work for the Sprint:
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
Source: The Scrum Guide on the Scrum team.
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
No one else tells [the Developers] how to turn Product Backlog items into Increments of value.
Source: The Scrum Guide on the Sprint Planning.
Unsurprisingly, the Scrum Guide does not refer to the Scrum team’s organizing of its daily work besides pointing at the basic Scrum events and the need to refine the Product Backlog continuously. Otherwise, defining the team’s way of working is part of the Scrum team’s self-management obligation.
Technically, if the Scrum team chooses to do so, focusing on maximizing utilization is a valid option within its autonomy. However, it turns into something completely different once the management or the organization pursue this approach, imposing it onto the team.
The Effects of Maximizing Utilization While Ignoring Slack Time
The Problem: The organization imposes an output-oriented management approach onto its Scrum teams. The management sees more value in protecting the organization from “slacking” workers than supporting self-management at the Scrum team level. Moreover, “Slack time” — empowering a Scrum team to allocate a portion of its total capacity as it sees fit — is prohibited.
The Consequences: In the long run, the effect of pushing for a traditional, output-focused work organization is damaging team cohesion and achieving a high level of sustained performance in the long run:
- Everyone will focus on getting their tasks done. (Maximizing utilization is just a step away from stack ranking.)
- There will be less time to support teammates or to pair.
- The team will no longer address minor or less urgent issues promptly.
- Individual team members might become bottlenecks, which might seriously impede the flow within the team.
- Lastly, the ‘I am busy’ attitude will reduce the creation of a shared understanding among all team members, contribution to a deteriorating productivity in the long run.
The Solution: Overutilization will always push team members to focus on their individual output, thus reducing the team cohesion or the creation of a Scrum team in the first place. On the other side, empowering the Scrum team to utilize slack time will allow the Scrum team to act collaboratively and focus on the outcome while continuously improving its way of working, both at the collaboration and competence level.
Maximum Utilization, No Slack Time — Conclusion
When practicing Scrum seriously, the management concern of “slacking workers” and the resulting need to protect the organization from them is irrelevant. On the contrary, the management should empower Scrum teams to embrace self-management fully. Ultimately, those who are closest to a problem typically know best how to solve it.
Is your management choosing to protect the organization from “slacking workers?” Please share your learnings with us in the comments.
✋ Do Not Miss Out: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team
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.
📖 Maximizing Utilization, Ignoring Slack Time — Related Posts
Three Essential Agile Failure Patterns in 7:31 Minutes—Making Your Scrum Work #12
Three Wide-Spread Product Owner Failures in 6:09 Minutes—Making Your Scrum Work #5
Scrum First Principles — How to Elon Musk the Scrum Guide
When the Management Ignores Self-Management — Making Your Scrum Work #16
Download the Scrum Anti-Patterns Guide for free.
