Agile assumes an engaged product owner available most days. Agency work rarely has one. The client is a managing director with a business to run, who thinks about your project on Tuesday afternoons and expects to see something at the end of the month.
The usual responses are both bad. Drag the client into ceremonies they resent, or abandon the cadence and discover in week six that you built the wrong thing.
What works is keeping the cadence entirely internal and exposing only two things outward: a demo and a decision list.
Internal: unchanged
Two-week sprints, planning on the Monday, standups daily, retro on the Friday. None of it involves the client. This is our machinery for knowing where we are, and it works the same whether the client is present or not.
The one adaptation: every sprint must end with something demonstrable. Not a status report — something on a screen that a non-technical person can react to. If a sprint produces only backend work, we build the thinnest possible view onto it. That view is not waste; it is the only way to get a decision from someone who does not read Jira.
Outward: the demo
Thirty minutes at the end of each sprint. Recorded, so it can be watched later at double speed, because half the time it will be.
Structure that holds attention:
- Two minutes: what we said we would do.
- Fifteen minutes: the working thing, driven by us, on real data where possible.
- Ten minutes: the decisions we need, which is the entire point of the call.
- Three minutes: what is next, and what we need from them before then.
Clients who will not attend a planning session will attend this, because it is short and they see progress. Attendance in our experience runs around 80%, against roughly 30% for anything labelled a ceremony.
Outward: the decision list
This is the part that saves projects.
Every decision we need is written down, with the options, our recommendation, the cost of each, and the date after which we will choose for them. That last part is not a threat. It is the only thing that keeps a project moving when the decision-maker is busy.
Should refunds be partial or full-only? Partial costs about three extra days and needs a rule for shipping. We recommend full-only for launch. If we have not heard by the 14th we will build full-only and leave room to extend.
Clients rarely object. What they object to is being blocked on a question they did not know existed, then blamed for the delay.
The Friday note
One short email every Friday, whether there is news or not. Three lines: what moved, what is blocked, what we need. Nobody reads a long status report. Everybody reads three lines.
Its real value is the paper trail. When somebody asks in month four why the deadline moved, the answer is sitting in an email from week six that says we were waiting on content.
What we do not do
We do not ask clients to write user stories. We do not ask them to groom a backlog. We do not invite them to retros. We do not explain story points, ever.
Those are tools for a team that works together daily. Imposed on a monthly participant they create friction and produce nothing.
When the client goes quiet
It happens, usually because something in their business caught fire.
Keep sprinting on whatever is unambiguous — infrastructure, tests, the screens already agreed — and let the decision list accumulate. Do not keep building speculatively past the point where the decisions matter. Say so plainly: "We have four weeks of unblocked work left, then we need decisions 7 through 11."
A date and a number get a reply. "Please advise" does not.
Working on something like this? We do this kind of work for a living — software, design, delivery and the accounting behind it.
Start a conversation