Scrum-but: The Impostor Framework and How to Spot It
Scrum-but often masquerades as Scrum, but lacks its core principles and benefits. Learn to identify common signs of this anti-pattern to improve your team's effectiveness.
Many organizations claim to use Scrum. They might have Sprints, daily meetings, and even a Product Owner. But often, if you look closer, what they practice is not Scrum. It is Scrum-but. This term refers to teams or organizations that adopt some Scrum practices but miss the framework's fundamental principles. They say, "We do Scrum, but..." and then list a deviation that undermines its purpose. This post will help you recognize Scrum-but so you can address it and move towards true Scrum.
What is Scrum-but?
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It is purposefully incomplete. It defines a small number of accountabilities, events, and artifacts. The rules binding them together are simple. The empirical process control theory underpins Scrum. This means it relies on transparency, inspection, and adaptation. When a team or organization ignores these fundamental aspects, even if they use the Scrum terms, they are doing Scrum-but. They are not getting the benefits of Scrum, because they are not doing Scrum.
Signs of a Weak Product Owner
A common Scrum-but indicator is a Product Owner who does not embody their accountability. The Scrum Guide states the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are also accountable for effective Product Backlog management. If the Product Owner is merely a requirements gatherer, a proxy for stakeholders, or lacks the authority to make product decisions, this is a problem. The Developers will not have clear direction, and the product will suffer.
Missing or Dysfunctional Events
Scrum events exist to create regularity and to minimize the need for other meetings. They are opportunities for inspection and adaptation. When these events are skipped, rushed, or lack purpose, it signals Scrum-but. For example:
- Daily Scrum is a status report to a manager instead of a planning meeting for the Developers.
- Sprint Review is a demo for stakeholders without seeking feedback or adapting the Product Backlog.
- Sprint Retrospective is skipped entirely, or it is a blame session without concrete actions for improvement.
- Sprint Planning focuses only on picking items, not on defining a Sprint Goal or how to achieve it.
Each Scrum event serves a specific purpose. Ignoring or distorting these purposes removes the rhythm and feedback loops critical for empiricism.
Lack of Self-Managing Developers
Scrum Teams are self-managing. This means they internally decide who does what, when, and how. If managers assign tasks directly to Developers, dictate their work, or micromanage their process, the team is not self-managing. This removes autonomy and limits the team's ability to innovate and solve problems effectively. A Scrum Master's role is to foster an environment where self-management can flourish, not to act as a project manager. Developers must be empowered to manage their own work within the Sprint Goal.
Ignoring Transparency, Inspection, and Adaptation
The core of Scrum is empiricism. Transparency means the emergent process and work must be visible to those performing the work and those receiving the work. Inspection means checking the progress toward a Sprint Goal or Product Goal, and inspecting the artifacts to detect undesirable variances. Adaptation means adjusting the process or product as soon as possible. If a team consistently fails to make their work transparent, does not inspect their progress or process, or avoids adapting based on new information, they are not practicing Scrum. This can manifest as an out of date Product Backlog, unclear Definition of Done, or a reluctance to change direction even when evidence suggests it is needed.
Moving Beyond Scrum-but
Identifying Scrum-but is the first step. The goal is to move towards true Scrum. This requires commitment from the entire organization, not just the team. Focus on understanding the why behind each Scrum element. A strong Scrum Master and Product Owner are crucial. They must educate, coach, and protect the team. Embrace the values of commitment, focus, openness, respect, and courage. These values underpin the empirical pillars and help teams escape the Scrum-but trap. Real Scrum delivers real value.