Agile vs Scrum: why it is not an either-or choice
The most common misconception in agile project management sounds like this: “do we choose Agile or Scrum?”. That question contains a category error — Agile and Scrum do not sit on the same level.
- Agile is a philosophy and a mindset — a set of values and principles described in the Agile Manifesto (2001).
- Scrum is a concrete framework that implements those values in a team’s daily work.
The relationship is one-directional: every Scrum is Agile, but not every Agile is Scrum. Under the Agile umbrella you will also find Kanban, Extreme Programming (XP), Lean, and scaled approaches such as SAFe and LeSS. That is why the meaningful question is not “Agile or Scrum”, but rather: “which implementation of Agile should I choose for my team — and is Scrum the right one?”.
What Agile is — a philosophy, not a method
Agile is a way of thinking about delivering value under uncertainty. It is defined by:
The 4 values of the Agile Manifesto (the item on the left matters more):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a rigid plan
On top of that come the 12 principles — among them frequent delivery of working increments, openness to changing requirements, regular team reflection, and a sustainable pace of work.
The key point: Agile does not say how long an iteration should last, which roles to introduce, or which meetings to hold. This generality is deliberate — and at the same time the reason why Agile on its own can be too abstract in practice. A concrete framework is needed.
What Scrum is — the framework that implements Agile
Scrum translates the Agile values into a repeatable structure of work, made up of three elements:
3 roles (accountabilities):
- Product Owner — accountable for product value and priorities in the Product Backlog.
- Scrum Master — ensures the team’s effectiveness and the proper use of Scrum.
- Developers — the team delivering the increment within the sprint.
5 events:
- Sprint — a cadence of 1-4 weeks in which a Done increment is created.
- Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
3 artifacts: Product Backlog, Sprint Backlog, Increment (with a Definition of Done).
Scrum is lightweight yet complete — it gives clear structure, which makes it easy to start. The risk lies in adopting the rituals alone without understanding the Agile values — that produces ‘mechanical Scrum’, where there are meetings but no agility.
Comparison table — different levels, not competitors
| Aspect | Agile | Scrum |
|---|---|---|
| What it is | Philosophy / mindset | Framework implementing Agile |
| Level | ’Why and by which values' | 'How to organise the work concretely’ |
| Source | Agile Manifesto (2001) | Scrum Guide (Schwaber, Sutherland) |
| Roles | Does not define | Product Owner, Scrum Master, Developers |
| Iterations | Recommends frequent delivery | Sprints of 1-4 weeks |
| Events | Does not define | 5 events (Planning, Daily, Review, Retro, Sprint) |
| Scope | Umbrella for many frameworks | One of the implementations of Agile |
| Metrics | None imposed | Velocity, Sprint Burndown, Sprint Goal |
Agile is more than Scrum
Since Scrum is only one of the paths, it is worth knowing the alternatives in the Agile family:
- Kanban — continuous flow of work, work-in-progress (WIP) limits, no rigid roles; ideal for operations and maintenance teams where work arrives unpredictably.
- Extreme Programming (XP) — engineering practices: pair programming, TDD, continuous integration.
- Lean — eliminating waste and optimising the flow of value.
- Scaling (SAFe, LeSS) — adopting agility across many teams and entire organisations.
Increasingly popular is also Scrumban — a hybrid that combines the structure of Scrum with the flow and WIP limits of Kanban.
When Scrum, and when Agile in the broader sense
- Choose Scrum when: you work on a product with defined goals, you can plan in sprints, and the team needs clear roles and rhythm. This is the most common choice for product teams.
- Choose Kanban (or another Agile framework) when: work arrives as a continuous, unpredictable stream (support, DevOps, maintenance) and rigid sprints would make it harder to respond.
- Stay with ‘pure Agile’ at the organisational level when: you are building a culture and values, and you leave the choice of a specific framework to individual teams.
In practice, most organisations combine the levels: Agile values as the foundation, Scrum or Kanban as the operational framework, and over time some fine-tuning (e.g. Scrumban).
Certification and training path
It is best to structure your learning from foundations to specialisation:
- Agile foundations — a broad introduction to the philosophy and practices of Agile through real examples.
- Specialisation in Scrum — the Scrum Master role (Professional Scrum Master) or Product Owner (Professional Scrum Product Owner) with an accredited exam.
- Broader agile project management — e.g. AgilePM Foundation, combining agility with the discipline of project management.
This way you do not learn ‘rituals detached from meaning’; instead you first understand the Agile values and then implement them with a concrete framework. You will find related EITT trainings below.