Adapting Team Process for Agentic Coding

Context

When teams embrace agentic coding, the development stage of a story gets faster — sometimes dramatically. But this doesn't mean the team gets faster. It means the team's bottlenecks shift. Suddenly the problems are:

• How do we review and test changes at the pace they're being produced?
• How do we deal with PR pileup?
• How do we keep generated code from degrading the system?
• How do we supply the team fast enough with the right problems to work on?
• How do we protect engineers from a new kind of burnout — one driven by review fatigue, not coding fatigue?

A 2-week sprint often feels out of phase with this reality. You plan two weeks of work, and some engineers finish their code in three days. Now what? You need faster feedback and much quicker communication across the team. Teams that already work hard at smooth handoffs will have less trouble here.

When an engineer finishes a task, they have a choice - do I pick up something new, or do I look for who needs help? Those teams who have the habit of helping each other are going to have an easier time adapting to the agentic flow.

Teams where daily standups feel like an obligation and everyone works solo are different. Those teams don't have the habits that support this shift.

Discussion

Two-week sprints have always been useful because they highlight problems in your process. But they aren't the only way to do that. When cycle times drop far enough, the sprint boundary itself becomes the problem.

When to shift to Continuous Flow

We've had a couple of teams reach this point and want to rethink their process entirely. This means drawing from the Kanban world. In Kanban, teams focus on single-piece flow: rather than selecting a two-week batch of work, they agree on limits to how many items can be at different stages at once. By keeping work in process low, they speed up the flow of value.

One approach, from Mike Burrows' book Kanban from the Inside, is called "reverse STATIK." It's a set of diagnostic questions the team works through on an ongoing basis. They map well to the specific pressures agentic coding creates:

• How do we balance demand and capability at each stage of our workflow? (When dev capacity outpaces QA or PM capacity, this question becomes urgent.)
• How can we refine our existing systems — tools, meetings — to address the problems of today? (Not last quarter's problems.)
• How do we address sources of dissatisfaction and other motivators for change? (Engineers idle while PRs pile up at review. Testers overwhelmed. PMs can't write stories fast enough.)

Burrows' framework is worth reading in full. The point here is that you don't need to invent this from scratch — there are good tools for this kind of diagnosis.

How agents change team dynamics

As code production speeds up, it applies pressure on every other stage. And your staffing probably isn't keeping up.