Collaborative Strategy with Agile

Start with a small, ordinary failure. A team ships a feature on time, within budget, with metrics that look fine at first glance. The standup was tight, the sprint review went smoothly, the velocity chart is trending up. Six weeks later, nobody is using the feature. Not because it was built badly — it wasn't — but because nobody stopped long enough to ask whether it was the right thing to build.

"Go fast and break things" was always a stupid business process. It just got a lot more expensive now that AI handed everyone a much bigger hammer.

AI has changed a lot of how knowledge work gets done. Some disciplines feel upended; others are just starting to notice. It really has gotten remarkably easier to build a functional prototype, but cats have not become dogs. Teams still need to coordinate. Hard decisions still need human judgment. Users still need things that work for them, not just things that ship. None of that changed. What changed is the pace, and the pace is uneven in ways that are going to break a lot of teams that aren't paying attention.

One framework worth paying attention to is dual-track agile. It's not perfect, but the problem it was designed to solve is exactly the problem AI is now making more urgent. With some adjusting it could help corral the bull.

AI in the agile shop

The foundation of rigorous discovery (the Double Diamond, front-loaded user research, long qualitative phases) rested on a specific economic assumption: building is expensive, so you'd better be sure before you start. That assumption has shifted. AI-assisted coding can reduce the effort of building certain features by as much as 80 percent, varying widely by task type. The practical consequence is that "build to learn" has gotten significantly cheaper relative to "research to decide." A working prototype costs less to produce. And that's genuinely useful — faster iteration and earlier feedback are real advantages, and pretending otherwise misses the point.

But that shift comes with two underappreciated risks. The first is strategic. When you've built something — even cheaply — you've already pointed the project in a direction. Discovery research at the front end isn't just about reducing waste; it's about generating the frame within which all subsequent decisions get made. Skip or compress that phase and you don't just skip the research — you inherit whatever assumptions were already baked into the first prompt. Often those assumptions belong to whoever happened to write it.

The second risk is less obvious. If every team is using AI to rapidly validate ideas, and AI tools share training data, biases, and aesthetic defaults, then uniform acceleration produces convergence, not differentiation. Everyone moves faster toward the same place. The teams that will separate themselves are the ones that use a good portion of those efficiency gains for harder thinking — the slow, specifically human work of figuring out what problem is actually worth solving — rather than shipping more iterations of the obvious answer.

The velocity problem operates at a different level. AI makes individual developers faster, but tends to overwhelm the downstream systems that haven't scaled at the same rate — QA, code review, security scanning, architectural review. The volume of code coming out of AI-assisted pipelines is creating bottlenecks that agile wasn't designed to manage. Teams are reporting higher operational risk and more rollbacks, which means the "fast" delivery track frequently generates rework that cancels the speed gains. The bull in the agile china shop isn't malicious. It's just very fast and not particularly aware of what it's breaking.

What dual-track is actually for

Dual-track agile is a framework for running two fundamentally different kinds of work in parallel without letting either one cannibalize the other. Discovery — the creative, qualitative, exploratory work of figuring out what to build — moves at a different pace than Delivery, which is the systematic, predictable work of building it well. Tying those two tracks to the same sprint cycle produced exactly the problems it was meant to prevent: designers feeling rushed, developers waiting on undercooked work, and product managers caught in the middle.

The triad model

The model that makes most sense for a truly cross-functional team puts designers leading discovery, engineers leading delivery, and product managers owning coordination and the overall product direction. The triad isn't divided between tracks — it spans both. What shifts is who leads at which moment.

Done well, dual-track means designers get room to think without being forced into two-week sprints that weren't designed for the kind of work they're doing. Delivery gets a steady supply of well-defined, validated work. The team avoids the classic failure mode of building things users don't need because nobody had time to find out whether they did.

Done badly, it creates silos, gaps between discovery and delivery, and the very disconnection it was designed to prevent. Discovery can lag and starve the delivery pipeline. The overhead of managing two distinct workflows requires organizational maturity that a lot of teams don't have yet. And more discovery tends to generate more ideas, which requires the kind of discipline to stay on a roadmap that is hard to maintain when the generative process is running well.

AI amplifies both the strengths and weaknesses. It speeds discovery cycles, generates concepts faster, and makes prototyping cheaper. It also makes it easier to produce more work than any team can thoughtfully evaluate, and faster to build in the wrong direction if the discovery work that should have preceded it was skipped or rushed.

Where AI actually helps

The coordination problem in any cross-functional team is partly about information: who knows what, when, and what should they do about it. AI turns out to be genuinely useful here — not as a decision-maker, but as a synthesis layer. Pulling together disparate research threads, flagging inconsistencies between what discovery surfaced and what delivery is currently building, drafting documentation that would otherwise fall through the gap between tracks. These contributions free up human attention for things that require human judgment.

For designers specifically, AI is changing what's possible in the handoff between discovery and delivery. A design team that can produce functional prototype code can be way more precise and cover more ground. Fewer questions and clarifications required.

There's a less obvious benefit here too. Ethics and business goals have a habit of getting addressed in separate conversations from the build — the compliance review, the legal check, the executive ask that arrives at sprint review. They show up as constraints, when they would have been more useful as inputs. AI can help by making it easier to ask the right questions early and keep the answers visible as the work progresses. A team with an AI-assisted coordination layer can stay connected to its own values more consistently than one relying on someone to remember to raise the question at the right meeting.

AI hands teams a lot of options, and it hands them faster than most processes were designed to handle. Speed is one of those options — a good one, when applied to the right work. The trap isn't going faster. It's going faster indiscriminately, letting the acceleration happen to you rather than choosing where to use it.

Whatever process a team adopts, it needs to be flexible — flexible enough to handle work that doesn't fit the sprint cadence, and flexible enough to evolve as the tools evolve. Dual-track provides the overarching frame: keep discovery and delivery running in parallel, keep the triad accountable across both, and protect the qualitative work from being consumed by delivery pressure. Within that frame, a Kanban-influenced approach to managing flow — particularly on the discovery side, where time-boxing is often the wrong tool — gives teams the responsiveness they need without losing the coordination that makes the work coherent.

The goal isn't a faster version of the same process. It's a process that uses the speed where speed helps and reserves the time it creates for the work that requires patience. Most teams will get the speed part right. The patience part is harder, and it's the part that tends to determine whether what ships was worth building.