Topics1 of 5: What is Agile
What is Agile?
Agile is a way of building products in small steps, checking each step with real people, and changing course when you learn something new. This guide explains the idea without the jargon.
7 min readUpdated
On this page7 sections
Agile in one paragraph
Instead of planning everything up front and delivering once at the end, an Agile team delivers a small, working piece of the product every few weeks, or continuously, and shows it to the people who will use it. What they learn shapes the next piece. There is still a plan; it simply gets updated as the team learns, instead of being defended.
Agile is not a single method. It is a set of values and principles, written down in 2001 in the Manifesto for Agile Software Development. Scrum and Kanban are two popular ways of putting them into practice.
The four values
The Manifesto’s authors summed up what they had learned in four pairs. Both sides matter; the left side matters more.
Tools help, but most problems are solved faster by people talking to each other.
Write the documents someone will use, and judge progress by what actually works.
Work with customers as partners all the way through, not only at sign-off.
Make a plan, and expect it to change as you learn more.
The value phrases are quoted from the Manifesto for Agile Software Development (2001), agilemanifesto.org. The explanations are ours. Next, see the twelve principles behind them.
Why teams work this way
- Less risk of building the wrong thing. You find out after two weeks, not after six months.
- Value arrives sooner. A first useful version can ship while the rest is still being built.
- Everyone can see progress. A shared board and a short review every sprint say more than a status report.
- A pace people can keep. Planning by the team’s real capacity, not by hope, means fewer late nights.
- Teams get better over time. A regular retrospective turns lessons into changes.
Agile and Waterfall, side by side
Waterfall runs a project as a sequence of phases (requirements, design, build, test, release), each finished before the next one starts. Agile does the same activities in short loops, again and again.
| Question | Waterfall | Agile |
|---|---|---|
| When is it planned? | Mostly up front, in detail | A little up front, refined every few weeks |
| How is it delivered? | One big release at the end | Small working increments, often |
| What happens to change? | Costly; it goes through change control | Expected; the backlog is reordered |
| When do users give feedback? | Late, after the release | Early and regularly, at every review |
| How is progress measured? | Phases and documents completed | Working product |
| Where does it fit best? | Well-understood work that is unlikely to change, such as a migration with a fixed specification | Work where the problem or the solution is uncertain and learning matters |
Neither is right for everything. Many teams that must meet fixed milestones still build in short Agile loops inside them.
Two ways of working: Scrum and Kanban
Both put the Agile values into practice. The main difference is rhythm.
Scrum
Work is planned and delivered in sprints, each the same length and never longer than a month. A sprint works towards a Sprint Goal, and closes with something usable, a review with stakeholders and a retrospective.
- Three accountabilities: Product Owner, Scrum Master, Developers
- Five events: the Sprint itself, plus Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective
- Good for product work with a steady team and a backlog of features
Kanban
Work flows continuously across a board. Instead of time-boxes, the team limits how much is in progress at once and watches how long items take to finish.
- No sprints and no prescribed roles
- Work-in-progress (WIP) limits per column: finish before starting more
- Good for support, operations and work that arrives unpredictably
Which should we use?
If your work can be planned a couple of weeks ahead and you want a regular review with stakeholders, start with Scrum. If work arrives all the time and priorities change daily, start with Kanban. You can change later, and many teams borrow from both: a Scrum team with WIP limits is common.
ScrumTeam supports both. Each project is set up either as a Scrum project, with sprints (and retrospectives on Starter and up), or as a Kanban project, with one continuous board and WIP limits.
Four common myths
- “Agile means no plan.”
- There is a plan: detailed for the next few weeks, broad for the months after, and updated often.
- “Agile means no documentation.”
- Write what someone will actually read and use, and keep it next to the work.
- “Agile is Scrum.”
- Scrum is one framework. Kanban, Extreme Programming and others are Agile too.
- “Agile makes teams faster.”
- It gives earlier feedback, which often saves time. It is not a way to squeeze more work out of people.
How ScrumTeam helps
What this guide describes, in the product.
- A Scrum or Kanban board for each project: sprints for Scrum, one continuous board for Kanban
- WIP limits on board columns, with a clear warning when a column is over its limit
- One ordered backlog, kept in priority order by the Product Owner
- A goal for every sprint, and on Starter and up a retrospective at the end of it with action items