Run a Dark Scrum / Bright Scrum Diagnostic

A team recognizes a Dark Scrum pattern.

Someone wants to use the Dark Scrum / Bright Scrum cards.

That can help. It can also go wrong quickly.

If the conversation is handled poorly, the cards become a new way to label people, score the team, or prove that another group is the problem. The team gets a new vocabulary, but the behavior underneath does not change. The tool that was supposed to make the conversation safer becomes one more way to make the system defensive.

That would be a dark use of the cards.

The cards are not the diagnostic. The conversation is the diagnostic.

The cards help the group stay with observable patterns long enough to ask better questions. They are not a verdict. They are not a maturity model. They are not a way to classify a team as dark or bright.

A Dark Scrum / Bright Scrum diagnostic is a structured conversation. It helps a group inspect how Scrum is being used, what the current system is protecting, and what one brighter experiment might look like.

If the terms are new, start with the definitions of Dark Scrum and Bright Scrum before running the diagnostic.

Download the Dark/Bright Scrum Diagnostic Cards and related talk resources on the Dark/Bright Scrum talk and resources page.

You can also run the diagnostic using the prompts in this article. The cards are a facilitation aid, not the activity itself.

This is the ninth article in the Dark Scrum / Bright Scrum series. Article 8 introduced the cards as a better way to talk about Dark Scrum without blame. This article shows how to use that language in a real diagnostic conversation.

The examples here use Scrum because this series is focused on Scrum, but the diagnostic logic is broader. The same pattern can show up in Kanban, XP, or any agile way of working when a useful practice starts protecting control, comfort, certainty, or theater instead of learning.

What This Diagnostic Is For

If you have not used the cards yet, start with How Dark/Bright Scrum Cards Help Teams Talk About Dark Scrum Without Blame.

The diagnostic has one job: make one Scrum pain point discussable without turning it into a blame session.

That sounds simple. It is not.

Scrum makes work, decisions, tradeoffs, and risks visible. When that visibility is used well, it helps people learn and adapt. When it is used poorly, it can create pressure, surveillance, defense, and theater.

The diagnostic helps the group slow down enough to separate three things:

• what people can observe

• what pattern the system may be producing

• what better Scrum purpose the group wants to protect

That separation matters. Without it, people jump straight from discomfort to accusation.

"The Daily Scrum feels bad" becomes "the Scrum Master is micromanaging us."

"Sprint Planning does not work" becomes "the team is not accountable."

"Velocity is being misused" becomes "leadership only cares about numbers."

Any of those claims might contain a piece of truth. But they are too loaded to start with. Once the conversation begins there, people defend themselves. When people defend themselves, they usually stop inspecting the system honestly.

If the diagnostic makes people defend themselves, it has already started to fail.

The diagnostic is for:

• making one Scrum pain point concrete

• separating observable behavior from inferred motive

• naming a Dark Scrum pattern without labeling people

• reconnecting the Scrum mechanic to its intended purpose

• choosing one useful next conversation or experiment

It is not for:

• ranking teams

• scoring people

• proving a leader, Scrum Master, Product Owner, or developer is the problem

• running a maturity assessment

• auditing Scrum Guide compliance as the main point

• producing a long improvement backlog nobody will use

The goal is not to decide whether a team is dark or bright. The goal is to inspect one pattern with enough honesty that a brighter next move becomes possible.

Before You Start

Keep the setup small.

The first mistake is trying to diagnose the whole organization. That may feel satisfying for five minutes, but it usually creates a conversation too large to act on. People start describing culture, leadership, trust, funding, dependencies, tools, strategy, and every unresolved frustration in the system.

Some of those things may matter. They are just too big for the first diagnostic.

Start with one Scrum situation.

A useful setup looks like this:

• 45 to 60 minutes

• 4 to 8 people, if possible

• one real Scrum situation, not the whole organization

• a facilitator who can keep the group on evidence and pattern

• cards or prompts visible to everyone

• a place to capture observations, risks, and one experiment

The group should include people close enough to the work to see the pattern. That might include Developers, a Scrum Master, a Product Owner, an Agile coach, a team lead, or a leader who works closely with the team.

Be careful with power dynamics.

Leadership can be useful in the room if leaders can participate without correcting, explaining, or defending the system. If a leader's presence makes people edit themselves, start smaller. Use anonymous input first, or run the diagnostic with the team before bringing the pattern into a broader conversation.

The ground rule is simple:

