Dark/Bright Scrum 02: What Is Dark Scrum?

Agile can look right and still feel wrong.

This is the second article in the Dark Scrum / Bright Scrum series. The first article looked at how bright ideas can become dark systems. This article defines Dark Scrum directly: what it is, how to recognize it, and why the form can survive after the purpose has been subtracted.

The Scrum events are on the calendar. The team uses the language of transparency, inspection, adaptation, feedback, collaboration, and continuous improvement. Leaders can point to ceremonies, artifacts, dashboards, roadmaps, standups, retrospectives, and delivery metrics.

From a distance, the organization can say, "We are Agile."

But the team knows something is off. The practices do not create more learning. They create more reporting. Transparency does not make adaptation easier. It makes people more careful about what they reveal. Planning does not help the team make better decisions under uncertainty. It becomes a way to pretend uncertainty has been removed.

That is the first sign of Dark Scrum. The form is still there. The purpose has been subtracted.

The Dark Scrum Formula

Dark Scrum is what happens when Scrum mechanics keep running after the Agile values and principles that give those mechanics their purpose have been weakened, ignored, or contradicted by the surrounding system. The simplest version is this. It is a diagnostic, not a slogan:

Scrum - Agile Values & Principles = Dark Scrum

That formula matters because it keeps us from making the easy mistake. Dark Scrum is not just "bad Scrum" or a team failing to perform the ceremonies with enough energy. It is not proof that Scrum itself is useless. It is what remains when the visible mechanics of Scrum are absorbed by a system that wants control, predictability, compliance, output, or pressure more than learning.

This is why Dark Scrum can be hard to name. The calendar does not confess. The board does not confess. The metrics often look cleaner than before. Everyone may be using the right words. Dark Scrum keeps the names and loses the purpose.

What Gets Subtracted

The Agile Manifesto names four value statements: "Individuals and interactions over processes and tools," "Working software over comprehensive documentation," "Customer collaboration over contract negotiation," and "Responding to change over following a plan."

Those phrases are not decorative history. They are a warning label for every process we build. The Manifesto does not say the items on the right have no value. It says the items on the left matter more. Dark Scrum reverses that priority. It keeps the process and tools. It keeps the documentation. It keeps the negotiation. It keeps the plan. Then it wraps those preferences in Scrum language and calls the result Agile.

That is where the distortion begins. A practice is not bright or dark by itself. A Daily Scrum can help a team coordinate around reality. It can also become a daily inspection ritual where people learn to sound busy and stay safe.

The question is not whether the practice happened. The question is what the practice served.

Why Start With Scrum

This series starts with Scrum because Scrum makes the drift easy to see. It has named events, roles, artifacts, and commitments. When those mechanics lose their Agile purpose, the contrast becomes visible fast.

But the pattern is bigger than Scrum. Once you see the subtraction, you can apply the same lens to Kanban, XP, OKRs, AI-assisted work, or an organization's own organic way of working.

Kanban can go dark when visualization becomes surveillance, WIP limits become management theater, and flow metrics become pressure instead of learning. XP can go dark when engineering practices become compliance theater instead of technical excellence and shared learning. OKRs can go dark when outcomes become reverse-engineered numbers. Retrospectives can go dark in any method when they document pain without changing the system. AI-assisted work can go dark when faster output overwhelms human judgment and review capacity.

Dark Scrum is the practical starting point, not the boundary of the idea.

Sprint Planning Without People

Start with Sprint Planning. In Bright Scrum, Sprint Planning is a real conversation about the goal, the work, the uncertainty, and the tradeoffs. The team is not pretending to know everything. They are deciding how to begin responsibly. They bring their expertise into the room, not just their availability.

In Dark Scrum, Sprint Planning becomes assignment with Agile vocabulary. The backlog is already decided. The capacity is already assumed. The pressure is already in the room. The meeting exists to distribute work and extract a commitment.

That is Scrum minus people. The first Manifesto value puts individuals and interactions ahead of processes and tools. Dark Scrum may still have the process. It may still have the planning tool. It may even have a meeting where people speak. But the interaction has been hollowed out if the team cannot meaningfully shape the plan, name the risk, challenge the load, or change the goal.

When planning becomes a contract instead of a conversation, Agile has gone dark.

