The short version
Agile is a way of reducing risk: you see working software every couple of weeks, so problems surface while they are still cheap to fix. For you as the client, it means a regular review where you can use what has been built, change your mind about what comes next, and see exactly where the budget is going.
Most writing about agile is aimed at developers. This is for the people paying for it: what you should expect to see, what you will be asked to do, and how to tell whether it is working.
Why it matters to you
The traditional approach is to write a full specification, build for months, and see the result at the end. The risk is obvious. If the specification was wrong, or the world changed, you find out when most of the money has been spent.
Agile delivery works in short cycles. Each one ends with working software in an environment you can use. If something is wrong, you find out in two weeks, not six months.
Scrum and Kanban, in plain terms
You will hear two names most often.
- Scrum works in fixed time-boxes called sprints, usually two weeks. Each sprint starts with planning, includes short daily check-ins for the team, and ends with a review where you see what was built. It suits larger, structured projects such as a new platform or a product built from scratch.
- Kanban is a continuous flow. Work is prioritised in a visible queue and picked up as capacity allows, without fixed sprints. It suits support, maintenance and shorter pieces of work, where priorities change week to week.
We use Scrum for larger builds and Kanban for support and smaller projects. The name matters less than the habits: small batches, frequent releases and honest visibility.
What you will see every fortnight
- A working release in an environment you can log into, not slides about progress.
- A sprint review where you use the new features and give feedback while it is still cheap to change course.
- An updated backlog: the prioritised list of what comes next, which you help to order.
- Where the money has gone, against the plan agreed at discovery.
What you will be asked to do
Agile needs more from the client than a traditional project, and this is where projects most often struggle. You will need:
- A product owner on your side who can make decisions about priorities, and has the time to do it.
- Access to real users for feedback, not just managers.
- Attendance at reviews. A review nobody from the client attends is a missed chance to correct course.
Agile does not mean no plan
A common worry, especially from finance and procurement, is that agile means an open-ended budget. It should not. Discovery should produce a costed plan, an architecture and a prioritised backlog. Delivery then works through that backlog in order of value. What changes is the detail of what gets built, not whether anyone is accountable for cost and scope.
How to tell if it is working
- You can use something new after every sprint.
- Problems are raised early by the team, not discovered late by you.
- Most finished work is accepted first time.
- Issues are caught in testing and staging rather than by users in production.
On one recent platform, 97% of completed work items were accepted first time and 96% of user-reported issues were caught in staging, before they reached production.
How we approach it
Every engagement follows the same stages: consult, discover, deliver, support. Discovery is fixed price. Delivery runs in short sprints with a working release every two weeks. Security and testing run throughout, with automated tests on every change and separate development, test and staging environments.
See how we work, or book a free health check.