Scrum Anti-Patterns: Dark Scrum, Zombie Scrum and Mini-Waterfall Sprints
What Scrum anti-patterns have in common is that empiricism is not working while the events and artifacts are in place. The post brings Dark Scrum, Zombie Scrum, ScrumBut, Sprint 0, hardening sprints, mini-waterfall and carry-over Sprints into one table of symptom, root cause, what the Guide says and first step; it shows that most stem from large items and a weak Definition of Done, and gives teams a 10-question self-check.
Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. For Dark Scrum the source is Ron Jeffries' 2016 article; for Zombie Scrum, zombiescrum.org and "The Zombie Scrum Survival Guide".
Guess First
Bookstore has a second team that builds campaign pages, and it "does Scrum". All the events are on its calendar. But over the last five Sprints: the first week of each Sprint goes to analysis and design, coding starts at the beginning of the second week, testing is squeezed into the last two days, and on average four items carry over to the next Sprint every time. In the Daily Scrum a director collects status from the team. No stakeholder comes to the Review; the team shows the Increment to itself. Before each release there is a "stabilization Sprint".
How many different anti-patterns are in this picture? And which one could be the root cause of the others? Write down your guess; the table in the middle of the post gives the symptom, root cause and first step for each.
Doing the Form and Skipping the Theory
The Guide's end note reads like a summary of this post: implementing only parts of Scrum is possible, but the result is not Scrum. That is what anti-patterns have in common: the events, artifacts and titles are in place, but one or more of the three pillars of empiricism is not working. Without transparency inspection is misleading, without inspection adaptation is random, and without adaptation the whole rhythm is a ritual.
The anti-patterns in this post are not independent. Mini-waterfall Sprints breed carry-over Sprints, carry-over Sprints breed hardening sprints, and hardening sprints breed Reviews without an Increment. That is why each one needs a look at the root cause, not just the symptom.
Dark Scrum
In his 2016 article "Dark Scrum", Ron Jeffries gave this name to using Scrum's forms to exert power over a team. The picture he describes is familiar: managers know their old roles but not their new roles in Scrum; the Daily Scrum turns into a status and command meeting; work is dictated in Sprint Planning and a developer who says "this is impossible" is called lazy; the Review becomes the place where the team's "failure" is shown; as pressure rises, testing and design are cut, quality drops, and that brings more pressure. Jeffries stresses that this often comes not from bad intent but from well-meaning people who have not learned their new roles.
The way out Jeffries proposes starts with the Developers: delivering tested, integrated, working software every Sprint, and learning the technical practices that make it possible. When working software is visible, fear drops and the conversation moves from "why is this so slow?" to "with the pace we have, what should we do first?". That is one reason the practices in the previous post matter so much for Scrum.
Zombie Scrum
Christiaan Verwijs, Johannes Schartau and Barry Overeem's book "The Zombie Scrum Survival Guide" and the zombiescrum.org site describe this as something that looks like Scrum from a distance but is not Scrum on closer inspection. In Dark Scrum there is pressure; in Zombie Scrum nobody feels anything: the events happen, nobody objects, nobody gets excited, nothing changes.
The four areas the authors use for diagnosis map onto the essence of the Guide: shipping fast (nothing works at the end of the Sprint, and the team does not see why speed reduces risk), building what stakeholders need (stakeholders never talk to the team), improving continuously (nothing comes out of the Retrospective) and self-organization (the team has no say over its own work). The site also offers a free survey teams can use to assess themselves. Bookstore's campaign team is weak in three of the four areas: no delivery, no stakeholders, no improvement.
ScrumBut, Sprint 0 and the Hardening Sprint
ScrumBut is a formula popularized by Scrum.org: the sentence "We use Scrum, but ..." followed by a reason and a workaround. "We do Retrospectives, but once a month because there's no time." "We have a Definition of Done, but this Sprint was urgent so we left the tests for later." Each ScrumBut looks innocent on its own; but each one hides, at exactly that point, a problem Scrum would make visible. The real reason for holding Retrospectives less often is usually that Retrospectives produce no results; the fix is not skipping them but making them produce results.
Sprint 0 is a Sprint held before the first Sprint for "infrastructure, architecture and backlog preparation", producing no Increment. It is not in the Guide and contradicts the Guide's sentence that the Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Even when infrastructure preparation is genuinely needed, the first Sprint can aim for a small piece that works end to end: Bookstore's first Sprint Goal was the return of a single-item order, and the pipeline was built in that Sprint, for that work.
We saw the hardening sprint in the sixth post of the series: a Sprint that produces no features, used to clear the testing, integration and stabilization work that piles up when the Definition of Done is weak. The campaign team's "stabilization Sprint" is the same thing under another name.
Mini-Waterfall Sprints and Carry-Over Sprints
A mini-waterfall squeezes the phases of waterfall into the Sprint: analysis in the first days, coding in the middle, testing in the last days. On the campaign team's board it shows plainly: the Done column is empty for the first eight days of the Sprint and tries to fill up in the last two. Every bug found in testing carries over to the next Sprint because there is no time left to fix it.
The root cause usually sits in two places. The first is item size: if an item takes the whole Sprint, analysis, coding and testing have to run in sequence inside that item. The second is team structure: if the person testing is not a Developer but sits in a separate team, work can only reach them "once the code is done". The first step is splitting items into pieces that can be Done in a day or two and bringing testing into the item from the first day. A Daily Scrum that walks the board from right to left helps reverse the order too.
Constantly carrying over is mostly a consequence of this structure. Four items carrying over every Sprint shows that the forecast systematically exceeds capacity; but the real loss is not in the number but in the meaning: when carried-over items move "automatically" to the next Sprint, the Product Owner's ordering decision is taken out of the loop. The Guide's rule is the same here: an item that is not Done returns to the Product Backlog.
Symptom, Root Cause, Guide, First Step
The campaign team's table, for each anti-pattern:
| Anti-pattern | Symptom | Root cause | What the Guide says | First step |
|---|---|---|---|---|
| Dark Scrum | A manager collects status in the Daily Scrum, work is dictated | Managers keep their old roles; working software is not visible | The Daily Scrum is the Developers' event; the "how" is solely at the Developers' discretion | Show a truly working Increment every Sprint; invite the manager to the Review |
| Zombie Scrum | Events happen, nothing changes, no stakeholders | The team is cut off from the product's purpose and its users | The Review is a working session; the Product Goal is the team's objective | Bring a real user or a support representative to the next Review |
| ScrumBut | "We do Scrum, but ..." sentences | Avoiding the problem Scrum makes visible | Implementing parts is possible, but the result is not Scrum | Write down the problem behind each "but" openly in the Retrospective |
| Sprint 0 | A preparation Sprint with no Increment | Not knowing how to build infrastructure together with business value | A valuable, useful Increment every Sprint | Write the first Sprint Goal as the thinnest end-to-end slice |
| Hardening sprint | A feature-less stabilization Sprint before release | A Definition of Done at the "code written" level | Work that does not meet the Definition of Done is not an Increment | Turn the work done in hardening into Definition of Done lines |
| Mini-waterfall | The Done column fills in the last two days | Large items; testing done by a separate person or team | Items are decomposed into work of one day or less; the team is cross-functional | Split items into one-to-two-day slices, bring testing into the item from day one |
| Carry-over Sprints | The same number of items moves to the next Sprint every time | Planning against gross capacity; mini-waterfall | An item that is not Done returns to the Product Backlog; the Sprint Backlog is a forecast | Build a capacity table, and reorder carried-over items instead of moving them automatically |
The answer to the opening question: there are traces of seven anti-patterns, and the root cause is most likely the combination of mini-waterfall and a weak Definition of Done. Because no working software comes out at the end of the Sprint, the director comes to the Daily Scrum to collect status (Dark Scrum); because there is nothing to show at the Review, stakeholders stop coming (Zombie Scrum); and the piled-up testing work breeds a stabilization Sprint before release (hardening sprint).
A 10-Question Self-Check for the Team
The Bookstore team uses this list in a Retrospective every quarter; the number of "no" answers sets the improvement agenda for the next quarter:
- At the end of each of the last three Sprints, was there a usable Increment that met the Definition of Done?
- Can we explain our Sprint Goal to a stakeholder in one sentence, without listing items?
- Did at least one thing change in the Product Backlog at the end of the last Review?
- Did at least one real user, or someone representing them, come to the last Review?
- Was the action from the last Retrospective applied in the next Sprint?
- In the Daily Scrum, do the Developers talk to each other, or report to someone?
- Are the items entering the Done column spread across the Sprint, or squeezed into the last two days?
- Is there an item that cannot be Done because it waits for a person or team outside the team?
- In the last year, did we hold a "preparation" or "stabilization" Sprint that produced no features?
- Did we say a sentence starting with "We do Scrum, but ...", and did we discuss the problem behind it?
The last two questions are reversed: a "yes" is a warning. The list is not for scoring; it is for starting the conversation. An area with more than three "no" answers is a candidate for being the single agenda item of the next Retrospective.
In Production: What to Watch
Most anti-patterns leave traces in the data. The distribution of Done items across the days of the Sprint shows mini-waterfall, the number of items carried over from Sprint to Sprint shows a planning problem, the number of backlog changes after the Review shows Zombie Scrum, and the application rate of Retrospective actions shows whether improvement has stalled. On Bookstore's campaign team more than 70 percent of Done items fell into the last two days; after a two-Sprint change that dropped to 35 percent.
At scale, anti-patterns spread and multiply. If the same symptom shows up in several teams, the root cause is usually not in the teams but in the organization: a separate test department, an approval chain that gives the Product Owner no authority, a Definition of Done not shared across teams. That is the territory of the Scrum Master's service to the organization.
Common Pitfalls
Anti-pattern hunting. Stamping every practice with a label ("that's a ScrumBut!") puts the team on the defensive and ends the conversation. A label is a diagnostic tool; the goal is not to blame the team but to find the root cause.
Trying to fix everything at once. If the campaign team had attacked all seven anti-patterns in the same Sprint, it could not have measured the effect of any of them. The first step was a single thing: splitting items. Carry-over Sprints and the need for a hardening sprint shrank on their own after that.
Using the Guide as a weapon. The sentence "the Guide says so" works when it is used to recall the purpose of a practice, not to close a discussion. The Guide itself says practices vary with context and that it does not describe them.
Mistaking Zombie Scrum for a motivation problem. If a team is unenthusiastic, the cause is usually not in the team but in the fact that its work never reaches a user. The fix is not a morale event; it is putting the Increment in front of a real user.
A Small Experiment
★☆☆ Answer the 10 questions above with your team in the first ten minutes of the next Retrospective. Find the question where answers diverge most; divergence shows the team sees the same reality differently.
★★☆ For the items Done in the last three Sprints, extract the day each became Done and build a distribution by day. If the last two days hold more than half the total, write down how you could split the three largest items.
★★★ Write down three "We do Scrum, but ..." sentences you have heard on your team. For each, gather on one page the real problem behind it, the cost of that problem and the first step to solving it without the ScrumBut, and share it with your Scrum Master.
Many anti-patterns come from not knowing what Scrum is, where it came from and why it sets so few rules. The last post of the series looks at Scrum's history: from the 1986 Harvard Business Review article to the 2020 Guide and the Expansion Pack published in 2025, which does not replace the official Guide.