Spotting Scrum-But: When Good Intentions Go Astray
Learn to identify Scrum-but, an anti-pattern where teams claim to use Scrum but deviate from its core principles. Understand its signs and impact.
Many organizations adopt Scrum. They want the benefits: faster delivery, better products, happier teams. Often, what they end up with is not Scrum. It looks like Scrum on the surface, but it lacks the critical elements that make Scrum effective. This is called Scrum-but. It means 'we do Scrum, but...' and then comes an excuse for not following the framework. This anti-pattern undermines the very benefits Scrum promises. You need to recognize it to fix it.
The Core of Scrum-But
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. It relies on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. The three pillars of empiricism are transparency, inspection, and adaptation. Scrum-but happens when one or more of these pillars are weakened or ignored. The team might go through the motions of Scrum events, but without the underlying purpose, they become hollow rituals. This leads to a lack of genuine learning and improvement.
Common Scrum-But Manifestations
Scrum-but shows up in many ways. It often starts subtly. Teams might feel pressure to deliver faster, so they cut corners. Management might not understand Scrum's purpose, so they impose traditional project management practices. Here are some examples:
- The Daily Scrum is a status report to the Scrum Master or manager, not a planning session for the Developers.
- The Sprint Review is a demo to stakeholders, not a collaborative working session to inspect the Increment and adapt the Product Backlog.
- The Sprint Retrospective is skipped or superficial, with no actionable improvements identified or implemented.
- The Product Owner is merely an order taker, not empowered to manage the Product Backlog and maximize product value.
- Developers are not self-managing; tasks are assigned to them by someone outside the Development Team.
- There is no defined, usable Increment at the end of every Sprint.
- Sprints are not time-boxed; they extend until the work is 'done'.
Scrum Master as a Secretary or Project Manager
A common Scrum-but scenario involves the Scrum Master role. In true Scrum, the Scrum Master is a true leader, a servant leader. They coach the team, Product Owner, and organization in Scrum practices. They remove impediments and facilitate events. In Scrum-but, the Scrum Master might become a glorified secretary, scheduling meetings and taking notes, without challenging the team or organization to improve. Or they act as a traditional project manager, assigning tasks and tracking individual progress. This undermines the Developers' self-management and the Scrum Master's true accountability for Scrum's effectiveness.
Ignoring the Increment and Definition of Done
Scrum requires a 'Done' Increment at the end of every Sprint. This means a usable, potentially releasable product. If teams are consistently failing to produce a 'Done' Increment, or if their Definition of Done is so lax it hides significant unfinished work, that is Scrum-but. An Increment that is not truly 'Done' provides false transparency. It prevents proper inspection and adaptation, as the team and stakeholders are not seeing the true state of the product. This leads to accumulating technical debt and unpredictable delivery.
How to Spot It and What to Do
Spotting Scrum-but requires paying attention to how Scrum is practiced, not just that it is practiced. Ask if the three pillars of transparency, inspection, and adaptation are truly present. Are decisions based on empirical evidence? Is there psychological safety to raise issues? If the answer is no, you have Scrum-but. The solution is not to abandon Scrum, but to return to its fundamentals. Re-educate the team and stakeholders. Emphasize the 'why' behind each Scrum element. A strong Scrum Master is crucial here, guiding the team back to the framework's intent. True Scrum takes discipline and commitment, but the rewards are worth it.