Agile
Agile is an iterative approach to product development that delivers working increments, welcomes change, and involves users throughout, instead of planning everything upfront.
It is a philosophy captured in the Agile Manifesto, which values individuals and interactions, working software, customer collaboration, and responding to change. Teams put it into practice through frameworks like Scrum, Kanban and Extreme Programming, but Agile itself is the mindset, not any one framework.
How it works
The Agile Manifesto defines four values and twelve principles. Several frameworks put them into practice.
- Scrum is the most common framework. Work happens in fixed-length sprints, usually one to four weeks, with specific roles (Product Owner, Scrum Master, development team) and ceremonies (planning, daily standup, review, retrospective). It is structured and prescriptive.
- Kanban is more flexible. Work is visualised on a board, work in progress is limited, and the focus is on flow. It suits teams with continuous incoming work better than fixed sprints.
- Extreme Programming (XP) emphasises technical practices like test-driven development, pair programming and continuous integration, on the argument that software quality is what makes iteration sustainable.
All three are Agile. None of them is the definition of Agile. The definition is the values and principles.
When to use it
Agile suits work where requirements will change, feedback is available, and learning matters.
It is a poor fit when the work is a one-off deliverable with a fixed specification, such as building a bridge to a set of engineering drawings. In software, that situation is rarer than it looks, because the act of building reveals things no planning session can predict.
It is also a poor fit when a team goes through the motions without the underlying values. Standups and boards without autonomy, feedback and adaptation are ceremony without substance, which is worse than no process at all.
Common mistakes
- Treating Agile as no planning. Agile involves planning. It is continuous planning rather than fixed upfront planning. Plans are made, adjusted and refined as the team learns. Agile without planning is chaos.
- Treating it as no documentation. The Manifesto values working software over comprehensive documentation. It does not say documentation is worthless. Agile teams document what is valuable, just enough.
- Confusing Scrum with Agile. Scrum is one framework. Kanban, XP and many team-specific approaches are also Agile. The Manifesto defines the mindset, not the ceremony.
- Dropping the technical practices. Without testing, integration and refactoring, iterations become painful and quality erodes. The team cannot sustain the pace.
- Letting stakeholders expect fixed scope, budget and timeline. Agile commitments are shorter and more reliable because they are based on recent velocity. Educating stakeholders on what an Agile commitment looks like is often required.
Key takeaways
- Agile is a mindset, defined by the Agile Manifesto's four values. Scrum, Kanban and XP are frameworks that put it into practice.
- Iterative delivery means getting working software to users sooner and learning from real usage instead of waiting for a big-bang release.
- Welcoming change is not a failure of planning. It is what the process is designed for.
- Agile without technical practices like testing and continuous integration cannot sustain the pace.
- Ceremony without the underlying values is worse than no process. Agile in name only creates overhead without the benefit.
No lessons cover this yet
This term is defined ahead of the curriculum — the definition above stands on its own, and lessons will link here once they exist.
Browse what is publishedCommon questions
- What is the difference between Agile and Scrum?
- Agile is the philosophy defined by the Manifesto's values and principles: iterate, deliver early, involve users, welcome change. Scrum is one specific framework for practising Agile, with fixed-length sprints, defined roles, and specific ceremonies. A team can be Agile without doing Scrum. A team can do Scrum without being Agile, if it goes through the ceremonies without the values. Scrum is a subset of Agile, not a synonym for it.
- Does Agile mean no deadlines or commitments?
- No. Agile teams make commitments, but they are shorter and more reliable because they are based on recent observed velocity rather than distant estimation. A sprint commitment is a promise the team makes to itself about what it can deliver in two weeks, informed by what it delivered in the previous two weeks. That is more reliable than a commitment made six months in advance based on a plan nobody has tested. Stakeholders used to fixed scope and timeline often need to be educated on what this looks like.
- When should a team not use Agile?
- When the work is a fixed deliverable with a stable specification and little uncertainty, such as implementing a well-defined engineering standard. In software, situations this stable are rarer than they look, because building almost always reveals something planning could not predict. More often the question is not whether to use Agile but whether the team is actually doing it or just performing the ceremony. Ceremony without values is the most common failure mode, not the methodology itself.