The Hidden Philosophy of Scrum’s Values (And Why the Framework Never Admits It)

A close reading of two paragraphs from the Scrum Guide reveals Kant, Foucault, Rousseau, and Sartre hiding in plain sight

Somewhere in the Scrum Guide, tucked between the description of the Daily Scrum and the definition of a Sprint Backlog, sits a passage most practitioners skim past on their way to the “real” content. It reads like corporate poetry; commitment, openness, respect, courage, the kind of language you’d expect on a motivational poster in a co-working space.

But read it slowly, and something strange happens. You start noticing Kant. Then Foucault shows up. Rousseau’s ghost is lurking in the sentence structure. And by the end, you’re staring at a 250-year-old argument about freedom that a project management framework never signed up to have.

Here’s the passage in question:

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.

These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life, building trust.

On the surface, this is harmless. Underneath, it’s a philosophical minefield. Let’s walk through it.

1. The Trust Paradox: A Circle That Never Closes

The text claims that when the values are “embodied,” transparency and inspection “come to life,” building trust. It sounds like a logical sequence: values → practices → trust.

Except trust isn’t waiting at the end of that chain. It’s required at the very start.

Nobody admits a problem in a Daily Scrum, nobody says “I’m stuck” or “I made a mistake,” without already trusting that the disclosure won’t be used against them. Openness doesn’t produce trust from nothing — it requires a baseline of trust just to happen at all.

This is the same structure Hans-Georg Gadamer described as the hermeneutic circle: you can’t understand a text, a person, or a situation without already bringing some prior understanding to it. Understanding isn’t a straight line from ignorance to knowledge — it’s a spiral, where each step both depends on and revises what came before.

The Scrum Guide writes trust as an output. In reality, it’s the entry fee.

2. “The Courage to Do the Right Thing” — According to Whom?

This is the line that should make every reader pause. Courage to do the right thing. It sounds unimpeachable. It’s also almost entirely empty.

Right according to what standard? The team’s? The client’s? The organization’s quarterly targets? The Scrum Guide never says — and that’s not a small omission, it’s the entire problem moral philosophy has been arguing about for millennia.

• Aristotle would say courage (andreia) isn’t a rule you follow, but a mean between cowardice and recklessness, calibrated by phronesis — practical wisdom developed through lived judgment, not a poster on the wall.
• Kant would say the “right” isn’t determined by group consensus at all, but by whether the underlying maxim of your action could be willed as a universal law.

Scrum borrows the word courage without borrowing any of the philosophical machinery that would make the word mean something. What’s left is a slogan — inspiring, vague, and conveniently unfalsifiable. If a sprint goes badly, was it a lack of courage? Who decides?

3. Respect, Kant, and the Irony Nobody Talks About

Here’s where it gets genuinely interesting. The line about respecting team members as “capable, independent people” is almost a direct paraphrase of Kant’s second formulation of the categorical imperative: treat people always as ends in themselves, never merely as means.

That’s a serious philosophical commitment to smuggle into a process framework. And it exposes a real irony: in most organizations, Scrum artifacts — velocity charts, burndown graphs, story point estimates — end up treating people almost entirely as means to throughput. The framework preaches Kantian dignity while its instrumentation quietly does the opposite.

The Guide never resolves this. It just states the ideal and leaves the contradiction for someone else to notice.

4. Transparency Is Never Neutral — Ask Foucault

“The Scrum Team and its stakeholders are open about the work and the challenges.” Fine. But Michel Foucault spent a career demonstrating that visibility is never innocent.

In Discipline and Punish, Foucault describes the panopticon — a prison design where inmates can be watched at any moment without knowing when, so they eventually start watching themselves. The mechanism doesn’t need an active observer to work. The possibility of being seen is enough to produce discipline.

A daily standup, a visible kanban board, a burndown chart on a shared screen — these are transparency tools, yes. But they’re also surveillance infrastructure. Over time, “openness” can quietly shift from a mutual, chosen vulnerability into something closer to constant self-monitoring: team members regulating themselves because they know they’re always potentially observed.

