Insight
Demystifying Agile & Scrum myths
"True agile means Scrum." The terms get used interchangeably in almost every organisation I've worked with. Before that debate can go anywhere useful, the terms need unpacking — because they operate at entirely different levels.
Agile is a strategic orientation: a set of values and principles that help organisations adapt and deliver value continuously. Scrum is one specific framework — tactical, structured, with defined roles, ceremonies, and artefacts — for realising those values inside a team. A chicken is a bird, but being a bird does not make something a chicken. Scrum is agile. Being agile does not make a team Scrum.
"True agile means Scrum."
There are other frameworks — Kanban, XP, LeSS, SAFe — each placing different bets on how best to achieve agility in a given context. Scrum itself predates the 2001 Agile Manifesto by roughly a decade. The Manifesto didn't create Scrum; it gave a shared language to the family of approaches Scrum belongs to.
Choosing is an engineering question
Choosing between them is not a philosophical question. It is an engineering one. The right questions are about scalability, flexibility, delivery cadence, team complexity, and risk tolerance. Scrum works exceptionally well in many contexts. It does not work in all of them, and pretending otherwise is how organisations end up running ceremonies that nobody believes in.
Before adopting or replacing a framework, understand why the previous choice was made — the history is usually instructive. Then assess whether an evolutionary improvement to the current approach would suffice, or whether a more fundamental shift is warranted. That distinction matters: revolutionary changes require broader stakeholder alignment, structured risk assessment, and time. The goal is not a framework. The goal is better delivery.
Something in here resonate?
If your team is running ceremonies nobody believes in, that's usually the one thing worth fixing first.
Let's talk