1. Why iterative working wins
Agile literally means nimble. It is not a toolbox and not a method, but a way of looking at work whose outcome you do not know in advance. You do not first put everything down on paper and then spend two years carrying it out; you deliver something that works in short steps, see what it does, and adjust. Before you start on sprints and roles, it is worth knowing where that conviction comes from and what it does to your planning.
After this chapter:
- You know where the Agile Manifesto comes from and what it says.
- You know the four values of the Manifesto and can explain them in your own words.
- You understand the difference between working iteratively and incrementally.
- You can explain why the project triangle is inverted in agile.
- You recognise situations in which a traditional approach is the better choice.
Where agile comes from
In February 2001 seventeen software developers met at a ski resort in Snowbird, Utah. They had had enough. Software projects in the eighties and nineties were getting out of hand on a massive scale: budgets tripled, delivery dates slipped by years, and what finally came out was often not what the customer needed. In three days they wrote down the Agile Manifesto: four values and twelve principles. Nothing more. They chose the word agile deliberately, because it expresses what it is all about, namely being able to respond quickly to change.
The cause of all those failures was always the same. At the start of a project everything was set out in detail. A team then worked in isolation for months or years. Only at delivery did the customer come into view again, and by then the world had moved on. Agile originated in the software world, but you now find it in marketing, HR, product development and education. Anywhere you cannot foresee everything in advance.
The four values of the Agile Manifesto
The Manifesto sets two things against each other four times. Not to declare the right-hand part worthless, but to say where most of the value lies.
Individuals and interactions over processes and tools. A good process helps, but without good collaboration no tool will solve your problems.
Working software over comprehensive documentation. If you do not work on software, read: a working product. A thick manual is no proof of progress. Something that works and delivers value is.
Customer collaboration over contract negotiation. A contract protects you, but a good relationship with your customer produces a better end result.
Responding to change over following a plan. A plan gives direction, but if reality changes, you change with it.
These four values are exam material and it pays to know them word for word, including the word "over". Twelve principles have been derived from the four values that make them concrete; these are covered in the full course.
Iterative and incremental
Two words keep cropping up, and they do not mean the same thing. Iterative means that you work in repeating cycles. You make a first version, improve it, make a second version, improve it again. Working iteratively is about refining. Incremental means that you deliver in parts. You do not build everything first and then launch, but keep adding a new, working component. Working incrementally is about extending.
The rule of thumb is simple: incremental is more, iterative is better. In practice you do both at once. You deliver a growing product in small steps, and with each step you improve what was already there on the basis of feedback.
A team of five people at a travel company is building a new booking app. In sprint 1 they deliver a search screen that lets you search by destination. Twelve colleagues test it that same week. In sprint 2 a price range filter is added: that is incremental, because there is more that works. At the same time they adjust the search screen, because the test showed that nine of the twelve colleagues could not find the "search" button on their phone: that is iterative, because what already existed got better. After two sprints of two weeks there is something you can show to a real customer. With a classic approach, the design would still have been in the approval round at that point.
Waterfall versus agile
The waterfall method divides a project into phases that follow one another: analysis, design, build, test and delivery. Each phase has to be finished before the next one starts. The name says it all: the water falls from step to step and does not flow back. Value is only created at the very last moment, at delivery. Once, at the end.
With an agile approach you cut that same lead time into sprints, for example five sprints of two weeks, and the team delivers a working increment after each sprint. Instead of one moment at which value is created, there are five. And therefore also five moments at which you notice that you had something wrong.
Waterfall is not wrong. It works well for projects with clear, stable requirements: building a bridge, constructing a motorway, a relocation. There you know in advance what it has to become and going back is expensive. It becomes a problem as soon as the requirements shift along the way, because a change in the test phase means going back to the design.
The inverted triangle
This is the difference you will feel most often in practice. In classic project management you work with the project triangle of scope, time and budget. The scope is fixed: what you deliver has been agreed. Time and budget are the dials you turn. If it overruns, it takes longer or costs more, and quality moves with it as the balancing item.
Agile inverts that triangle. Time and budget are fixed, because you work in sprints agreed in advance with a fixed team. The scope is the variable. You deliver the most important functionality first and push less important matters back or drop them altogether. That is precisely why prioritising in agile is not a side issue but the heart of the craft, and that is what chapter 3 is about.
Do you want to know whether an organisation really works in an agile way? Ask what happens when a sprint is not finished. If the answer is "then we run a week over", the scope is still fixed and nothing has changed. If the answer is "then the least important work goes back to the backlog", the triangle really has been inverted.
When agile is not the best choice
The gain from agile does not come from the method but from the rhythm: real feedback every few weeks instead of a signature under a document. A wrong assumption therefore costs you weeks rather than months. But there are situations in which that gain falls away.
With a scope laid down in law there is little to prioritise, and then all you are left with is the extra meetings. Clients who want a total price for a fixed scope up front run into trouble with a variable scope. A team that is not freed up and jumps between five projects will not make a single sprint. And in a chain where you depend on parties that plan by the quarter, your two-weekly rhythm loses its point.
Whether agile takes hold depends mainly on three things. There is a client who really decides and does not pass every choice on to a steering committee. The team works on one thing at a time. And management steers on delivered results rather than on utilisation and timesheets.
A municipality with 90,000 inhabitants has a new digital service desk built, budgeted at 640,000 euros. Two things are running side by side. The statutory requirements around digital accessibility are fixed: there is nothing to prioritise there, they all have to be included. The user experience, by contrast, is entirely open, because nobody yet knows how a resident wants to report a change of address. The project management therefore opts for a hybrid approach: PRINCE2 for governance towards the executive and the council, with stages and go/no-go moments, and scrum for building the service desk itself, in two-week sprints. The first three sprints deal only with reporting a change of address; after sprint 3 a test with eleven residents shows that the form needs to fit into two screens instead of five. That insight cost six weeks. In the preceding project, which ran entirely on waterfall, the same kind of insight only surfaced after fourteen months.
Take a project from your own work that overran or went differently than expected.
- Was the scope fixed, or were time and budget the hard limits? What gave way when things got tight?
- At what moment was it first visible that things would go wrong? And when was it discussed?
- Was there something you could already have shown to a user after two weeks?
- Was there a client who decided things themselves, and was the team working on one thing at a time?
Write down your answers in no more than ten sentences. You will use them in the following chapters.
Summary
- The Agile Manifesto was drawn up in 2001 by seventeen developers in Snowbird, Utah, and consists of four values and twelve principles.
- The four values: individuals and interactions over processes and tools, working product over documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
- Iterative means improving through repeating cycles; incremental means delivering in parts. Agile does both at the same time.
- Waterfall delivers value once, at the end. Agile delivers a working increment after every sprint.
- The project triangle is inverted: in the traditional approach the scope is fixed and time and budget move with it, in agile time and budget are fixed and the scope moves.
- Agile is a poor fit for a scope laid down in law, a fixed total price agreed in advance, fragmented teams or supply chains that plan by the quarter.
In sprint 4 a team delivers a new export function and at the same time adjusts the search function from sprint 2 in response to user feedback. What do you call those two things?
What does the inverted project triangle say about an agile project?
Which of these four is a value from the Agile Manifesto exactly as it is written?