Our process
How we actually run delivery, and where we leave the textbook
Agile in the sense that matters — short cycles, working software, and changing direction on evidence. Not in the sense of running every ceremony and shipping quarterly.
The situation
Agile in name
A great many organisations run standups, sprints and retrospectives, and deliver no faster than before. The ceremonies are not the method; they are what is left when the method is dropped.
- Sprints that end with work carried over every time
- A backlog nobody has ordered by value
- Demos with slides instead of working software
- Estimates treated as commitments and then as blame
- Retrospectives raising the same issue for months
- A release process too slow to keep up with the sprints
What it covers
What we actually do
Short cycles with working software
Every iteration ends with something that runs and can be used. A demo that is a presentation is not evidence of progress.
Work ordered by value and risk
The riskiest and most valuable things first, so the expensive unknowns surface while there is still time.
Slices small enough to finish
Work sized to complete within a cycle, which does more for predictability than any estimation technique.
One accountable owner
A named person on your side who can decide. Delivery stalls on unavailable decisions more often than on technical problems.
A release process that keeps up
Automated deployment, because short cycles are pointless if releasing takes a month.
Honest reporting
Status that reflects reality, including when reality is unwelcome. That is the only kind worth having.
How we work
A cycle, end to end
Two weeks is our usual rhythm, adjusted where the work genuinely calls for something else.
Plan
Agree what will be delivered this cycle, sized so it can actually be finished rather than optimistically filled.
Build
Develop, test and integrate continuously rather than leaving testing to the last two days.
Show
Working software, in your hands, not a screenshot. This is the point at which misunderstandings surface.
Adjust
Change the plan on what was learned. A plan that never changes is not being informed by anything.
Outcomes
What this gives you
- Working software every cycle, not at the end
- Problems visible early, while options remain
- The ability to change priority without renegotiating everything
- Predictability from finishing small things, not from estimates
- Reporting you can act on rather than reassure yourself with
- The option to stop with value already delivered
Common questions
Questions we are usually asked
No. It means the scope flexes rather than the date or the quality. Fixed-date, fixed-budget work is entirely compatible with iterative delivery — what cannot be fixed simultaneously is date, budget and scope, and pretending otherwise is what produces the late, over-budget projects agile was a reaction to.
We do not run ceremonies that are not earning their place. If a daily standup has become a status report to a manager, it should be a written update. Scrum is a starting point, not a compliance regime.
By breaking work into slices small enough that the estimate matters less, and by measuring how much actually completes per cycle. Historical throughput predicts better than any estimation ritual, and it improves as the project runs.
Most are not, and it is not a prerequisite. What we do need is one person who can make decisions within a reasonable time. Iterative delivery survives a traditional organisation; it does not survive decisions taking three weeks.
Yes, and often better. Iterative delivery produces continuous evidence of what was built, tested and approved, which is easier to evidence than a document written at the end describing what was intended.
Written where it will be read. Working software over comprehensive documentation was never an argument for none — an application handed over without documentation is not agile, it is unfinished.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Working with usWhat an engagement looks like from first call to live system.
- Rapid application developmentGetting something usable in front of people quickly, without disposable code.
- Prototyping and specification writingDeciding what to build, and proving it before it is built.
- Agile and DevOpsShorter release cycles and a build pipeline you can rely on.
- Project managementDelivery run by people accountable for the outcome.
- Application development and maintenanceBuilding it, then keeping it running and current.