Agile is one of those words that means everything and nothing depending on who is using it. In some organisations it means Scrum. In others it means Kanban. In others it refers to a general posture of iterative working, continuous improvement, or customer responsiveness. All of these usages have some legitimacy, which is exactly what creates the confusion.

Getting clear on the structure — what Agile is, what frameworks are, and how the two relate — makes it much easier to make good decisions about how to work.

What Agile actually is

Agile is a philosophy, not a method. Specifically, it is a set of four values and twelve principles articulated in the Agile Manifesto in 2001, when a group of experienced software practitioners concluded that the dominant approaches to software development were producing poor results.

The Agile Manifesto does not tell you what meetings to hold, how to structure your team, or what tools to use. It describes a set of priorities — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan — that should inform how you choose your methods and tools.

Agile Methodology, as the term is often used, refers to the practice of applying these values and principles through a process of incremental delivery, continuous stakeholder feedback, and iterative improvement. The emphasis is on delivering working results in small increments rather than in a single large release, which creates opportunities for learning and adjustment throughout the work rather than only at the end.

What agile frameworks are

Agile frameworks are specific, structured approaches to implementing agile principles. They translate the values of the Manifesto into concrete practices: defined roles, specific events, required artefacts, and recommended ways of working. The most widely used are Scrum and Kanban, but there are many others.

Scrum is a timeboxed framework built around fixed-length iterations called Sprints. It defines three accountabilities (Scrum Master, Product Owner, Developers), five events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint itself), and three artefacts (Product Backlog, Sprint Backlog, Increment). It is particularly well-suited to teams building products iteratively where regular stakeholder feedback is part of the process.

Kanban, in its agile context, is the Kanban Method — a flow-based approach to managing knowledge work. It starts from wherever the team currently is, makes work visible through a visual board, limits work in progress to improve flow, and evolves the process incrementally. It is often a better fit than Scrum for teams with continuous, varied work where the concept of a fixed-length sprint does not map well to how work actually arrives.

Other notable frameworks include Crystal, which emphasises team size and criticality over prescribed practices; Extreme Programming (XP), which focuses intensely on technical practices like test-driven development and pair programming; and SAFe, Nexus, and LeSS, which address the challenges of coordinating multiple agile teams in large organisations.

Which framework is right?

No single framework is universally best. The right choice depends on the nature of the work, the team's context, and what the organisation is trying to achieve.

Scrum tends to work well for product development teams, innovation work, and any context where iterative delivery and regular feedback cycles are central. Kanban tends to work well for teams managing ongoing work, support functions, and organisations that need to evolve their processes gradually rather than adopt a new framework wholesale.

The most important factor is not which framework you choose but whether you understand why it works, whether you implement it thoughtfully in your specific context, and whether you have the discipline to learn from what it reveals rather than adapting it to hide the problems.