Daily Scrum Without Adaptation

The Daily Scrum is where the subtraction becomes visible fast. In Bright Scrum, the Daily Scrum helps the team inspect progress toward the Sprint Goal and adapt the plan. It is a coordination event. The team uses it to notice what changed, what is blocked, and what needs to shift so the goal still has a chance.

In Dark Scrum, the Daily Scrum becomes a status checkpoint. People report what they did yesterday, what they will do today, and what might make them look bad. The conversation points upward, even when the manager is not physically in the room. People learn the safest answer, not the truest one.

This is Dark Scrum in its daily status-reporting form. The event still happens every day. That is not the problem. The problem is that the event no longer changes anything important. It does not protect adaptation. It protects visibility for control.

There is a big difference between being visible and being watched. Bright Scrum uses transparency to help the team learn. Dark Scrum uses transparency to make the team easier to manage.

Sprint Review Without Customer Learning

The Sprint Review can drift the same way. In Bright Scrum, the Sprint Review is a feedback event. The team shows working product or meaningful progress, invites conversation, and learns something that may change what happens next. The point is not performance. The point is evidence.

In Dark Scrum, the Sprint Review becomes demo theater. The work is presented after the real decisions have already been made somewhere else. Stakeholders attend as an audience. The team performs progress. Everyone acts as if feedback is welcome, but the system has no real appetite for changing direction.

That is Dark Scrum minus customer collaboration. The event may still look polished. It may look more professional than a messy, useful review. But polish can be a trap. A clean demo can hide the fact that nobody is learning anything that changes the work.

If the Sprint Review cannot influence direction, it is not a review. It is a broadcast.

Retrospectives Without System Change

Retrospectives may be the most painful version of Dark Scrum because they can look psychologically safe while teaching people that nothing changes.

In Bright Scrum, the Retrospective is where the team reflects, identifies a real improvement, and adjusts how it works. Sometimes the improvement is inside the team. Sometimes it requires a manager, a policy change, a staffing decision, a technical investment, or a conversation the organization has been avoiding.

In Dark Scrum, the Retrospective becomes a coping ritual. The same problems appear every sprint. The team names them carefully. Everyone agrees they matter. Then the action items stay small enough to avoid touching the system that caused the pain.

The Agile principles say the team should reflect on how to become more effective. Dark Scrum turns that into a meeting where people document why effectiveness is blocked and then return to the same conditions.

At some point, a retrospective that cannot change the system becomes part of the system.

Definition Of Done Without Quality

The Definition of Done is supposed to protect value. It should make quality visible before the work is treated as complete. It should prevent unfinished work from being renamed as progress. It should help the team and stakeholders share a serious understanding of what "done" means.

In Dark Scrum, the Definition of Done becomes paperwork. It is a checklist people satisfy without asking whether the product is healthy, usable, maintainable, or valuable. Worse, it can become a shield. The team can say the item is done because the boxes are checked, while quality risk moves quietly downstream.

That is Dark Scrum minus technical excellence and good design. A Bright Definition of Done might say the work is not done until the user-facing behavior is verified in a realistic environment, the quality risk is named, and the team would be willing to support the change after release. A weak Definition of Done does not only create defects. It creates false confidence. It lets the organization believe work is complete when the real cost has merely been postponed.

Dark Scrum loves false confidence. It makes the dashboard look cleaner while the product gets harder to change.

Sprint Goals Without Value

Sprint Goals can also go dark. In Bright Scrum, a Sprint Goal gives the team a focus for tradeoffs. It helps people decide what matters when reality changes. It gives the sprint a purpose that is larger than finishing a list of tasks.

In Dark Scrum, the Sprint Goal becomes a slogan pasted over output pressure. The real goal is to finish the tickets, hit the number, satisfy the forecast, or avoid the conversation about why the work is too fragmented to have a meaningful goal in the first place.

That is Dark Scrum minus customer value. A real goal helps the team choose. A fake goal helps the organization pretend a pile of work is coherent.

This is one of the quietest forms of Dark Scrum. Nobody has to say anything obviously wrong. The goal can sound reasonable. The board can look active. The burndown can move. But the team is not learning toward value. It is pushing work through a pipe.

Why Dark Scrum Can Look Normal