Foucault called this dynamic governmentality — power that doesn’t need to punish, because it has already trained people to police themselves.

5. How Capitalism Learned to Sell You Your Own Liberation

There’s a book that explains, almost too perfectly, what’s happening in this passage: The New Spirit of Capitalism by Luc Boltanski and Ève Chiapello. Their argument is that capitalism survives criticism by absorbing it — taking the language of 1960s liberation movements (autonomy, creativity, authenticity, self-direction) and repackaging it as a management tool.

Scrum is a textbook case. “Self-organizing team.” “Commitment.” “Ownership.” These sound emancipatory. In practice, they often function as a transfer mechanism: when a sprint fails, the story isn’t “the organizational structure was flawed” — it’s “the team wasn’t committed enough, wasn’t courageous enough, didn’t own it enough.” Responsibility moves downward, onto the individual, dressed in the language of empowerment.

This is what sociologists call responsibilization — and it’s precisely why values statements like this one can feel both inspiring and faintly suspicious at the same time.

6. Where the Empirical Pillars Actually Come From

The paragraph mentions team members “learning and exploring the values” through Scrum events — which is pure John Dewey. Dewey’s pragmatism argued that values and knowledge aren’t fixed truths handed down in advance; they’re discovered and revised through action, through doing.

But notice what this reveals about the famous “three pillars” — transparency, inspection, adaptation. That’s not philosophy. That’s Deming’s PDCA cycle (Plan-Do-Check-Act), which itself descends from Norbert Wiener’s cybernetics — feedback-loop control theory built for machines and manufacturing systems.

Scrum dresses an engineering control loop in the language of Deweyan personal growth. It’s a strange, oddly effective hybrid: half factory-floor process control, half humanist self-discovery narrative.

7. Rousseau’s Unsolved Problem, Rebooted for Sprint Planning

There’s a tension sitting quietly between the first and second sentences of the passage: the team commits collectively to its goals, yet members are respected as independent individuals.

This is not a new problem. It’s Rousseau’s, from The Social Contract: how can a person submit to the “general will” of the group while remaining free? Rousseau’s answer was the infamous, endlessly debated phrase — people can be “forced to be free.”

Scrum doesn’t even attempt a resolution. It just states both halves of the contradiction as if they were obviously compatible, and trusts the team to work it out in practice. Sometimes they do. Often, this is exactly where team conflict actually lives.

8. Prescribed Courage Is a Contradiction in Terms

Last point, and maybe the sharpest one. Sartre argued that authentic action requires facing the anxiety of freedom head-on — deciding, without a script, and owning the consequences. That’s what he meant by authenticity.

But courage that’s assigned to you by a framework — “you must have courage” — isn’t really courage anymore. It’s compliance wearing courage’s clothes. Sartre had a name for this too: bad faith (mauvaise foi) — performing freedom while actually just following an externally imposed role.

There’s something almost funny about a values statement instructing people to be spontaneously brave. Real courage, by definition, can’t be a checklist item.

So What Do We Do With This?

None of this means Scrum is a scam or that its values are cynical. The values are genuinely good ones — commitment, openness, respect, courage, focus. The problem is that the Scrum Guide states them as though they’re self-evidently coherent, self-sustaining, and free of the tensions that philosophy has spent centuries mapping in painstaking detail.

They’re not. And that’s fine — as long as the people using the framework know it.

A team that understands the trust paradox won’t expect openness to appear before psychological safety does. A team that understands the Foucauldian dimension of transparency will design standups that feel like support, not surveillance. A team that understands the Rousseauian tension between commitment and autonomy will stop being surprised when “self-organizing” and “aligned” pull in different directions.

The Scrum Guide gives you the values. It doesn’t give you the instruction manual for the contradictions hiding inside them. That part, apparently, is on us.

If you work with Scrum — or any framework that borrows the language of values without doing the philosophical work behind them — which of these tensions do you actually see playing out on your team?