What Agile is
Agile is a family of approaches to organising work, mostly developed in software, built around short cycles, frequent feedback and the willingness to change plans as you learn. The word became widely used after a group of software practitioners published the Agile Manifesto in 2001, a short statement of values. It is not a single method or a certification, and no one framework is “the” Agile.
The core idea is simple. In many projects the full set of needs is not known at the start, and detailed long-range plans tend to be wrong in places. Instead of planning everything and then building it, an Agile team builds something small, shows it to the people who will use it, learns from their reactions and adjusts.
The values in plain words
The Manifesto expresses four preferences, each meaning “while there is value in the items on the right, we value the items on the left more”:
- 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 priorities, not rejections. Agile does not say that documentation, plans or processes are worthless; it says that when they conflict with real collaboration and working results, the latter should usually win. Misreading the values as “no planning” or “no documentation” is a common source of poor Agile practice.
Common practices
Different frameworks combine a handful of recurring ideas:
- Short iterations. Work is divided into cycles of a few weeks or less, each producing something usable or at least reviewable.
- A prioritised list of work. A backlog holds what might be done, ordered by value, and is revisited as understanding changes.
- Small, cross-functional teams who can do most of the work without handing it to other groups.
- Regular feedback. Demonstrations to users or stakeholders, and team reflection on how to work better.
- Visible progress. A board, chart or list that everyone can see.
Scrum
Scrum is one of the best-known frameworks. Work happens in fixed-length iterations called sprints, commonly one to four weeks. The team picks items from the backlog to complete in the sprint, meets briefly each day to coordinate, shows what it has finished at the end in a review, and holds a retrospective to discuss what to improve.
Scrum defines a few roles. A product owner decides priorities, a scrum master helps the team follow the process and removes obstacles, and the developers do the work. Role names and exact rules can differ between organisations, and teams often adapt them. Scrum suits work that can be divided into small increments and where the priorities may shift between sprints.
A realistic caution: Scrum can become a ritual, with meetings held because the framework says so, and sprint goals treated as promises to management rather than as a team’s plan. The ceremonies work best when they serve a purpose the team understands.
Kanban
Kanban takes a different approach. Instead of fixed iterations, work flows continuously across a board, with columns such as “to do”, “in progress” and “done”. The distinctive idea is limiting how much work is in progress at one time. Capping work in progress makes bottlenecks visible, since a full column signals that the stage after it is the constraint, and it encourages finishing things before starting new ones.
Kanban is often a good fit for work that arrives unpredictably, such as support requests, maintenance and operations. It adds less structure than Scrum, which some teams like and others find too loose. Some teams mix the two, using sprints plus a board with limits.
Where Agile fits poorly
An honest account has to include the limits. Agile tends to fit less comfortably when:
- Changes are costly or slow. If building a physical part, ordering tooling or changing a certified design takes months, repeated rapid change is not realistic. Hardware teams often use hybrid approaches, combining early iterations on models and prototypes with more fixed planning for manufacturing.
- Regulation or safety demands formal evidence. Some industries require documented requirements, reviews and traceability. Agile practices can sit alongside these, but only if the team deliberately plans for them. Rules vary by country and sector, so follow the standards that apply to you.
- Requirements are truly fixed. If the target is fully known and unlikely to change, a more sequential plan may be simpler.
- The organisation does not support it. Agile works poorly when management demands fixed scope, fixed dates and fixed budgets while also asking for flexibility.
- People work in isolation. Short feedback cycles help little if the team has no access to users or decision-makers.
Another common problem is adopting the vocabulary without the habits: calling a long wish list a backlog, or a status meeting a stand-up, while behaviour stays the same.
Using Agile ideas sensibly
You do not have to adopt a whole framework. Useful pieces can be taken on their own:
- Deliver in small steps and ask for feedback early.
- Keep a visible, prioritised list of work.
- Hold short regular reflections on what to change.
- Write acceptance criteria so that “done” is clear.
- Keep documentation proportionate to need.
Starting with one or two practices, observing the results and adjusting is more likely to work than a wholesale change. Agile thinking also overlaps with continuous improvement, which has a long history beyond software. Teams still need basics such as clear requirements engineering, scheduling and honest status reporting, and iterative methods do not remove those needs.
Finally, no method guarantees success. Results depend on the people, the problem and the context, so treat any framework as a tool to adapt rather than a rule to obey.