We are diagnosing a pattern in the system, not deciding who is at fault.

That does not remove accountability. It makes accountability more useful. People can be accountable for what they do next without pretending that one person's behavior explains the whole pattern.

Pick One Scrum Situation

For a concrete Daily Scrum example, see When Standups Become Surveillance.

Do not begin with "our culture is broken."

Do not begin with "leadership does not trust us."

Do not begin with "the team is not accountable."

Those may be real concerns, but they are too broad to inspect. They also invite people to argue about motives before they have agreed on observations.

Start with one visible Scrum moment where the pattern appears.

Good candidates include:

• Daily Scrum feels like status reporting.

• Sprint Planning feels like capacity loading.

• Sprint Review feels like a defense of the old plan.

• Retrospectives repeat the same issues every Sprint.

• Velocity is treated as a target.

• The Definition of Done is negotiated away under pressure.

• The Product Backlog is ordered more by stakeholder pressure than product learning.

The situation should be recent enough that people can remember what happened. It should be specific enough that the group can describe it without drifting into organizational mythology.

"Our Daily Scrum has become surveillance" is still a little broad.

"In the last two Daily Scrums, each person gave an update to the manager, nobody discussed the Sprint Goal, and blockers were handled after the meeting as individual follow-up" is much better.

The diagnostic starts to work when the group can point to behavior instead of only describing frustration.

Describe What Is Observable

This is where the facilitator has to be disciplined.

Ask people to describe what happened, not why they think it happened. Capture phrases people actually heard. Capture behaviors people could see. Capture decisions that were made or avoided.

Avoid mind-reading.

Useful prompts:

• What happened in the last Scrum event where this pattern was visible?

• What did people say?

• What decisions were made?

• What information was ignored, softened, or delayed?

• What did the team learn to avoid saying?

• What changed after the conversation?

This is not a demand for sterile language. People can name real discomfort. But the group needs to distinguish observation from interpretation.

Instead of:

"Management does not trust the team."

Try:

"In Sprint Planning, the team raised three risks. The plan did not change. The same scope stayed in the Sprint, and the risks were treated as things the team should absorb."

That second version is more useful. It gives the group something to inspect. Maybe the issue is mistrust. Maybe the issue is planning pressure. Maybe the issue is unclear decision rights. Maybe the issue is a leadership habit of hearing risk as resistance.

The diagnostic does not need to settle all of that immediately. It needs to keep the group close enough to evidence that the next question becomes sharper.

Ask What Scrum Is Supposed To Protect

Every Scrum mechanic is supposed to protect something.

The Daily Scrum is not supposed to protect the manager's need for updates. It is supposed to help Developers inspect progress toward the Sprint Goal and adapt their plan.

Sprint Planning is not supposed to protect a capacity spreadsheet. It is supposed to create focus, shared understanding, and a responsible plan for pursuing a Sprint Goal.

The Sprint Review is not supposed to protect the old plan from embarrassment. It is supposed to create transparency and feedback so the Product Backlog can change based on learning.

The Retrospective is not supposed to protect the appearance of continuous improvement. It is supposed to help the Scrum Team inspect and improve the way it works.

The Definition of Done is not supposed to protect a label. It is supposed to protect quality and transparency.

Metrics are not supposed to protect pressure. They are supposed to support judgment.

This question is the conceptual center of the diagnostic:

What is this Scrum mechanic supposed to protect?

You can ask it a few ways:

• What is this event, artifact, accountability, or commitment supposed to make visible?

• What decision is it supposed to improve?

• What kind of learning is it supposed to protect?

• What responsibility is it supposed to make possible?

This prevents the diagnostic from becoming a complaint session. The group is not only saying what feels wrong. It is reconnecting the mechanic to its purpose.

Bright Scrum is not Scrum with better vibes. Bright Scrum is Scrum used in service of learning, value, quality, responsibility, and adaptation.

That means the bright side of a pattern is usually more demanding, not less.

Ask What The System Is Protecting In Practice

Now comes the harder question.

If the Scrum mechanic is supposed to protect one thing, what is it protecting in practice?

This is where Dark Scrum becomes visible.

A status-style Daily Scrum may protect management comfort more than team coordination.

A velocity target may protect the appearance of predictability more than real forecasting.

A defensive Sprint Review may protect the old plan more than product learning.

A weak Retrospective may protect the system from changing what it rewards.

This does not mean everyone is acting with bad intent. Most Dark Scrum patterns survive because they protect something the organization has learned to value, even when that thing damages learning.

