From Theory X to Theory Y

Scrum makes work visible. That visibility sounds obviously useful until the organization uses it to watch people instead of help people make better decisions.

From a distance, the mechanics can look familiar: visible board, Daily Scrum, Sprint Goal, metrics, Retrospective, Scrum Master, Product Owner, Product Backlog. But the purpose can be completely different.

In Bright Scrum, visibility helps capable people coordinate, learn, inspect risk, improve quality, and take responsibility for complex work. In Dark Scrum, visibility becomes a control surface. It helps the organization monitor people, apply pressure, correct behavior, and preserve the feeling that work is under control.

The difference is not the event name. It is what the organization believes visibility is for.

This is the fifth article in the Dark Scrum / Bright Scrum series. The first article showed how bright ideas can become dark systems when organizations keep the mechanics and lose the purpose. The second article defined Dark Scrum as Scrum with Agile values and principles subtracted. The third article defined Bright Scrum as Scrum reconnected to Agile values and principles. The fourth article explained that Scrum amplifies the surrounding system.

Now we can inspect one of the first things Scrum amplifies: what the organization believes about people.

The Assumption Under The Process

Theory X and Theory Y are old management language, but the distinction is still useful if we keep it practical. Theory X assumes people must be watched, pushed, corrected, and controlled, or work will drift. Theory Y assumes people can take responsibility, learn, improve, and coordinate around meaningful goals when the system gives them clarity, trust, feedback, and real decision space.

Theory X uses process to make people comply. Theory Y uses process to make responsibility possible.

That contrast is easy to flatten. It should not become "mean managers versus nice managers." It should not become "control bad, trust good." That is too soft for real work.

The real question is whether Scrum is being used to control people or to create the conditions for ownership.

Bright Scrum is not permissive Scrum. It does not mean people do whatever they want, leaders disappear, or accountability gets replaced by warm language. It asks for a harder kind of accountability: visible work, clear goals, transparent risks, real inspection, responsible adaptation, and honest conversations about quality, value, and constraints.

Dark Scrum can also talk about accountability. But under Theory X assumptions, accountability often means something narrower: Can we see what each person is doing? Can we tell who is behind? Can we increase pressure? Can we make the team explain variance?

Both systems may use the same Scrum vocabulary. Only one is treating people as capable of ownership.

Daily Scrum Becomes Coordination Or Status Reporting

The Daily Scrum is one of the easiest places to see this control logic. Later in the series, When Standups Become Surveillance looks at that pattern directly.

The Daily Scrum is one of the fastest places to see the assumption.

In Dark Scrum, the Daily Scrum becomes a status meeting. The team performs progress for someone else. The questions underneath the conversation are not really about the Sprint Goal. They are about whether each person is busy, whether each person is on track, and whether anyone needs to explain themselves.

The event may still be short. It may still happen every day. People may still stand near a board. But the center of gravity has shifted from coordination to inspection of the workers.

That shift changes behavior quickly. People learn to speak in safe updates. They learn to sound productive. They learn not to reveal uncertainty unless they already have a solution. They learn that blockers are acceptable only when they do not create discomfort for anyone with authority.

The organization may call that transparency, but it is really performance management in Scrum clothing.

In Bright Scrum, the Daily Scrum belongs to the team. It helps Developers inspect progress toward the Sprint Goal and adapt their plan. The event is still disciplined. It is not casual conversation. It is not a group therapy session. It is a coordination point for people doing shared work under changing conditions.

The difference is visible in the questions people care about.

• What has changed since yesterday?

• What do we need to coordinate?

• Is the Sprint Goal still realistic?

• Where is risk showing up?

• What decision do we need to make before the day gets away from us?

• Who needs help, and what kind of help would actually matter?

Status asks, "Are you working?"

Coordination asks, "What do we need to learn or change?"

That is the Theory X / Theory Y split inside one Scrum event.

Sprint Planning Becomes Assignment Packaging Or Shared Focus

Theory X assumptions often become sharper when uncertainty rises. The next cause is uncertainty intolerance: treating not knowing as a defect instead of a condition of complex work.

Sprint Planning shows the same pattern before the Sprint even begins.

