Diagnosing Dark Scrum: A Card Activity

A team knows something is wrong, but the conversation keeps turning personal.

One person says leadership is the problem. Someone else says the team is not accountable. A stakeholder says Agile is supposed to be flexible. The Scrum Master says the Daily Scrum is for the team, not management. The Product Owner says the roadmap pressure is real. Everyone may be naming part of the truth, but the group still lacks a shared language for the pattern.

That is where many Scrum conversations get stuck. People can feel the dysfunction, but they do not have a way to inspect it without turning the room into a courtroom.

This is the eighth article in the Dark Scrum / Bright Scrum series. Earlier articles defined Dark Scrum and Bright Scrum, showed that Scrum amplifies the surrounding system, and inspected several forces that pull Scrum toward control, false certainty, and quick fixes. Article 8 explains how the Dark Scrum / Bright Scrum cards can make those patterns easier to discuss.

The cards are not a scorecard. They are not there to decide who is dark. They are there to help a group see what the system is making easy.

That distinction matters because the fastest way to make the cards dark would be to use them as proof that someone else is the problem.

Why Cards At All?

Dark Scrum patterns are hard to discuss because they are rarely one person's mistake. A Daily Scrum can become status reporting because a manager attends with control energy, but also because the team has learned not to reveal risk, because the Sprint Goal is weak, because work is sliced around individuals, and because the organization rewards visible busyness more than coordinated progress.

If the conversation starts with "the manager is micromanaging," the manager may defend themselves. If it starts with "the team is not self-managing," the team may defend itself. If it starts with "Scrum is not working," everyone may retreat into their preferred explanation.

A card gives the group a small, shared object of attention. It lets people point to a pattern instead of a person.

That does not solve the problem. It changes the opening move.

A useful card does not simplify the problem away. It gives the group a better starting point for inspection.

Scrum is built on empiricism: transparency, inspection, and adaptation. The Scrum Guide says Scrum makes the relative efficacy of current management, environment, and work techniques visible so improvements can be made. The cards are meant to support that kind of visibility. They help ask: what is Scrum making visible here, and what is the system doing with that visibility?

What The Cards Are For

The cards are for conversation and diagnosis.

They can help a team or leadership group:

• Name recurring patterns without starting with blame.

• Connect Scrum symptoms to system conditions.

• Contrast the dark pattern with a bright alternative.

• Make hidden assumptions easier to inspect.

• Choose a better next question.

• Turn frustration into a conversation about learning, value, quality, ownership, and adaptation.

The point is not to create a clever workshop activity. The point is to make the real pattern easier to discuss while people still have enough honesty to do something about it.

Dark Scrum often hides inside normal language. The board is transparent. The Daily Scrum is disciplined. The Sprint Review is on the calendar. The Product Backlog is ordered. The Retrospective has action items. The dashboard is green.

The card asks a different question:

What is this practice protecting?

If the practice protects learning, adaptation, customer value, transparency, quality, and team ownership, it is moving bright. If it protects comfort, control, certainty, optics, output pressure, or avoidance, it is moving dark.

What The Cards Are Not For

The cards can easily be misused, so the boundary has to be clear.

They are not:

• A maturity model.

• A team scorecard.

• A personality test.

• A way to label managers, teams, or stakeholders as dark.

• A replacement for Scrum, coaching, leadership, or product judgment.

The downloadable resources can help, but the point is not to turn the cards into a scoring tool.

More importantly, the cards should never become a weapon. If a team uses "Theory X" to prove that a manager is bad, the card has become part of the same dark pattern it was meant to expose. If leaders use "Output-Led" to tell teams they are not outcome-focused enough while still rewarding output, the card has become theater.

The cards are useful only when they make the conversation more honest.

If they make the conversation more performative, more defensive, or more certain than the evidence allows, they are being used wrong.

The Basic Diagnostic Move

The cards are only a starting point. To use them in a real conversation, run the structured Dark Scrum / Bright Scrum Diagnostic.

The card is not the answer. It is a better question.

When a Scrum symptom appears, the card can help the group slow down and inspect the pattern:

• What are we seeing?

• Which contrast does this resemble?

• What Scrum mechanic is being pulled dark?

• What would the bright version protect?

• What condition in the system is making the dark version easier?

• What conversation or experiment would test that?

That sequence is intentionally simple. It keeps the group close to observable behavior before jumping to judgment.

For example, if the Daily Scrum feels like status reporting, the first move is not "we have Dark Scrum." The first move is to ask what people are actually doing. Are Developers adapting their plan toward the Sprint Goal, or are they reporting individual activity? Is the team using the event to coordinate, or is the system using the event to monitor? What would need to be true for the team to own the conversation again?

