Delivering design one iteration ahead reduces mutual waiting

What it is

If design and implementation start the same item in the same iteration, each side stalls on what the other has not yet given: engineering waits for a buildable spec, design waits for constraints that only appear once something is being built. Handing design over one iteration ahead, in a buildable state, lets engineering consume this round while design produces the next, and shortens that mutual queue.

What leads is a buildable delivery, not exploration stuffed into the lead slot. Shipping a still-contested direction “ahead” only swaps waiting for rework.

Why it happens

On the same item, engineering’s start condition is structure, states, and copy bounds that are clear enough to build; design’s ability to absorb implementation feedback depends on implementation having started. Aligning both on the same item on the same day makes a wait-ring: engineering idles, and design, with no in-progress build to reveal problems, stays in guesswork. Offsetting design output by one iteration breaks the ring into a pipeline — engineering consumes last round’s signed file, design produces the next — with “buildable” rather than “still exploring” as the handoff.

The wait is queuing from a simultaneous start, not a lack of effort. Leading by two or three iterations sends design too far before implementation hits problems, and the pipe clogs downstream as a large change. One iteration of lead is the amount that lets “what engineering is digesting” and “what is being finished next” meet.

Where it stops holding

A two-person group that cannot run two parallel streams — the same person drawing and shipping — has no separate consumer for a one-iteration lead. Sev-1 defects that must be fixed today have no “next round” to lead into. If engineering is blocked on an API, data, or a release window, an early design file does not clear that idle; the idle is not in the design queue. Items still exploring must not enter the lead slot: engineering then receives unfinished input and waiting turns into bounce-backs. Teams whose cycle is only a few days may find a calendar iteration too coarse; offset on a buildable queue instead of on the sprint calendar.

Applying it

• Pull sprint work only from a ready-for-build column of signed design. This round’s design capacity is for what engineering will build next round.
• Write the buildable bar: main path, critical states, real copy or marked variable ranges. Files under that bar do not go ahead.
• Cap inventory: about one round in ready-for-build, not three rounds of design stock.
• How to check: for two consecutive iterations, count whether engineering had a buildable file on day one, and whether design was waiting for engineering to finish before it could continue. Each “no” on the first or “yes” on the second is a pipeline that did not form.

Related

• Same group: R2.12.2 Problems found in implementation must be written back into the design source · R2.12.3 When the joint review happens determines how much work is thrown away · R2.12.4 Exploratory design and delivery design must be scheduled separately
• Nearby: R2.02 Design QA · R2.11 Identifying and paying design debt
• Search terms: design one iteration ahead · ready-for-build · design lead time