The Upstream Trap

This is part 2 of 4 in a series about Product Development teams with AI agents (agentic SDLC). The other parts are linked at the end.

The slowest part is now upstream of code

In companies on the frontier of agentic software production, the slowest part of delivering software is no longer the developers. It is the work done before code is written.

• Ideation ↓
  • Deciding whether to buy or build ↓
    • Procurement or internal resourcing ↓
      • Goal alignment ↓
        • Requirements alignment ↓
          • “Prompt”

For decades, large organizations staffed roles and departments that orbit the delivery teams: business analysts, solution architects, project managers, a project management office, requirements reviewers, and architecture review boards. Their job was to pre-digest requirements, to chew on the problem in advance so the programmers could (hypothetically) implement quickly without stopping to ask questions.

It was never a good idea, but it was understandable. Every hand-off reduces knowledge and context, and every specification is a guess about what users need. It was a coping mechanism when the bottleneck was code — but the bottleneck moved (see part 1 of this series). Code is no longer scarce and all of that upstream machinery is the new constraint.

The common error: treating a prepared requirement as progress

Does this sound familiar? A backlog with forty items, each one refined, estimated, and signed off. A roadmap approved for the next three quarters. But that isn’t progress; it is inventory. Let’s make that distinction clear:

Inventory

Work that has cost money and effort but hasn’t reached a user yet.

Example: Forty refined, estimated, signed-off items waiting in the “Ready” column.

Progress

Delivering something new into the hands of end users, and learning from it.

Example: “We shipped the new MFA security feature, and occurances of stolen accounts dropped 90%.”

It’s always been too easy to brush away this problem. Which problem?? The problem of thinking that documents=progress. Donald Reinertsen shared a crucial insight in The Principles of Product Development Flow (2009). One of his principles reads:

“Product development inventory is physically and financially invisible.” — D. Reinersten

It’s a reminder that a specification is inventory. So is a refined backlog item, an approved design, and a roadmap. They are work about the work.

The sawmill: a metaphor

Picture a sawmill yard with countless stacks of logs, all waiting for access to one of the saws. The saws run continuously and as fast as possible — but they’re expensive, slow, and scarce. So the company employes people, forklifts, and trucks to ensure logs can be moved to whichever saw is available. All of that machinery is expensive to buy, run, and maintain, and it takes an entire crew to keep it working. The yard crew feels busy and overworked.

I’m sure you see the connections to the real world

• The logs are Jira items.
• The trucks and forklifts are the labyrinth of “boards” in Jira.
• The yard crew is made up of business analysts and project managers waiting to shove requirements at the coders.
• The saws are teams of coders.

Then everyone gets a magic saw!

Gone is the massive inventory of pre-selected logs. Every one or two developers can produce sophisticated shapes made to order. That’s what coding agents did. Anyone on the team can pick up a log and cut it.

Problem category #1: what to build

I meet some teams who kept their Product Backlogs to a minimum. As coding agents have become part of their workflow, they suffer problem #1…

Consider our metaphor: when saws were scarce, scarcity forced a choice. You couldn’t cut every log, so people argued about which stack went to the saw next. When everyone has a magic saw, they can cut anything and everything. The product easily fills with features nobody uses. Everyone is excited by their rapid outputs; they’ve lost track of outcomes.

Problem category #2: enterprise bloat

All the machinery upstream of the saws is now in the way. The yard crew still sorts logs months ahead, and the forklifts and trucks (all those Jira boards, workflows, and the admins who keep them running) still haul each stack to a saw (a development team). People with saws in their hands stand around waiting for a stack of logs. The yard is the bottleneck, and most of it is no longer necessary.

And it gets worse. Many logs were sorted months ago for orders that have since changed. Customers requested something a year ago, they’ve waited, and (whether they know it or not) their needs have since changed.

Batch size and the cost of waiting

Donald Reinertsen explained the economics; he advised: If you only quantify one thing, quantify the cost of delay. Every week a log sits in the yard, someone pays for it.

He would also say: Reducing transaction cost per batch lowers overall costs. Coding agents put a magic saw in every pair of hands, so the stacks should shrink. If they didn’t, it’s because the cost in the yard didn’t fall. If the bureaucracy still expects every Jira item to contain detailed information, a review, and a sign-off before it moves to the developers, then the enterprise is still funding inventory not product.

How the upstream trap shows up at work

“Definition of Ready”

A dozen checkboxes, including sign-off by people who aren’t on the team.

Metaphor: The yard crew’s sorting rules. No log moves until every field in the Jira item is filled in.

What to do about it: Delete it. Find every so-called “Definition of Ready” across the enterprise and delete them all. Do this immediately.

Replace with: Rapid prototyping and UX discovery work.

The “Ready” column

Probably contains two or three Sprints of Jira items, refined and waiting.

Metaphor: The stacks waiting for a saw. Some logs were sorted for orders that no longer exist, and all of them are ageing.

What to do about it: Get with key stakeholders immediately and review those items. Filter to what’s still relevant and what’s now obsolete.

Refinement sessions

If more than a few minutes are spent detailing items that won’t be started for months, stop.

Metaphor: Asking the yard crew to move and sort logs for orders the buyer doesn’t need yet, and may never need.

The labyrinth of boards

😱 Portfolio boards, program boards, project boards, team boards, and the workflows and admins that link them.

Metaphor: Those are the forklifts, trucks, and stacks of inventory. Everything consumes gas and needs maintenance.

What to do about it: Go immediately to the people closest to the coding agents and ask them: “What exactly will help you to make the current and near-future work transparent to each other and the key stakeholders?”

The quarterly PI planning event

A large batch of features committed months before any of them will reach end users.

Metaphor: The yard crew standing around talking in detail about every log to be cut in the next three months.

What do do about it: Do it bi-weekly, not quarterly. And do it in a much smaller room — no more “Big Room Planning” — what used to require legions of people can be achieved by tight-knit, cross-functional teams. (The armies of developers and the people who orbit them can now be split into many independent squads.)

The metrics

Percent of backlog refined. Sum of story points. Jira items "ready." 🤮

Metaphor: Measuring the number of logs sorted.

What to do about it: Measure time-to-learn and actionable value metrics. (See Evidence-Based Management)

Now add agents

Everyone has a magic saw now!

Pitfall to watch for:

• Programmers may whip through the current backlog faster than the upstream bureaucracy can analyze, decide, and approve of new work.
• So, to cope, managers may respond by hiring even more upstream staff to work even further ahead.

That is a category error. Managers who do that are still treating code as the bottleneck, mistaking a flow/throughput issue for a capacity issue.

What to do instead

Today

Cap upstream work-in-progress. Limit how far ahead product managers and analysts can define work.

Redefine the Analyst/PM roles. Shift upstream staff from “spec writers for devs” to “validators of outcomes”.

Shift developers upstream. Encourage software engineers to participate directly in discover, architecture, and product framing. (This has always been a good idea; now it is a competitive imperative.)

Start measuring the age of your Jira items

Work item age is one of the flow measures in the Kanban Guide. Use it on the upstream columns too, not only on work in progress. (See Kanban.)

The goal

The outcome to strive for is:

• Minimal inventory. The sawmill yard gets smaller and the logs are harvested just-in-time.
• People stop asking “Is this fully specified?” and instead ask “What will we learn when this reaches users?”
• Analysts and SMEs stop thinking their job is to shove requirements at the coders. They instead realize their job is to sit with them. (That’s the subject of the next article in this series.)