The word "agile" refers to the ability of a system to adapt and respond quickly to change. In the context of product development and organisational work, Agile (capitalised) refers to a philosophy and set of values that shape how teams approach complex, uncertain work.

It is worth being precise about what Agile is and is not, because conflating it with its implementations produces confusion that gets in the way of using it well.

What Agile actually is

Agile is a philosophy — a set of values and principles, not a process. The Agile Manifesto, written in 2001, articulates four core 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

These are not instructions for how to run a meeting or structure a team. They are statements about what matters most when trade-offs arise — which is the form a philosophy most usefully takes.

The manifesto was followed by twelve principles that elaborate on these values: delivering frequently, welcoming changing requirements, building around motivated individuals, maintaining a sustainable pace, and so on. Together, the values and principles describe a way of thinking about work rather than a set of practices to follow.

What Agile is not

Agile is not a methodology — it does not specify how to organise your team, what meetings to hold, or what artefacts to produce. That is what frameworks are for. Agile frameworks — Scrum, Kanban, XP, and others — are specific, structured approaches to implementing Agile values in practice. They vary considerably in their prescriptiveness and their suitability for different contexts.

The most important practical implication of this distinction: when someone says "we use Agile," they have said very little about how they actually work. When someone says "we use Scrum," they have said something specific. The question "which Agile framework?" is usually the more useful one.

Agile methodology

The phrase "Agile methodology" is widely used to refer to the practice of iterative, incremental development — delivering working products in short cycles, incorporating stakeholder feedback frequently, and continuously improving both the product and the process. This is a reasonable shorthand for a family of related approaches, even if it blurs the distinction between values and methods.

Key characteristics of Agile working:

• Iterative delivery — working in short cycles rather than large releases, allowing learning and adjustment to happen throughout development rather than only at the end
• Customer collaboration — involving the people the product serves throughout the process, not only at the requirements stage
• Self-organising teams — trusting the people closest to the work to make decisions about how to do it
• Continuous improvement — systematically examining how the team works and making specific changes to do it better

What Agile has actually delivered

Organisations that apply Agile well tend to gain higher transparency within teams, faster decision-making, clearer priorities, and better collaboration. These are the gains that show up most consistently in practice.

What is less consistently achieved — and what the Agile Manifesto promises — is genuine customer orientation, self-managing teams, faster time to market, and real innovation. These things require changes at the organisational level that framework adoption alone does not produce. The teams can be Agile while the organisation around them remains structured in ways that prevent the benefits from flowing through.

This is the distinction that matters most in practice: Agile at team level is achievable with relatively modest intervention. Agile as an organisational capability requires rethinking how work is governed, how decisions are made, and how the organisation creates the conditions for teams to actually deliver the value they are capable of.

Better Change has been working at both levels since before Agile frameworks were mainstream in Europe. If you are navigating this distinction in your own organisation, that is the experience we bring to the conversation.