In Dark Scrum, Sprint Planning becomes assignment packaging. The work is already decided somewhere else. The team is treated as a capacity container. The conversation is mostly about how much can be loaded into the Sprint and who will take which pieces.

The Sprint Goal may exist, but it does not guide decisions. It becomes a label placed over a bundle of tasks.

This is not always loud or aggressive. It can look very organized. The backlog is ready. The estimates are visible. The capacity math is done. The team is asked whether it can "commit." The plan looks clean.

It can sound as ordinary as this: "Last Sprint you finished 42 points, so can we pull in these extra two items?" The question looks like planning, but it has already reduced the team to a throughput line. The Product Goal, Sprint Goal, risk, quality, and unknowns become secondary to filling the container.

But the underlying assumption is weak: the organization is not trusting the team to help shape the work. It is asking the team to accept the package and deliver the package.

Under Theory X assumptions, planning is a way to secure compliance before uncertainty appears.

In Bright Scrum, Sprint Planning creates shared focus. The Product Owner brings the goal, ordering, product context, and value conversation. Developers bring technical judgment, capacity realities, risk awareness, and delivery knowledge. Together, the Scrum Team creates a plan for pursuing a Sprint Goal.

That plan still matters. Bright Scrum does not make planning optional. It makes planning more honest.

The team can say:

• This item is too unclear to forecast responsibly.

• This dependency could change the plan.

• This quality risk needs to be visible now, not at the end.

• This Sprint Goal is too broad to guide tradeoffs.

• This work matters, but not all of it belongs in this Sprint.

Those conversations are not signs of low accountability. They are what accountability sounds like before the work becomes painful.

If people are trusted with responsibility, they must also be allowed to bring reality into planning.

Metrics Become Pressure Or Judgment Support

Metrics expose the assumption quickly because numbers look objective.

A metric can help a team see something important before it becomes expensive. Cycle time can expose a bottleneck. Defect trends can reveal quality risk. Escaped defects can show that "Done" is not as done as people thought. WIP can show that the team is starting more work than it can finish. Velocity, used carefully, can help a team think about capacity, historical throughput, and forecast ranges.

None of that is dark by itself. Good metrics can move in uncomfortable ways and still be useful. Sometimes a metric gets worse because the team finally made hidden work visible. Sometimes throughput dips because the team stops bypassing quality work. Sometimes cycle time rises because a dependency is real and needs management attention.

The dark turn happens when the metric stops being a signal and becomes a pressure handle.

Velocity is the easiest example. In Dark Scrum, velocity becomes a productivity target. If velocity goes down, someone wants an explanation. If velocity goes up, someone wants it repeated. If the team changes composition, work type, quality expectations, or technical context, the number still gets treated as if it should obey management desire.

When a metric becomes a control tool, people learn to manage the metric. They resize work. They split stories in ways that make the numbers look smoother. They avoid work that creates visible drag. They push quality work outside the metric. They protect the story the number is supposed to tell.

The organization may believe it has more transparency. In practice, it has made transparency less trustworthy.

This matters because the issue is not "metrics versus no metrics." That is too simple.

The issue is whether the metric helps the team and organization make better decisions, or whether it helps the organization apply pressure while pretending the pressure is empirical.

A useful metric improves judgment. A dark metric improves control.

Retrospectives Become Containment Or Improvement

Retrospectives are supposed to support improvement. Under Theory X assumptions, they often become containment.

The team gets a safe place to express frustration, but not enough power to change what keeps producing the frustration. The same issues appear Sprint after Sprint. Too much work enters the system. Priorities change without tradeoffs. Quality expectations are unclear. Interruptions keep breaking focus. Decisions happen outside the team and arrive as urgency.

People talk. People nod. People choose an action item small enough to survive the system.

After a while, the team learns the real rule: honesty is allowed as long as it does not create responsibility for anyone with power.

That is not continuous improvement. It is emotional ventilation with a process label.

In Bright Scrum, the Retrospective is a real inspection of the way of working. Some improvements belong to the team. The team can change how it slices work, coordinates, refines, pairs, reviews, tests, or makes risks visible.

