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.
Think of it like this. A road trip planned down to the minute assumes the weather holds, the roads stay open and nothing interesting appears along the way. A road trip that checks in at each town and adjusts is slower to plan but more likely to end somewhere worth being. Agile is the second approach applied to building products.
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.
Frequently asked questions
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.