The Three Parallel Workstreams: How Design, Build, and Test Start on Day One Without Colliding

A developer describes running three parallel workstreams — design, build, and test — off a single discovery session in an AI-augmented SDLC, arguing that sequential delivery persists because of a "Blame Myth" in which developers who start early personally own any rework. The approach removes that penalty by explicitly budgeting for client-driven scope changes, which the team estimates at roughly 15 to 20% of built scope moving after discovery.

Episode 3 of the AI-Augmented Parallel SDLC series. The pillar article https://www.tech-sprinter.com/blog/the-ai-augmented-parallel-sdlc laid out the blueprint: discover once, run three workstreams in parallel, converge at one gate. Episode 1 https://www.tech-sprinter.com/blog/the-handoff-chain-why-your-team-is-mostly-paying-handoff-debt put numbers on what the handoff chain costs you. Episode 2 https://www.tech-sprinter.com/blog/the-joint-discovery-session-why-five-perspectives-beat-one-requirements-document got rid of the handoff at intake. This one covers the question everybody asks first and almost nobody answers properly, which is what actually happens on Monday morning. The first time we ran three workstreams off a single discovery session, I spent most of the week waiting for the crash. It was a mid-sized engagement, an invoicing and approvals module, nothing anyone would call exotic. Discovery wrapped on a Thursday afternoon. Friday morning the developers started building, the BA started elaborating scope, and QA started drafting test scenarios, all three at once, working from notes that were less than a day old and a requirements document that did not exist. I checked the dev channel far more often that week than I needed to. On the Tuesday I asked the BA twice, in about four hours, whether anything had changed that the developers needed to know about. She told me the second time that she would tell me if it had. Nothing crashed. Not that week, not on that engagement, and not since, though I want to be careful here because it took us two more projects before I could explain why rather than just report it. The explanation has two parts. One of them is a cultural thing that most teams never say out loud, and the other is a twenty-minute exercise with a whiteboard. If you ask a delivery lead why development can't begin before requirements are signed, you'll hear something about uncertainty. Unstable ground, wasted effort, building on sand. It's a perfectly reasonable answer and I gave it myself for years. It also isn't what's really going on. What's really going on is that in a sequential model, a developer who starts early and builds something that later turns out to be wrong ends up owning that waste personally. It becomes their rework, their velocity dip, their thing to explain in the retro. A developer who waits for sign-off and then builds precisely the wrong thing, on the other hand, is completely covered, because the signed document told them to. Same wasted fortnight, two very different conversations. So waiting isn't timidity. Given how we've set up the incentives, waiting is just correct, and it will be correct every time until somebody changes the incentives. I've started calling this the Blame Myth, and I think it's the wall holding up sequential delivery. Those long requirements phases aren't genuinely an attempt to reach certainty, because everyone sitting in the room already knows certainty isn't on offer. What they're really doing is establishing in advance whose fault it's going to be. The document functions less like a specification and more like an insurance policy, which is also why it keeps growing and why nobody ever feels it's finished. Both models receive the same change request. Only one of them needs somebody to be at fault for it. Parallel delivery doesn't fix this by asking anyone to be braver. It fixes it by taking the penalty away. We tell the team, out loud and then again in writing, that the client is going to change their mind. Not that they might. Across our engagements it lands somewhere around 15 to 20% of built scope moving after discovery, and it has been consistent enough that we now put it in the plan and price it. It gets estimated, funded and scheduled in the same unremarkable way that testing or deployment does. Once rework is sitting there as a line item instead of arriving as an incident, the arithmetic flips for everyone involved. A developer who starts on day one and absorbs a change three weeks later hasn't failed at anything. They've done the thing the plan said they'd be doing, and nobody's opening a defect against them for it. Stop trying to prevent change. Plan the rework instead. The client gets velocity and something real to look at early. The engineering team gets to stop being defensive. Those two usually get framed as a trade-off, one bought at the other's expense, and I don't think they are. They both fall out of the same decision. The economics here have shifted recently, and more than people have adjusted to. Our standard now is that pre-sale notes, early client thinking and whatever half-formed ideas came out of the first conversation get turned into a running build almost straight away. If a client call is confirmed for Monday, we aim to walk into Tuesday's meeting with something they can click. Not slides, not wireframes, an actual interface with their workflow in it. That's only possible because prompt-to-UI generation has taken the cost of a structural first draft down from about a fortnight to an afternoon. Five years ago "let's just build it and find out" was reckless advice that I would have argued against. The first version is now cheap enough that not building it is the more expensive choice. The bigger effect isn't the time saved, though. It's what it does to the conversation. Clients are poor at reviewing abstractions and very good at reacting to interfaces. Hand somebody twelve pages of requirements and you'll get typo corrections and a comment about the order of two sections. Put a screen in front of them with their own process half-implemented and you'll get the objection that actually matters, usually inside ninety seconds, and usually the one that would otherwise have shown up at UAT four months later with three sprints of work sitting behind it. The hatched blocks are handoff debt from Episode 1, drawn to scale. Nobody writes those days down anywhere. Sequential delivery divides work up by phase, design then build then test, on the assumption that the dangerous variable is time. Work done early is work done on unstable ground, so you stabilise the ground first and then walk everyone across it in single file. The flaw in that is that scope isn't uniformly unstable. In any feature set there are things the client will never revisit and things they'll change their mind about twice before lunch, and when you treat both as equally volatile you end up parking the entire team to wait for permission that only a handful of items ever actually needed. So at the end of discovery, before anybody opens an editor, we spend twenty minutes going over the captured scope and asking one question of each item on it: If the client changed their mind about this next Tuesday, what would it cost us? You get two variables out of that question, how likely the change is and what it would cost, and between them they sort the scope into four piles rather than the two people expect. Twenty minutes, a whiteboard, and the four piles that decide how your week goes. | Quadrant | The strategy | What belongs here | |---|---|---| | Stable core | Build it on day one. Expensive to change, unlikely to change. The safest work in the building. | Domain entities and relationships, authentication and roles, the navigation shell, integration boundaries and data contracts. Nobody wakes up on a Tuesday and decides an invoice shouldn't have a customer. | | Decide first | Top of the decision queue, week one. Expensive and likely to change. Get these answered before Friday or parallel work really is a gamble. | Multi-tenancy and data isolation, immutable versions vs in-place edits, audit and compliance obligations, how money is represented. | | Volatile edge | Build the seam now, fill it in week three. Likely to change, and cheap to change as long as the seam exists. | Approval thresholds and routing, notification and escalation policy, pricing and fee logic, field-level validation, partial-failure behaviour. Put it behind configuration, a feature flag, or a strategy interface. | | Just build it | No ceremony required. Cheap and settled. | Static copy, standard CRUD on settled entities, conventional form layouts, admin and housekeeping screens. Most of what an agent scaffolds in an afternoon. | The decide-first pile is the one that earns the exercise. There are rarely more than four or five things in it, and they're the entire reason the BA keeps a ranked decision queue rather than a flat list of open questions. Everything else can carry on while the client is still making up their mind, which is the whole trick and, in fairness, the only genuinely clever part of any of this. Every stream launches with one deliverable for the week and one hard constraint. People remember the deliverable. The constraint is the part doing the work. The bottom row is the one teams skip, which is a shame, because it's the one preventing the collision. Ships by Friday: a clickable frontend with real navigation, real screens, real interaction and stubbed data behind it. In practice this is Tuesday's prototype, cleaned up and hardened into the actual product shell. The guardrail: the application is the design artifact. Designer and developer work on the same running build, in the same repo, in the same week, and no files get exchanged, so there's nothing to drift apart. Must not do: implement volatile business rules. If somebody is hardcoding an approval threshold in week one, the volatility split didn't work and you've already booked the rework. Ships by Friday: elaborated stories and rules against the stable core, plus a ranked decision queue with the decide-first items sitting at the top of it. The guardrail: the BA runs the client back-and-forth exactly as before. Review cycles still take days, the stakeholder nobody mentioned still turns up in round three with opinions, all of it still happens. It just stops holding three other people hostage while it does. Must not do: treat the running build as the spec. Once the BA starts writing down what got built rather than what was meant, the model has quietly inverted itself, and in my experience nobody notices for about a month. Ships by Friday: scenario-level coverage pulled from the QA notes taken during discovery, so risks, boundaries and failure modes, along with test data preparation and automation scaffolding. The guardrail: write outcomes rather than clicks. "A partial batch failure commits the clean rows and returns an error ledger" will survive every redesign between now and the gate. "Click Upload, then Confirm, then check the toast text" will not survive the first one. The suite stays scaffolding until sign-off, and at the gate it gets aligned to the signed requirement and locked. Must not do: run executions against un-signed-off stories or unstable builds and log what comes back as defects. This matters more than it sounds like it does. Testing against fluid requirements manufactures churn out of nothing, punishes the developer for having started early, and walks the Blame Myth straight back into a process built specifically to get rid of it. Of all the ways to lose this model, it's the fastest. Parallel work doesn't fail in unpredictable ways. It fails in three recognisable ones, and none of the fixes is a meeting, mostly because rituals quietly decay the first time a deadline gets tight and structure doesn't. Three failure modes, three structural answers. Not one of them is a standup. 1. Design drifting from build. The designer produces screens that can't be built at a sensible cost, or engineering invents patterns nobody specified. Drift needs distance to happen, and the file exchange is where the distance comes from. A Figma handoff is still a handoff, it just has a friendlier name. Put both people on the same running artifact in the same repo and whatever gap is left closes in a ten-minute conversation, because the thing being argued about is right there on screen and clickable. 2. Requirements diverging. A rule lands in week three that contradicts something built in week one. You can't prevent this and I'd be suspicious of anyone claiming otherwise. What you can do is make it visible and make it cheap, which takes two things: the seam, so it lands somewhere editable rather than in the foundations, and a broadcast rule, so that any change to shared understanding gets announced on the day it's decided rather than the day it's documented. Silent absorption is what hurts. A BA updating a story quietly because it obviously should have said that all along is how you end up with an integration surprise. 3. The test suite churning. QA writes step-level cases against an interface that's still being designed and then rewrites the suite three times before the gate. The intent never actually moved. Only the steps did. We don't run a daily standup across the three streams. We did try, and within about a fortnight it had turned into three people reporting progress to each other with nothing to decide, which is a meeting I've sat in enough times to recognise early now. What we run instead is a divergence sync, three times a week, capped hard at twenty minutes, with one question asked of each stream. What changed in your understanding since we last spoke, and who does it affect? Not progress, not blockers, just deltas in understanding. If nothing changed, that stream says so and we move on, and some weeks the whole thing is over in six minutes, which is a good sign rather than a wasted slot. Anything that can't be settled in the room goes onto the BA's decision queue for the next client session. Running three streams in parallel used to mean roughly tripling the headcount, which is why the idea stayed academic for about twenty years. The pillar article split every role into three parts: production, memory and judgment. Agents have absorbed the first two, judgment stayed human and named and accountable, and that split is the only reason any of this is affordable now. The rule is the same in all three and it doesn't bend: the agent drafts, the human reviews and owns. Nothing gets into the baseline, not code, not a story, not a test case, not a test result, without a named person's signature on it. Nobody announces they're abandoning this. It decays instead, in a handful of familiar ways, and slowly enough that all the ceremonies stay in place while the thing underneath them stops working. Four numbers will tell you whether this is actually working. If you only track one of them, track the last one. Read the second one carefully, because it's the one people get backwards. You aren't aiming for zero divergence. Zero means the team waited, which is to say you bought certainty with calendar time and then described it as discipline. A stable, predictable band is the healthy result, and a number that swings wildly month to month usually means discovery isn't doing its job rather than that delivery isn't. The fourth is the early warning system for everything else in this article. If every piece of rework is going into the tracker as a defect, the culture has already reverted, whatever the process documentation still says. The three streams don't stay aligned because the people running them coordinate especially well. They stay aligned because the work got divided up so that being slightly wrong is cheap, and because nobody gets punished when it happens. Get those two right and parallelism stops being a risk you're managing. It just becomes how you work. The AI-Augmented Parallel SDLC https://www.tech-sprinter.com/blog/the-ai-augmented-parallel-sdlc — the full blueprint: discovery once, three parallel workstreams, one gate. Episode 1: The Handoff Chain — Why Your Team Is Mostly Paying Handoff Debt Episode 2: The Joint Discovery Session — Why Five Perspectives Beat One Requirements Document Next up — Episode 4: The Quality Gate, and the one word that decides whether your parallel model survives its second quarter, which is why convergence findings have to be logged as requirement gaps rather than defects. What's the split in your current sprint? How much of what you're building is genuinely volatile, and how much of it has just been waiting for permission?