The first hour of a Sprint is spent watching, not asking, why the documented process and the real one never match

Ask a manager to describe how a process works and you will get a clear answer. Ask the person who runs it every Wednesday afternoon and you will get a different one.

Neither of them is lying. The manager is describing the process as designed, which is genuine and usually sensible. The other person is describing the process as survived, which includes every adjustment made since to keep it moving. That second version is the one that matters, because it is the one that actually runs.

The documented process is a summary

Written processes are written at a moment in time, usually by somebody who does not perform the steps. They are accurate on the day they are approved and then reality happens to them. A supplier changes a form. A customer type appears that the original design never anticipated. Somebody leaves and their replacement invents a slightly different way of doing step four.

None of those changes get written back into the document, because updating the document is nobody's job and the work still gets done without it. Two years later the document describes a process that resembles the real one in outline and differs from it in every detail that costs money.

Workarounds are requirements

The interesting part of any first conversation is the workarounds, and they take some coaxing out. People are slightly embarrassed by them. They present the spreadsheet that bridges two systems as an apology rather than as information.

It is the most useful thing in the room. A workaround is evidence. It exists because something in the official design does not survive a real week, and somebody built a small bridge rather than raise a ticket that would take a quarter to resolve. The bridge shows exactly where the design failed and exactly what shape the fix has to be.

Tidying those away at the start of a project is a common and expensive mistake. The new system gets built to the documented process, ships, and immediately needs the same workarounds again, because the conditions that produced them never went anywhere.

What the first hour actually looks like

Very little of it involves questions about software. It involves opening the thing and doing it.

• One real case, followed all the way through. Not a representative example and not a diagram. An actual order, matter, claim or ticket from last week, followed from arrival to completion with the tabs open.
• Every point where the work stops. Waiting for an approval. Waiting for a file. Waiting because the next person only looks on Thursdays. These gaps are usually where most of the elapsed time lives, and they are almost never in the documentation.
• Every place data gets retyped. Retyping is the clearest signal there is. It means two systems hold the same fact and nothing joins them.
• What happens when it goes wrong. The exception path is where the real complexity sits. Most processes handle the ordinary case perfectly well. The cost is in the ten per cent that need a phone call.

The question that changes the answer

The most productive thing to ask is not what do you do. It is what do you do when the customer has two addresses, or when the invoice is part paid, or when the job skips a stage because somebody was in a hurry.

That question moves the conversation from the version people present to the version they operate. It also surfaces the rules that live in one head and nowhere else, which are the rules that make holiday cover difficult and onboarding slow.

Why this happens before anything is designed

A build that automates the wrong process is worse than no build. It hardens a bad shape into code, makes it harder to change later, and adds a maintenance cost to a problem that was already costing money.

An hour of watching prevents most of that. It costs almost nothing, it produces a description that both the manager and the person doing the work recognise, and it usually turns up two or three things that can be fixed without building anything at all. Occasionally the honest answer at the end of a discovery day is that a process needs deleting rather than automating, and that is a good conclusion to reach cheaply.

What you can do without booking anything

This is not a technique that requires an outsider. Pick one process that everybody complains about. Sit with the person who runs it and watch one real case, start to finish, without correcting anything you see. Write down the waits, the retyping and the workarounds.

Then compare that against whatever document describes the process officially. The distance between the two is your brief.