The system may be protecting certainty.

It may be protecting a roadmap promise.

It may be protecting a leader from hearing uncomfortable tradeoffs.

It may be protecting the team from punishment.

It may be protecting a metric that makes progress look cleaner than it is.

This is why the diagnostic has to stay grounded in behavior. Otherwise this section can turn into blame quickly.

Useful prompts:

• What does the current pattern make safer for the organization?

• What discomfort does it help people avoid?

• What truth becomes harder to say?

• What decision gets delayed?

• Who gets protected from uncertainty, tradeoffs, or accountability?

Dark Scrum often protects organizational comfort. Bright Scrum protects organizational learning.

That sentence should make the conversation less personal, not less accountable. The issue is not who to blame. The issue is what the system is rewarding, avoiding, or protecting through this Scrum mechanic.

Once the group can see that, the next move becomes more practical.

Use The Cards Or Prompts To Name The Pattern

If you have the cards, do not spread the whole deck and invite everyone to diagnose everything.

That will create too much surface area. People will find too many patterns, argue about too many labels, and leave with too little movement.

Use a small set of relevant cards.

Ask each person to pick one card that best describes the pattern. Then require an evidence sentence:

"I picked this because I observed..."

That sentence matters. It keeps the card connected to evidence instead of opinion. It also slows down the urge to weaponize the language.

The facilitator should listen for three moves:

• people labeling other people

• people jumping from one situation to the whole organization

• people picking a card without evidence

When that happens, bring the group back:

"What did we observe?"

"Where did that show up?"

"What did the Scrum mechanic protect in that moment?"

If you do not have the cards yet, use the contrast directly:

• What is the dark version of this Scrum mechanic?

• What would the bright version protect instead?

• What would we see or hear if this mechanic were supporting learning?

Do not force consensus too early.

Disagreement can be useful. It may show that people are seeing different parts of the system. The Product Owner may see stakeholder pressure. Developers may see quality risk. A leader may see predictability concerns. A Scrum Master may see the team editing itself.

The goal is not to flatten those views into one tidy answer. The goal is to create enough shared language that the group can choose a useful next move.

The cards are not the diagnostic. They are a way to keep the conversation anchored while the diagnostic happens.

Translate The Pattern Into A Bright Scrum Question

Diagnosis is not enough.

If the group stops at "we found a Dark Scrum pattern," the conversation can become cynical. People get a sharper label for something they already dislike, but no better path forward.

Translate the pattern into a Bright Scrum question.

Use this formula:

If the dark pattern is ____, the bright question is ____.

Examples:

• If the Daily Scrum has become status reporting, the bright question is: What does the team need to coordinate today to protect the Sprint Goal?

• If Sprint Planning has become assignment packaging, the bright question is: What would make this forecast honest enough to act on?

• If the Sprint Review has become a defense of the old plan, the bright question is: What did we learn that should change the Product Backlog?

• If velocity has become a target, the bright question is: What decision is this metric supposed to improve?

• If the Retrospective has become emotional ventilation, the bright question is: What can this team change, and what system impediment needs a different conversation?

The Bright Scrum question should not be inspirational. It should be useful.

It should point toward a decision, experiment, conversation, or behavior that makes the Scrum mechanic serve learning again.

Choose One Small Experiment

The output of the diagnostic is not a transformation backlog.

It is one next move.

That next move might be an experiment the team can run. It might be a conversation with leadership. It might be a change to how an event is facilitated. It might be a decision to inspect one metric differently.

Keep it small enough to try and real enough to matter.

A useful experiment should be:

• small enough to try in one Sprint

• connected to the pattern

• owned by people who can actually influence it

• clear enough to inspect later

• honest about what the team does and does not control

A useful experiment does not require pretending the team controls the whole system.

That matters. Some Dark Scrum patterns are team-level habits. Others are system-level pressures showing up through the team. If the diagnostic reveals that the team cannot fully solve the issue alone, that is not failure. That is useful information.

Examples:

• For one Sprint, change the Daily Scrum prompt from individual updates to Sprint Goal coordination.

• Before finalizing Sprint Planning, add a risk and tradeoff check: "What would make this plan irresponsible?"

• In the next Sprint Review, reserve five minutes for: "What changed in our understanding of value?"

• For one metric, write down the decision it is supposed to improve before discussing the number.

• In the Retrospective, separate team-owned improvements from system impediments that need leadership response.

The experiment should create better evidence. It does not need to solve the whole pattern immediately.