But Bright Scrum does not pretend every problem is team-owned. Some problems are system conditions. If leaders keep overloading the team, shifting priorities without tradeoffs, ignoring quality debt, or rewarding starts over finishes, the Retrospective should make those realities visible.

Visibility is not the same as blame. It is the beginning of responsible management.

Theory Y does not say, "The team can solve everything." It says people can take responsibility when the system gives them real levers, useful feedback, and enough trust to tell the truth.

That is a much higher bar than asking a team to generate one tiny action item every Sprint.

Roles Become Control Channels Or Ownership Supports

The Scrum Master and Product Owner roles are supposed to help Scrum work. Under Theory X assumptions, they can become control channels.

The Scrum Master gets pulled into compliance monitoring: make sure the ceremonies happen, collect updates, chase Jira hygiene, enforce templates, and keep people behaving in the prescribed Scrum-shaped way. The Product Owner gets pulled into demand management: pass requests down, defend commitments up, keep the team loaded, and absorb stakeholder pressure.

Both can feel useful because they create order. But the order is narrow. The Scrum Master becomes a softer version of supervision. The Product Owner becomes a translation layer between stakeholder pressure and team capacity.

In Bright Scrum, the roles support ownership instead of replacing it. The Scrum Master helps the team and organization improve transparency, self-management, feedback, collaboration, and the removal of impediments. The Product Owner leads value by making ordering decisions, learning from feedback, clarifying goals, and collaborating with Developers so product judgment and delivery judgment inform each other.

That work can be uncomfortable. A Scrum Master may need to help leaders see how their behavior changes what the team is willing to make transparent. A Product Owner may need to tell stakeholders that not every request can be urgent, not every roadmap promise should survive new evidence, and not every Sprint should be loaded to capacity.

Bright Scrum does not need a Scrum Master who polices the team into Scrum.

It does not need a Product Owner who turns every demand into a delivery package.

It needs roles that help the organization stop using Scrum against itself.

This connects directly to the Agile value of customer collaboration over contract negotiation. In Dark Scrum, stakeholders negotiate for output. In Bright Scrum, the Scrum Team and stakeholders collaborate around value, learning, and adaptation.

The difference shows up when evidence changes the plan. If new learning can change the Product Backlog, Product Ownership is alive. If new learning only creates a new explanation for why the team is still expected to deliver the old plan, Product Ownership has been captured by control.

Self-Management Becomes A Slogan Or A System

Many organizations like the language of self-management more than the reality of it.

Self-management sounds modern. It sounds Agile. It sounds empowering. But it becomes hollow when the team has responsibility without decision space.

In Dark Scrum, the team is "self-managing" because nobody wants to admit that the important decisions are still controlled elsewhere. The team can decide how to do the work, as long as it accepts the work, timing, scope, priorities, constraints, tools, dependencies, and quality tradeoffs already imposed on it.

Then, when the plan fails, the team owns the failure.

That is not self-management. That is delegated blame.

Bright Scrum treats self-management as a system condition. The team needs clear goals, real constraints, access to feedback, a meaningful Definition of Done, and enough authority to adapt its plan. Leaders still matter. Management still matters. Product direction still matters. Constraints still matter.

But within those constraints, the team must have real room to make decisions.

Otherwise the language of ownership becomes another dark pattern. People are told they are empowered while the system removes the choices that empowerment would require.

Why This Pulls Scrum Dark

Scrum without Agile values and principles can keep the mechanics while losing the human assumptions needed for collaboration, trust, customer focus, and adaptation.

That is why the series formula still matters:

Scrum - Agile Values & Principles = Dark Scrum

If leaders believe people cannot be trusted with responsibility, Scrum's transparency becomes evidence. Events become control points. Metrics become pressure tools. Sprint Planning becomes commitment extraction. The Daily Scrum becomes status reporting. Retrospectives become containment. Self-management becomes a slogan.

The framework has not disappeared. The purpose has.

Scrum is still creating signals. But the system is using those signals to make control more efficient.

That is why Dark Scrum can feel so frustrating. It often uses the language of trust while operating from assumptions of mistrust. It asks teams to be transparent, then punishes what transparency reveals. It asks teams to take ownership, then denies meaningful decision space. It asks teams to improve, then leaves the system incentives untouched.

