What does Agile mean for the people paying?
Agile is built on one observation: in software projects the scope is not known at the start. So you deliver a working piece every few weeks and correct course. For a buyer it means seeing something work regularly and being able to change priorities without renegotiating the contract, in exchange for being in the room.
“We use Agile” is what every software supplier says, and that is exactly why it says nothing. It is worth understanding what it means for the people paying, because the difference between a method declared and a method practised shows up in a single meeting.
What it is, without the jargon
Agile is a way of working built on a simple observation: in software projects the scope is not known at the start. It is discovered while working. So instead of deciding everything up front and delivering at the end, you deliver a working piece every few weeks and correct course with what you have learned.
It is not about speed, despite the name. It is about when decisions get made: as late as possible, which is when you know most.
What changes for the buyer
- You see something working every few weeks, instead of a completion percentage.
- You can change priorities without renegotiating the contract.
- Problems surface early, when they are cheap.
In exchange:
- You have to be there. An agile project without the client in the room is not agile: it is a supplier deciding alone more often.
- Somebody has to be able to decide. If every choice climbs a two-week approval chain, the method stalls.
The four values, translated for a buyer
The 2001 Agile manifesto is four lines. Without the jargon, they mean this:
People before processes. If the project goes badly, one more document will not save it: talking to the person writing the code will. Ask to be able to.
Working software before documentation. Not “no documentation”: software first. If by month three you have read three reports and never seen a screen work, something is wrong.
Collaboration before contract. The contract matters, and the clearer the better. But if every discovery becomes a negotiation, the project stops.
Responding to change before following the plan. The plan is a tool, not a promise. A plan that has never changed in six months is not discipline: it is nobody looking.
Scrum, Kanban: what changes for you
These are the two common ways of practising it, and from the client’s side the difference is one thing.
Scrum works in closed cycles of two to four weeks: inside a cycle the scope is untouched, and at the end something is delivered. It gives rhythm and dates, but asks you to wait for the end of a cycle to change priorities.
Kanban works as a continuous flow: the order can change at any moment, but there are no natural dates, and it needs more discipline and someone of yours always available.
Our method takes the rhythm of the first and the freedom of the second: weekly cycles that end on Friday, with a final date that does not move.
When Agile is not the answer
A method that suits everything is a flag, not a method.
- When the scope really is known and fixed (a migration, an integration against written specifications), planning up front works better and costs less.
- When a regulation requires documentation first. You can work iteratively inside, but the form is set by the rule.
- When the client cannot take part. In that case it is more honest to agree a closed scope, say so, and stick to it.
The way it usually goes wrong
Many companies adopt the rituals (daily meetings, point estimates, boards full of cards) without the substance, which is the freedom to change your mind based on what you have seen. The result is a waterfall with ceremonies on top: the same late deliveries, with more meetings.
The signal is simple: if the plan has never changed in six months, the method is not working.
Three questions for anybody who says they use Agile
- How often do I see something working? If the answer is “at the end”, it is not agile.
- What happens if I change a priority in month three? If the answer contains the words “change request”, the method is on paper.
- Who is in the meeting where decisions get made? If you are not, it is not a meeting where decisions get made.
How we use it
Eight weeks, fixed date, fixed team.
The date does not move: you know from the start when it ends and what it costs. The team does not change: in two months there is no time to explain the process to somebody new.
Scope is renegotiated every Friday, one hour, in front of what is running. Not a status meeting: the meeting where it is decided what goes in and what comes out. At the end there is a system working on real data, in the hands of the people who will use it, and you decide whether to fund phase two.
What we ask is three things: half a day on site at the start, one person who can decide, and the Friday hour. We say so before signing, because without them it does not work.
The method in full is on our method.