The contrast gives the group a starting point. The conversation still has to do the work.

Output-Led Versus Outcome-Led

If the pattern is output pressure through a metric, Velocity Addiction shows how the number can become the target instead of a planning signal.

This is one of the clearest card contrasts because it shows up in otherwise successful-looking Scrum.

The Sprint ends. The team completed the Sprint Backlog. Velocity looks stable. The dashboard is green. The Sprint Review happens on time. Stakeholders see the work and agree it matches what was requested.

Then nothing important changes.

No product decision changes. No customer assumption is tested. No risk is retired. No stakeholder expectation is adjusted. The Product Backlog stays basically the same because the Review was treated as confirmation that the team delivered, not as inspection of what the Increment teaches.

That is the dark pull of Output-Led Scrum. Completed work becomes the proof of progress.

Output is evidence. It is not the whole verdict.

The problem is not that output is irrelevant. Scrum still asks the Scrum Team to create a usable Increment. Delivery matters. A team that never delivers cannot inspect much of anything.

But output is not the whole story. Output-Led Scrum treats completion as the finish line. Outcome-Led Scrum treats completion as evidence.

The bright side asks harder questions:

• What did this Sprint help us learn?

• What decision changed because of the Increment?

• What risk is now clearer?

• What customer behavior, feedback, or evidence matters next?

• Are we using Scrum to maximize output or to improve product judgment?

This card helps the group notice when a Sprint Review has become a ceremony for proving work was done instead of a moment for improving product decisions.

That is not a small distinction. It is the difference between Scrum as a delivery reporting system and Scrum as an empirical product-learning system.

HIPPOs Tell Versus Customers Tell

Another card contrast shows up in Product Backlog ordering.

The Product Backlog may be orderly, refined, estimated, and visible. The Product Owner may be working hard. Stakeholders may be engaged. From the outside, the system can look professional.

But when the loudest stakeholder, highest-paid person's opinion, or most urgent internal pressure decides what matters, Product Ownership becomes demand translation.

That is the dark pull of HIPPOs Tell Scrum.

The bright side is not anti-leadership. Leaders often have important strategic context. They may see market risk, financial constraints, operational realities, or timing issues that the team does not see. Bright Scrum does not dismiss that.

The question is whether authority substitutes for learning.

Customers Tell Scrum does not mean every customer request becomes the Product Backlog. It means customer evidence, product strategy, and delivery judgment are allowed to challenge internal certainty. The Product Owner still orders the Product Backlog, but the ordering is shaped by value and evidence, not only by pressure.

This contrast asks:

• Whose evidence is changing our backlog?

• Which assumptions are we treating as facts?

• Are stakeholders collaborating around value, or negotiating for output?

If new evidence cannot change the Product Backlog, Scrum is no longer helping the organization learn. It is helping the organization route demand.

Uncertainty Intolerance Versus Uncertainty Tolerance

Scrum is designed for complex work, and complex work contains uncertainty.

Dark Scrum often appears when the organization wants Scrum to remove that discomfort. Forecasts become promises. Sprint Planning becomes commitment extraction. Variance becomes something to explain. Dashboards become reassurance devices.

The card contrast is Uncertainty Intolerance versus Uncertainty Tolerance.

Uncertainty Intolerance asks Scrum to make the future feel safer than it is. It does not always look anxious. It can look disciplined. The plan is detailed. The numbers are clean. The risks are converted into dates, assumptions are converted into commitments, and the Sprint starts with everyone pretending the unknowns are smaller than they are.

Bright Scrum does not enjoy uncertainty. It refuses to lie about it.

Uncertainty Tolerance uses Scrum to make uncertainty visible early enough for responsible adaptation. Sprint Planning still matters. Forecasting still matters. Goals still matter. But the system treats new information as part of the work, not as an embarrassment.

This connects directly to the earlier article on uncertainty intolerance. The card gives teams a compact way to notice when Scrum is being used to manage anxiety instead of manage complex work.

Theory X Versus Theory Y

Theory X and Theory Y assumptions show up quickly in Scrum visibility.

The Daily Scrum may look normal. It is short. People stand near the board. Everyone says what they worked on, what they will work on, and whether they are blocked.

But the underlying question is, "Are people working?"

When that is the real question, the event changes. Updates become performance. People learn to sound busy. Risk is softened. Blockers are phrased carefully. The conversation is shaped for whoever has authority, even if that person never says much.

That is the dark pull of Theory X Scrum. Visibility is used to watch people.

In Dark Scrum, visibility becomes surveillance. In Bright Scrum, visibility becomes coordination.

Theory Y Scrum uses visibility differently. It assumes capable people can take responsibility when goals are clear, constraints are honest, feedback is real, and the team has enough decision space to act.

