Home → Part 01
Being Agile vs Doing Scrum
Can a team run every ceremony flawlessly and still not be agile? Not only is it possible — it is the most common thing I see in the field.
- Agile is not a framework, it is a way of deciding. The Scrum Guide describes roles and events; what to do in a hard moment comes from the spirit of the Manifesto.
- The goal is not to avoid being wrong, but to avoid being wrong late. Shipping the wrong product after six months is a disaster; saying "we are on the wrong track" after two weeks is learning.
- Agile does not end the chaos, it exposes it. The first sprints look worse — because problems can no longer be hidden.
- The ceremonies are a chain. Fixing one in isolation rarely works; the broken link is usually one step earlier.
Your real problem is not a ski trip in 2001
Most articles on Agile open with seventeen people meeting in Utah in 2001. The story is true, but it is not your problem. Your problem is the backlog you open on Monday morning, a requirement that changed three times in two weeks, an item that has been "in progress" for three days, and the question asked in the meeting: "Why have we still not shipped this?"
This series is about that question. Each part takes one ceremony. But first one thing has to be settled, because everything else rests on it: doing Scrum and being agile are not the same thing.
1. Why Agile? Against the illusion of prediction
Plan-first approaches rest on a single assumption: that we can predict the future accurately enough at the start. The assumption is comforting, because you end up holding a date and a budget. The trouble is that the comfort comes from a document, not a measurement.
Agile does not promise a better prediction. It lowers the cost of being wrong. Two-week cycles will not make your estimate accurate; they will make sure that when you are wrong, you find out in two weeks instead of six months.
2. The Manifesto is a decision frame, not a prayer
The four values were not written to be hung on a wall. They were written for the moments when you have to choose. In practice they translate like this:
| Value | What it means in the field |
|---|---|
| Individuals and interactions | More valuable than a status field in Jira is someone being able to say in the daily: "I am stuck, I need help." |
| Working software | Nobody reads the hundred-page analysis document. A clickable screen produces real feedback. That is why Sprint Review exists. |
| Customer collaboration | The point is not to write down what we agreed, but to be sure we understood the same thing. |
| Responding to change | Sprint Planning is permission to correct course at regular intervals. Not "no plan" — "not a prisoner of the plan". |
3. The part nobody mentions: it gets worse first
In teams moving to Scrum, the first few sprints usually go worse. The reason is not that they are doing it wrong. The reason is that Agile does not solve problems, it makes them visible.
- A retrospective is a place to improve the process, but early on it feels personal.
- Telling a customer "the sprint has started, let us take this in the next one" is hard.
- Short cycles increase context switching; the team constantly asks and waits.
These are not the disease, they are the fever. Instead of suppressing the fever, look for the cause — and the cause is almost always one step earlier in the chain.
4. A practical scenario: a production bug mid-sprint
This is one of the questions the Scrum Guide does not answer. Our decision tree — derived from the Manifesto rather than from the book — works like this:
- Impact analysis. How many users, what is the business impact? If small, defer it deliberately and put it in the backlog.
- Sprint goal check. Can it be fixed with small effort without breaking the goal? If yes, fix it — but make it visible.
- Trade-off. If it will break the sprint, the right question is not "shall we work late" but "what are we taking out to make room for this?" Decide it with the PO.
- Stop the sprint. If the bug is large enough, be honest: cancel, fix, re-plan. That is a decision, not a failure.
My own addition: whichever option you take, write down the decision and its reason in one sentence. Six months later, whoever asks "why did that sprint blow up" (usually you) will look for that sentence. Teams that skip this have the same argument again every quarter.
5. Why Scrum? Choosing a frame
Scrum is not the only option, and not the right one for every team. Roughly:
| Framework | Focus | When |
|---|---|---|
| Scrum | Complexity and delivery | Product work with high uncertainty |
| Kanban | Continuous flow | Operations, support, externally driven priorities |
| XP | Engineering quality | When TDD, pairing and technical excellence come first |
In practice most teams run a hybrid: a Scrum skeleton, a WIP limit borrowed from Kanban, pairing borrowed from XP. That is not inconsistency; it is fitting the problem rather than the book.
6. Agile is a constitution, not a legal code
A legal code enumerates every case. A constitution gives principles and leaves the interpretation to the people applying it. The Scrum Guide is the second kind: it defines roles and events but does not answer every problem you will meet — nor should it be expected to.
If you try to resolve every question by asking "does Scrum say so?", the result is predictable: you will do Scrum and fail to be agile.
- Base decisions on principles, not clauses
- Deliver bad news early — early bad news is a risk, late bad news is a failure
- Adapt the process to the team and write down why you adapted it
- Do not claim you improved something you never measured
- Treat the number of meetings as a measure of agility
- Apply process to protect yourself rather than to solve a team problem
- Freeze whenever an exception is not covered by the guide
- Read early turbulence as "Agile did not work for us"
A five-question honesty test
Ask these five to find out whether your team is genuinely agile. If you cannot answer yes to all of them, you have probably adopted the process without changing the behaviour.
- Have we cancelled a planned piece of work in the last three months? (Never cancelling means never learning.)
- Can a junior challenge a senior's technical decision in a meeting?
- Does bad news soften on its way up, or arrive intact?
- Did at least one action from the last retrospective actually happen?
- Can everyone state the sprint goal without looking it up?
Conclusion
Agile does not end the chaos; it makes it manageable. It does not stop you making mistakes; it stops you noticing them late. The first months are hard, retros are tense, sprints spill over. Those are signs that the process is working, not that it is broken — because you simply were not seeing any of this before.
The rest of the series takes the ceremonies one at a time. Next up is the first link in the chain: how work gets filtered before it ever reaches the team.
The skeleton of this series and many of its ideas are inspired by İbrahim Demir's Agile series. The text is mine; the additions and changes come from my own team experience. The Scrum Guide (2020) and Robert C. Martin's Clean Agile are the base references.