Three Relationships with a Framework
Before I say when a frame becomes a cage - we need to talk about how we enter it in the first place. Because there are several entrances. And each comes with a price.
By the book
The Scrum Guide says a sprint lasts from one to four weeks. At one company I got the answer: “We do two weeks because that’s what the book says.” Fine. I asked: “And what do you deliver after those two weeks?” Silence. Then: “Well… we work.”
That is the “by the book” relationship. Precision in form, deaf silence on purpose.
What it gives:
- A shared language - everyone knows what a Sprint Review is
- Safety - “we do it as the Guide says, we can’t be blamed”
- Structural predictability
What it costs:
- Energy goes into observing rituals, not into value
- Every deviation from the “manual” becomes a problem to solve
- The team starts asking “is this Scrum-compliant?” instead of “does this work?”
From scratch
I once worked at a company where the Product Owner said: “Scrum slows us down, we do it our own way.” And indeed - they built their own process. Agile, tailored, effective. For six months. Then the company grew. New people joined. And it turned out “our own way” was encoded in the heads of three original team members, and nobody could pass it on.
The “from scratch” approach has real value - it forces you to think. To ask “why?”. But “from scratch” can also mean cutting yourself off from others’ mistakes… and from others’ solutions to those mistakes. Someone has already been through this. Someone paid for that lesson. Maybe it’s worth using?
What it gives:
- Ownership of the process - truly yours, not someone else’s
- No blind trend-following
- Authentic flexibility
What it costs:
- You reinvent the wheel - often a crooked one
- You waste time on experiments someone ran twenty years ago
- Scalability becomes a nightmare because “your system” lives only in people’s heads
With understanding
This is the third way. And the hardest - not because it requires more knowledge, but because it requires more courage to ask questions.
I saw this in a team in the oil sector (yes, coaching outside of IT is a different adventure). The leaders understood what Sprint Review was for - not because “the Scrum Guide says so,” but because they needed a regular feedback loop from the business. When one of the stakeholders disappeared for two months, they didn’t cry over “non-compliance with the framework.” They designed an alternative mechanism. And returned to the Review when the stakeholder came back. A means. Not an end.
What it gives:
- Framework as a tool, not as a dogma
- Flexibility without chaos
- The ability to modify without losing meaning
What it costs:
- A constant need to explain “why” - especially to new people
- The risk that “with understanding” becomes an excuse for “whatever is convenient for me”
- More conversations, less work on autopilot
When a Framework Becomes a Cage
There are signals. A few concrete ones, from the battlefield.
Ritual without purpose. “We do a retrospective on Friday.” Great. What have you changed after the last five retros? Silence. We do retro because “that’s how it’s done in Scrum.” A ceremony without effect. Process theater.
Defending the process, not the value. “We can’t shorten the sprint, we have two weeks.” Why two weeks? “Because that’s how we started.” When did you last ask whether that pace still serves your product?
Measuring framework compliance, not outcome. At one company they had a “Scrum Maturity Level” on their dashboard. Eighteen out of twenty. I was impressed. I asked about Time to Market - they don’t measure it. About NPS - they don’t measure it. About whether users actually use what they deliver. They looked at me like I was an alien.
When does a framework become a cage? When you ask “are we doing this in accordance with the framework?” instead of “does this serve us?” Subtle. But once it becomes a habit - it can freeze an entire organization.
First Principles Thinking - What It Really Looks Like
“First principles thinking” - sounds like something from a TED conference. Elon Musk. Batteries. Blah blah. In practice? It’s simply breaking a problem down into smaller parts. And asking “why?” at each one - until nothing is left that you take on faith. Instead of “because others do it that way.”
It looks like this…
I worked with a leader of a large business unit at an insurance company. A year into transformation. Scruming by the book. And they had a problem: Sprint Review looked like a management presentation, not a feedback loop.
I asked: “What is the Sprint Review for?”
“Well… because the Scrum Guide says so.”
“Okay. But if the Scrum Guide didn’t say so - why would you do it? What do you need after each sprint?”
Silence. Then:
“Actually, I need to know whether what we’ve built is going in the right direction.”
“And how do you know now?”
“I don’t know.”
Three questions. And he already knew he had a management-demo, when what he needed was a learning-mechanism. Those are two different things. The framework gave him a tool. He had to understand what to use it for.
First principles thinking is not about throwing frameworks out. It’s about understanding what problem a framework solves - and whether your problem is the same problem. Sometimes it is. Sometimes it isn’t.
My Favorite Moment
I have a favorite moment in my work with organizations. It’s not the moment when a team successfully implements Scrum. Not when they complete all the ceremonies. Not when they reach “Scrum Maturity Level 18/20.”
My favorite moment is when someone - a leader, a Scrum Master, a Product Owner, a developer - says:
“Listen, this makes no sense. Why are we even doing this?”
That is the moment. When the framework stops being sacred.
But watch out - this moment doesn’t come out of nowhere. It is usually preceded by frustration. A few sprints that we “completed,” but delivered nothing. A few retros after which nothing changed. A few Dailies where everyone said “all good on my end,” and the sprint ended in failure. When the frustration is big enough - the question appears. And that question is the beginning of real work.
What follows? Depends. Sometimes a conversation that lasts two hours and ends with: “OK, so how do we actually want to work?” Sometimes changing one ceremony to see if something improves. Sometimes a conscious decision that this part of the framework doesn’t serve them.
Conscious. That’s the key.
Not “we don’t do retro because there’s no time.” But: “we don’t do retro in this form, because it brings us no value - instead we do X.” The difference is enormous. In the first case the framework falls apart without a plan. In the second - it evolves with understanding.
The Wednesday 2 PM Test
Scrum itself says it’s a “lightweight framework.” That’s true. It is lightweight. We are capable of turning it into a concrete wall.
I don’t blame anyone for that - I went through it too. I had my “by the book” phase, I had my “throw everything out and start over” phase. Maturing into the third relationship - the one with understanding - takes time and requires making significant mistakes.
But there is one simple test. You can do it in the middle of a week full of meetings, even without a flipchart.
Take one event from the upcoming sprint - Daily, Review, Retro, Sprint Planning - and ask yourself:
Am I doing this because I understand why - or because “that’s how it’s done”?
And if that answer is honest… you know what to do next.
So - does your framework support you today, or are you the one serving it?