Dark Scrum often survives because it looks normal from the outside. The organization sees events, artifacts, roles, reports, metrics, and predictable cadences. Leaders can say Scrum is installed. Teams can say they are following the process. Coaches can point to ceremony attendance and tool hygiene. Everyone has evidence that something is happening.

But Scrum is not valuable because it creates activity. Scrum is valuable when it helps people learn and adapt toward better outcomes. Once inspection becomes surveillance, adaptation becomes re-planning theater, and transparency becomes pressure, the mechanics start serving a different system. That system may still call itself Scrum. The team will know better.

They will feel it in the way people speak during Daily Scrum. They will feel it in the silence around unrealistic plans. They will feel it when retrospectives get safer by getting smaller. They will feel it when quality concerns are translated into "not this sprint." They will feel it when the Sprint Goal is treated as a motivational poster instead of a decision tool.

Dark Scrum is not hidden because it is invisible. It is hidden because people are trained to inspect the mechanics instead of the purpose.

The Causes Come Later

Dark Scrum has causes. Theory X assumptions matter. If leaders believe people avoid work unless controlled, transparency becomes a cheaper way to watch them. Uncertainty intolerance matters. If an organization cannot tolerate not knowing, Sprint Planning becomes a way to manufacture certainty instead of make an honest forecast. Quick-fix thinking matters. If Scrum is installed as a shortcut around structural and cultural problems, the framework gets blamed for conditions it was never allowed to change.

Those causes deserve their own articles. They are bigger than Scrum, and the Dark Agile matrix is a better map for that territory: output over outcomes, HIPPOs over customers, certainty over learning, cognitive simplicity over complexity, high power distance over bad-news transparency, Theory X over trust, fixed mindset over growth, short-termism over sustainability, and quick-fix change over systemic change.

For now, the job is simpler: recognize the pattern: control over trust, predictability theater over adaptation, output pressure over outcomes, and process compliance over empirical learning.

If those are the forces shaping your Scrum, the problem is not that the team forgot how to run the meetings. The problem is that the practices have been recruited into the wrong job.

The Diagnostic Question

When Scrum feels wrong, do not start by asking whether the team is doing the practice correctly. Ask what has been subtracted.

What Agile value or principle is missing from this practice?

• Is transparency helping the team learn, or helping someone watch?

• Is planning helping the team adapt, or forcing the team to pretend uncertainty is gone?

• Is the review creating customer learning, or only displaying completed work?

• Is the retrospective changing the system, or asking the team to cope better?

• Is the Definition of Done protecting value, or hiding risk behind a checklist?

• Is the goal helping the team make decisions, or decorating output pressure?

That question changes the conversation. It moves the team away from "Are we doing Scrum?" and toward the more useful question: "What is our Scrum serving?"

Bright Scrum Is The Contrast

If Dark Scrum is Scrum with Agile values and principles subtracted, Bright Scrum is not a new ceremony package. It is Scrum reconnected to the purpose that makes the mechanics worth using.

Bright Scrum does not mean every meeting feels good. It does not mean there is no pressure, no tradeoff, no disagreement, and no hard conversation. Bright Scrum may actually create harder conversations because it refuses to let the process hide reality.

But the purpose is different. Transparency is for learning. Planning is for adaptation. Reviews are for feedback. Retrospectives are for changing the system. Done is for protecting value. Goals are for making decisions under uncertainty. Flow is for improving the system, not speeding up the pressure.

That is the difference.

Dark Scrum asks Scrum to make control more efficient. Bright Scrum asks Scrum to make learning harder to avoid.

The next article turns the contrast around and defines Bright Scrum: Scrum reconnected to Agile values and principles so the mechanics serve learning, adaptation, quality, feedback, and team ownership.

If this definition helps you name what has gone wrong in your Scrum, keep going with the Lean/Agile articles.

Next Step

Where is your Scrum protecting the mechanics more than the purpose? If you want to practice the Bright Scrum side of the formula, join one of our Certified ScrumMaster courses, where we connect Scrum mechanics back to trust, adaptation, transparency, and real team learning.

Sources

• Agile Manifesto, https://agilemanifesto.org/

• Principles behind the Agile Manifesto, https://agilemanifesto.org/principles.html

• Dark Scrum presentation deck, internal source presentation

• Dark Agile Matrix Cards, internal source deck