Close The Diagnostic Clearly

Do not end with vague agreement.

Vague agreement feels good in the room and disappears immediately afterward.

Close by capturing five things:

• the Scrum situation inspected

• the observed pattern

• the Scrum purpose being distorted

• the Bright Scrum question

• the one experiment or next conversation

• what will be inspected after the experiment

That close is important because it protects the diagnostic from becoming a discussion artifact. The group should know what it is trying next and how it will learn from it.

A useful closing script is:

"We are not declaring that this team is dark or bright. We are naming one pattern we can inspect. We will try one change, watch what happens, and come back with better evidence."

The point is not to produce a perfect improvement plan. The point is to create a better learning loop.

Common Failure Modes

If the team keeps asking for certainty before it can adapt, inspect Uncertainty Intolerance as the deeper pattern.

If the diagnostic starts with velocity pressure, Velocity Addiction shows how a planning signal becomes a pressure target.

The fastest way to make the cards dark is to use them as proof that someone else is the problem.

Watch for these failure modes.

Failure: Turning the cards into a maturity score.

Correction: The goal is not to classify the team. The goal is to inspect one pattern.

Failure: Using the cards to label another group.

Correction: Bring the conversation back to observable behavior and the system conditions that make the pattern more likely.

Failure: Trying to diagnose the whole organization at once.

Correction: Choose one Scrum situation where the pattern appears.

Failure: Skipping evidence and jumping to explanation.

Correction: Require the evidence sentence: "I picked this because I observed..."

Failure: Letting leaders correct the team's perception during the diagnostic.

Correction: Ask leaders to listen for system information before explaining intent.

Failure: Ending with a vague action item.

Correction: Choose one experiment or one next conversation that can be inspected later.

Failure: Treating the bright side as nicer language.

Correction: Bright Scrum is not softer Scrum. It is Scrum with more honest learning and more useful accountability.

These corrections do not make the diagnostic easy. They make it less likely to become theater.

Why This Matters For The Series

The earlier articles in this series built the language.

Articles 2 and 3 defined Dark Scrum and Bright Scrum. Articles 5 through 7 inspected forces that pull Scrum dark: assumptions about people, uncertainty intolerance, and quick-fix behavior. Article 8 introduced the cards as a better way to talk about Dark Scrum without blame.

This article turns that language into a practical conversation.

That matters because the next articles will inspect specific Dark Scrum patterns. Before diagnosing Daily Scrum surveillance, velocity addiction, or other common distortions, the group needs a way to keep the conversation grounded in evidence, purpose, and one next experiment.

Otherwise the series language itself could become dark.

Dark Scrum is not a label for people who are doing Scrum wrong. Bright Scrum is not a label for people who agree with us.

Dark Scrum names a pattern where Scrum mechanics are used to protect control, comfort, certainty, or theater.

Bright Scrum names a pattern where Scrum mechanics are used to protect learning, value, quality, responsibility, and adaptation.

A diagnostic conversation helps a group see which pattern is showing up in one real situation.

That is enough work for one conversation.

What Comes Next

The next article applies this diagnostic to one of the fastest places Dark Scrum appears: the Daily Scrum.

When the Daily Scrum becomes surveillance, visibility stops helping the team coordinate and starts helping the system watch people. The event may still be short. It may still happen every day. People may still stand near a board or open the same Jira view.

But the purpose has changed.

That is the first specific pattern we will inspect next.

For now, the diagnostic is simple:

Pick one Scrum situation. Describe what is observable. Ask what the mechanic is supposed to protect. Ask what it is protecting in practice. Name the pattern without blame. Translate it into a Bright Scrum question. Choose one small experiment.

The cards can help.

But the conversation is the diagnostic.

Next Step

A diagnostic conversation like this asks for more than Scrum terminology. It asks for facilitation judgment: how to keep people with evidence, how to protect honesty without avoiding accountability, and how to reconnect Scrum mechanics to learning.

In our Certified ScrumMaster courses, we help people build that practical Scrum judgment through transparency, inspection, adaptation, facilitation, accountability, and healthier use of Scrum mechanics.

For the talk and downloadable resources behind this series, including the Bright/Dark Scrum formula cards and Dark Agile Cards, use the Dark/Bright Scrum talk and resources page.

Sources

• Agile Manifesto, official values page: https://agilemanifesto.org/

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

• The Scrum Guide, 2020 edition: https://scrumguides.org/scrum-guide.html