People notice that contradiction. They may not have the words for it, but they feel it.

After a while, they stop bringing the system the full truth. Not because they are lazy. Not because they hate accountability. Because they have learned what kind of truth the system can tolerate.

What Bright Scrum Does Instead

Bright Scrum starts from a different assumption.

People can take responsibility when the work is meaningful, the goals are clear, the constraints are honest, the feedback is real, and the system gives them enough room to act.

That belief does not remove accountability. It makes accountability more serious.

Bright Scrum shows up in operating choices:

• Goals are clear enough for real team decisions.

• Transparency is treated as shared reality, not evidence for blame.

• Metrics improve judgment instead of pressuring behavior.

• The Scrum Team has real decision space inside clear constraints.

• Impediments are treated as system information, not personal excuses.

• The Sprint Goal helps the team make tradeoffs.

• The Scrum Master helps improve the system instead of policing compliance.

• Product Ownership leads value instead of passing demand through.

Bright Scrum trusts people with responsibility, then makes the work visible enough to take that responsibility seriously.

That is not soft. It is demanding.

It asks leaders to stop confusing pressure with accountability. It asks teams to stop hiding behind vague empowerment. It asks Product Owners to make hard ordering decisions. It asks Scrum Masters to serve the purpose of Scrum, not just the appearance of Scrum. It asks Developers to be transparent about progress, quality, risk, and learning.

The result is not less accountability. It is accountability with more truth in it.

Bright Scrum is not "nice Scrum." It is more honest Scrum.

Diagnostic Questions

If you want to know whether Scrum is amplifying Theory X or Theory Y assumptions, do not start by asking whether people are nice or whether the team seems happy.

Look at how the system uses visibility.

• What do our Scrum events assume about people?

• Does the Daily Scrum belong to the team or to the status system?

• Where are we using visibility to help the team coordinate?

• Where are we using visibility to watch people?

• Are metrics helping decisions or applying pressure?

• What decisions can the Scrum Team actually make?

• What happens when the team names an impediment outside its control?

• Do leaders respond to transparency with curiosity or correction?

• Is self-management paired with real decision space?

• Are people held accountable for outcomes, learning, quality, and collaboration, or mostly for visible busyness?

The answers may be uncomfortable. That is useful.

Scrum is not only showing the work. It is showing the assumptions around the work.

What This Does Not Mean

This article can be misread in predictable ways, so the boundaries matter.

It does not mean managers are unnecessary. In many organizations, Bright Scrum requires stronger leadership because leaders have to create clarity, remove system impediments, make tradeoffs, and respond to transparency without turning it into punishment.

It does not mean accountability is bad. Weak accountability is not Bright Scrum. Avoiding hard conversations is not Bright Scrum. Letting work drift is not Bright Scrum.

It does not mean teams should be left alone without goals, constraints, or feedback. That is abandonment pretending to be empowerment.

It does not mean every team is automatically ready for every decision, and it does not mean trust replaces inspection. Capability grows. Trust can be built. Decision rights can expand as competence, clarity, and feedback loops improve.

Bright Scrum combines trust with transparency, feedback, and real responsibility. Trust without transparency gets vague. Transparency without trust gets dark.

What Comes Next

Assumptions about people connect closely to assumptions about uncertainty.

If leaders believe people must be watched and controlled, uncertainty starts to look like a threat. A changed forecast looks like failure. A newly discovered risk looks like poor planning. A Sprint Review that changes the Product Backlog looks like instability. A Retrospective that names a system constraint looks like complaining.

That is where Scrum gets pulled toward false certainty. Sprint Planning becomes a commitment ritual. Forecasts become promises. Metrics become defense. The Product Backlog becomes a place to pretend the future is more knowable than it is.

That is the next force to inspect: uncertainty intolerance.

For now, the diagnostic is simple:

Dark Scrum uses visibility to control people. Bright Scrum uses visibility to help people own the work.

Next Step

Many Scrum teams do not struggle because they skipped the mechanics. They struggle because the mechanics are used inside systems that still reward surveillance, compliance, and pressure over ownership, learning, and responsible adaptation.

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, 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

• Douglas McGregor, The Human Side of Enterprise, source for Theory X and Theory Y management theory