In that system, the Daily Scrum belongs to the Developers. The question is not "Are you working?" The question is, "What do we need to coordinate or change to make progress toward the Sprint Goal?"

The card helps the group inspect the assumption underneath the event. The surface practice may be identical. The human meaning is not.

Same meeting. Different belief about people.

Quick-Fix Change Versus Systemic Change

The same pattern shows up in Retrospectives.

The same impediment returns every Sprint. The team is overloaded. Priorities change without tradeoffs. Dependencies keep blocking work. Quality expectations rise while time and tooling stay the same.

The Retrospective action item becomes smaller because smaller is all the team can control. Communicate risk earlier. Update the working agreement. Break stories smaller. Improve refinement. Add a checklist.

Those changes may help. The card does not mock local improvement.

The dark pull appears when the fix treats the symptom as the boundary of the problem.

Quick-Fix Change asks, "What can we adjust so this hurts less?" Systemic Change asks, "What condition keeps reproducing this?"

That condition may be a decision right, incentive, staffing constraint, quality tradeoff, stakeholder behavior, approval path, funding model, or leadership habit. Sometimes the team owns part of it. Sometimes leaders own part of it. Often the work is shared.

The contrast keeps the conversation from shrinking too quickly.

In the previous article, the core distinction was symptom relief versus system learning. This card makes that distinction easier to use in the moment.

How To Use The Cards Without Making Them Dark

The cards should make the conversation more honest, not more theatrical.

Use them with discipline:

• Start with a real Scrum situation, not a label.

• Ask what the system is rewarding.

• Name the dark pattern as a hypothesis.

• Name the bright alternative as a direction, not a slogan.

• Identify one conversation, decision, or experiment that would test the pattern.

• Avoid using the cards to diagnose people who are not in the room.

• Keep the focus on learning and system conditions.

This last point matters. Dark Scrum is not usually caused by one villain. It is often produced by normal people adapting to a system that rewards the wrong thing.

That does not remove accountability. It makes accountability more accurate.

If the metric rewards output, people optimize output. If forecasts are punished when they change, people defend old forecasts. If Reviews cannot change decisions, people learn to perform the Review. If Retrospectives never move system constraints upward, teams learn to choose action items that stay safely inside their control.

The card helps the group see the pattern before the system normalizes it.

If the card makes the conversation less honest, the card is being used wrong.

Return to the opening scene. The team is stuck because every explanation points at a person: leadership, the team, the stakeholder, the Scrum Master, the Product Owner. A card can change the conversation by moving the first question from "Who is the problem?" to "What pattern are we seeing, and what is the system making easier?"

That does not remove responsibility. It gives responsibility a better target.

A Compact Field Guide

If the live issue is the Daily Scrum, When Standups Become Surveillance gives a concrete example of how one card conversation can become a better diagnostic.

When a group is looking at a Scrum symptom, these questions can keep the conversation useful:

• What Scrum mechanic is involved?

• What is that mechanic supposed to protect?

• What is it protecting in practice?

• Which card contrast best names the tension?

• What would the bright side require that the current system resists?

• Who has the decision rights to change the condition?

• What is the next useful conversation?

The last question may be the most important.

The purpose of the cards is not to complete the cards. The purpose is to choose a better conversation than the one the system usually has.

Maybe that conversation belongs inside the Scrum Team. Maybe it belongs with stakeholders. Maybe it belongs with leaders who control funding, WIP, staffing, quality expectations, or product strategy. Maybe it belongs with the Scrum Master, who needs to help the organization understand what Scrum is revealing.

The card does not decide that for you. It helps you stop pretending the issue is only a meeting problem.

What Comes Next

Article 8 explains the cards. Article 9 will show how to run a Dark Scrum / Bright Scrum diagnostic with them.

That next step matters because even a useful diagnostic tool can become theater if the group uses it poorly. A diagnostic can become blame. It can become a checklist. It can become a workshop activity that produces insight and no change.

The next article moves from what the cards mean to how a team or leadership group can use them without turning the exercise into another dark pattern.

For now, the simplest test is this:

Does the card help the group protect learning, or does it help the group protect its favorite explanation?

Next Step

The cards can make patterns easier to see. They only help when people have enough Scrum judgment to use what they see.

Transparency without blame. Inspection without theater. Adaptation without panic. Ownership without abandonment.

In our Certified ScrumMaster courses, we reconnect Scrum practices to the purpose they were designed to serve: better transparency, stronger feedback loops, healthier collaboration, clearer accountability, and more honest progress.

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 values

• Principles behind the Agile Manifesto

• The Scrum Guide, 2020 edition