Dark/Bright Scrum 01: From Bright Ideas to Dark Systems

The cubicle is one of the easiest office jokes in the world. Say the word and people can see it: gray walls, bad light, a little rectangle of carpet, the soft hum of work that has been divided, assigned, monitored, and drained of life. The cubicle has become shorthand for a certain kind of organizational failure, not the dramatic kind, but the worse kind: normalized failure that everybody learns to work around.

That is what makes the cubicle story useful. It did not begin as a joke. It began as a bright idea.

Robert Propst was not trying to invent a corporate cage. In the 1960s, while working with Herman Miller, he studied office work and saw that the standard office was not built for how people actually thought, collaborated, concentrated, or moved through a day. The Action Office was meant to create a more flexible workspace with different surfaces, different postures, more customization, and more room for the individual human being inside the system. The original promise was simple: the office should adapt to the person doing the work.

Then the system got involved.

How a Bright Idea Went Dark

The first version of the Action Office did not fit how large organizations bought and scaled office furniture. It was too expensive, too unusual, and too hard to reduce to a repeatable purchasing pattern. Action Office II changed that. Panels made the system easier to assemble, repeat, and reconfigure, which made it easier to sell and easier to misuse.

Organizations saw something different from what Propst intended. They did not see a human-centered system for better work. They saw a way to divide floor space, fit more people into less room, and make workstations replaceable, movable, and standardized. Add knockoffs, cost pressure, and tax incentives for depreciable office furniture, and the bright idea became a box.

The system kept the panels and lost the purpose.

That is how good ideas go dark. Not all at once. Not because everyone involved is malicious. Not because the original idea was stupid. Good ideas become dark when organizations preserve the visible mechanics and abandon the values that made those mechanics useful in the first place.

That contrast matters for Scrum. Bright systems protect purpose. Dark systems protect mechanics.

Scrum Can Drift the Same Way

Scrum did not begin as a way to make teams miserable. It did not begin as a calendar full of status meetings, a velocity pressure system, or a ceremony package for managers who want more frequent updates. It did not begin as a way to make uncertainty look fake-manageable. Scrum begins with a better promise: make work visible, inspect reality frequently, adapt based on what is learned, bring people closer to the customer, and give teams enough structure to learn without pretending complex work can be perfectly predicted in advance.

Those are good ideas, but good ideas are not self-protecting. A Daily Scrum can help a team coordinate around a shared goal, or it can become a daily accountability ritual where people report upward and learn to protect themselves. Sprint Planning can help a team make a serious forecast under uncertainty, or it can become a commitment trap where the plan matters more than what the team discovers. A Sprint Review can bring real users, customers, stakeholders, and team members into useful conversation, or it can become demo theater where everyone politely watches work that was already decided somewhere else.

A Retrospective can help the team improve the system, but it can also become a venting meeting where the team names the same problems every two weeks because nobody with power changes the conditions. The mechanics are not enough. That is the first hard lesson of Dark Scrum.

Scrum Is an Amplifier

Scrum does not replace your management system. It reveals it. In a high-trust system, transparency helps people learn; in a low-trust system, transparency becomes surveillance. In a learning system, a Sprint Goal helps people make better tradeoffs; in a control system, the Sprint Goal becomes a slogan pasted over a list of tasks. In an adaptive system, a forecast is a working hypothesis; in a fear-based system, a forecast becomes evidence for blame.

This is why Dark Scrum and Bright Scrum can use the same basic mechanics and produce completely different experiences. Bright Scrum keeps the purpose alive. It uses Scrum to support learning, adaptation, focus, trust, and better decisions under uncertainty. Dark Scrum keeps the visible practices and loses the purpose. It uses Scrum to make control more efficient.

That is the cubicle pattern. The system takes something designed to help people work better and reshapes it around what the system already values: density, predictability, compliance, reporting, and control. The language may still sound modern and humane. The experience tells the truth.

This Is Bigger Than Scrum

This is not only a Scrum problem. Open offices started as a promise of collaboration and energy; in many places, they became noise, interruption, and the disappearance of private thought. OKRs can help people align around outcomes; they can also become another quarterly pressure machine where people reverse-engineer numbers to satisfy leadership.

Dashboards can help teams see reality, but they can also become instruments of theater. The metric becomes more important than the work. AI tools can help people move faster, think differently, and reduce drudgery; they can also flood the system with outputs nobody has the time, context, or courage to judge.

The thing itself is rarely the whole problem.

The question is what your system will do to it. Organizations rarely corrupt a useful practice by announcing the corruption. The drift sounds reasonable. It sounds like efficiency, consistency, standardization, and accountability. Sometimes those things are useful. Sometimes they are the language a dark system uses to explain why the bright idea had to be made smaller.

The Diagnostic Question

If you want to know whether Scrum is becoming bright or dark, do not start with whether people are following the events correctly. Start with what the events are doing.

Are ceremonies creating better decisions or just more reporting? Does transparency help the team adapt, or does it help managers assign blame? Does planning help people act responsibly under uncertainty, or does it pretend uncertainty has disappeared? Do retrospectives change the system, or do they only ask the team to cope better?

Then widen the question beyond Scrum. What other shiny new thing in your organization started as a way to help people work better, then became another control mechanism? Did you keep the purpose, or only the visible mechanics? Did the practice increase learning, autonomy, and better judgment, or did it create more dashboards, meetings, checklists, and pressure?

The useful test is whether the practice is still serving the work. If the work has been reshaped to serve the tool, the tool has already won.

That is not a tooling problem. It is a management system problem wearing a tool badge.

Bright Scrum Has to Protect the Purpose

Bright Scrum is not softer Scrum. It is not nicer meetings, happier sticky notes, or a friendlier vocabulary. Bright Scrum is Scrum with its purpose protected.

Transparency is for learning. Planning is for responsible adaptation. The Daily Scrum is for team coordination. The Sprint Review is for feedback and shared understanding. The Retrospective is for improving the system.

Not for asking people to survive the same broken system with a better attitude.

Once those purposes are lost, the mechanics can keep running for years. The calendar still looks like Scrum. The board still looks like Scrum. The language still sounds like Scrum. The team knows something has changed, even if they do not have the words for it yet.

They feel the difference between visibility that helps and visibility that watches. They feel the difference between focus and pressure, adaptation and re-planning theater, a retrospective that changes the system and one that politely documents pain. That difference is the beginning of this series.

Dark Scrum protects the mechanics.

Bright Scrum protects the purpose.

Same Scrum. Different experience.

Before you move on, ask one practical question: where has your organization kept the mechanics of a bright idea but lost the purpose? It might be Scrum. It might be OKRs, dashboards, AI, or some other useful tool that got absorbed by the management system around it. Name the practice, name what it was supposed to help people do, and then look honestly at what it rewards now.

If this made you recognize a place where Scrum mechanics have drifted away from Agile intent, keep going with the Lean/Agile articles. If you want to learn what Bright Scrum looks like in practice, join one of our Certified ScrumMaster courses, where we connect Scrum mechanics back to trust, adaptation, transparency, and real team learning.

Source

Erin Blakemore, "Why the Inventor of the Cubicle Came to Despise His Own Creation," History.com, https://www.history.com/articles/why-the-inventor-of-the-cubicle-came-to-despise-his-own-creation