If you take one practice from this site, take this one. Every engagement we run has a demo of working software once a week, at a fixed time, whatever the engagement model. It is the cheapest control there is, and it prevents the failures that make custom software expensive.
This article explains how the meeting runs and what it stops from happening.
What the demo is
Thirty minutes. The team shows the software running in a test environment, doing what was agreed at the start of the week. The product owner on your side drives or watches, asks questions, and says what is right and what is not. The project manager writes the decisions down before the call ends.
No slides. No status report read aloud. If something is not working, it is not demoed and the team says why. A demo of "almost done" work is a status meeting with extra steps.
What it is not
It is not the only contact of the week; stand-ups and the shared board continue. It is not user acceptance testing; that comes before a release and takes longer. And it is not a sign-off ceremony where a feature is accepted forever. It is the moment each week when the work becomes visible to the people paying for it.
What it prevents
Scope drift nobody noticed. When the product owner sees each feature within days of it being built, a misunderstanding costs a day. When the first look comes at the end of a phase, the same misunderstanding has been built on for weeks and costs a month. The demo is where "that is not what I meant" happens early enough to be cheap.
Integration surprises. Working software in a test environment, not a branch on a laptop, means the pieces have been put together. Teams that demo weekly integrate weekly, and the integration problems that sink projects in their final month surface in week three instead.
Invisible technical debt. A demo that has been slower every week, or has skipped the same feature twice, tells you something a status report will not. The product owner sees the software's health directly and can ask why.
Decisions that were never made. Every demo produces questions, and the questions produce decisions, and the decisions are written down with a name and a date. Projects fail on decisions that were assumed rather than taken. A weekly cadence forces the taking.
Late acceptance testing. By the time a release reaches formal testing, the product owner has already seen every feature at least once and usually several times. Acceptance becomes a confirmation, not a discovery, and the release date stops being a guess.
How to run it well
Fix the slot and keep it. Same day, same time, every week, in the overlap between your hours and the team's. A demo that moves is a demo that stops.
Have one product owner in the room. Not a committee; one person who can say yes, no or "let me check and confirm by tomorrow". Others are welcome to watch.
Demo from the test environment. The software should be deployed, with realistic test data, on the infrastructure it will run on. Demoing from a laptop hides the deployment problems that will appear later.
Show the failures. A feature that is not ready is not shown, and the reason is said out loud. A feature that half works is shown as half working. Trust comes from the weeks where the news is bad and the team says so.
Write the decisions down during the call. The project manager types while people talk. The notes go on the shared board before anyone leaves, so the next India morning starts with them.
End with next week's list. The last five minutes agree what will be demoed next week. That list is the plan; anything not on it is not promised.
An agenda that fits in thirty minutes
The meeting keeps to time when it has a shape. The one we use:
- Two minutes: what was promised. The project manager reads last week's list, so everyone knows what is about to be shown against.
- Fifteen minutes: the software. Each item on the list, in the test environment, driven by the engineer who built it or by the product owner. Real data where possible, the same flows a user would take.
- Five minutes: what did not make it. Each item not shown, with the reason and the new date. This is said plainly, not explained away.
- Five minutes: decisions. The questions the demo raised, each closed with a decision, a name or a date to decide by.
- Three minutes: next week. The list for the next demo, read back, so it is agreed rather than assumed.
Thirty minutes is enough for a team of four to six engineers. A larger programme with several teams demos in parallel slots rather than in one long meeting, because attention is the resource the demo spends.
What the client side brings
The demo works when the product owner arrives having used the software since last time. Ten minutes in the test environment the day before produces better questions than an hour of watching. Bring the questions written down, bring the decisions the last demo asked for, and bring anyone whose opinion would otherwise arrive by email a week later.
When to skip it
Never. A week with nothing to show is the week the demo is most useful, because the reason there is nothing to show is what you need to know. Holidays move the slot; they do not cancel it.
Where it fits
The demo is one of the artifacts in our six-stage process, alongside the scope document from discovery, the clickable prototype from design, the test plan and the runbook.
If you have worked with a vendor that reported progress in percentages, you already know why we do it this way. Ask any team you are evaluating when you will first see the software running. If the answer is a date rather than a weekday, keep asking.
