The confusion between Agile and Scrum is understandable. Both terms are used constantly in product development, both relate to iterative working, and both emphasise collaboration and responsiveness over rigid planning. They also appear together so often in job descriptions, certifications, and conversations that it is easy to assume they are the same thing.

They are not, and understanding the difference matters practically — not just conceptually.

What Agile is

Agile is a philosophy: a set of values and principles about how to approach complex, uncertain work effectively. It is expressed most directly in the Agile Manifesto, written in 2001 by a group of experienced software practitioners who had concluded that the dominant project management approaches were producing poor results.

The four values — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan — describe a way of thinking about work rather than a way of organising it. Agile does not tell you what meetings to hold, what roles to create, or what artefacts to produce. Those are questions of method, and Agile is not a method.

What Scrum is

Scrum is a specific, structured method for organising work in a way that is consistent with Agile values. It was developed by Jeff Sutherland and Ken Schwaber in the early 1990s and is now probably the most widely used agile framework in software development.

Scrum is defined and prescriptive in a way that Agile is not. It specifies three accountabilities (Scrum Master, Product Owner, Developers), five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and three artefacts (Product Backlog, Sprint Backlog, Increment). These are not optional elements — removing them produces a different method that may or may not be Agile, but is no longer Scrum.

The key relationship

Scrum is always Agile — by design. Everything about Scrum is consistent with the Agile Manifesto: the short feedback cycles, the emphasis on working software over documentation, the self-organising teams, the continuous improvement built into the Sprint Retrospective.

But Agile is not always Scrum. Kanban, Extreme Programming, Crystal, and many other methods are also consistent with Agile values but look completely different from Scrum. An organisation that uses Kanban to manage its work is not using Scrum, but it is — if it is using Kanban well — working in an Agile way.

Which to use

The choice is not between Agile and Scrum — you cannot really "use Agile" as a method. The choice is which agile method best fits your context.

Scrum is particularly suited to teams building products iteratively where regular stakeholder feedback is valuable and where the scope of work is manageable in two-week cycles. It provides enough structure to be accessible for new teams and enough flexibility to be adapted for experienced ones.

Kanban is often a better fit for teams with continuous, mixed-flow work — where the idea of fixed-length sprints would create artificial rhythm that doesn't match how work actually arrives. Support teams, operations teams, and teams doing ongoing maintenance often find Kanban a more natural fit than Scrum.

Both are Agile. Which one you choose should depend on what your work actually looks like — not on which one has the more recognisable certification pathway.