Developer velocity is more unpredictable now than it was when writing code was the obvious bottleneck. Prompting skill gaps, codebase complexity, greenfield vs. brownfield tradeoffs, and the rate at which models keep improving mean your old estimation data is effectively stale. Planning tools built around stable velocity — sprints, story points, burndown charts — rest on an assumption that no longer holds.
Why old agile feels broken
Estimation is noise. Sprint commitments assume a predictable output per engineer. That assumption is gone.
Ritual cost vs. value. If planning meetings aren't grounded in real velocity, they're burning time without producing alignment.
Bottleneck has shifted. Code generation is fast. The constraint is now spec quality and product owner availability.
What to experiment with instead
Treat specs like code
Product specs are the new unit of developer input. Store them next to the code, version them, and maintain them with the same discipline. Vague specs = wasted engineering time + wasted tokens. POs, engineers, and designers need to collaborate on refining them — kanban boards and ticket comments are the right venue.
Use LLMs for first-pass estimation
Let a model generate ticket estimates and flag spec gaps before your team sees them. Use ritual meetings to review and calibrate — not to produce the estimates from scratch.
PO availability is now a hard dependency
A blocked developer costs more than ever. Product owners should be on-demand for clarification — don't let async lag become the slowest thing in the system.
Count services, not just features
Agentic tools make it cheap to spin up new code. The hidden cost is maintenance surface. Each new service adds untracked small tasks that don't show up in your velocity metrics but quietly consume real capacity. Factor active codebase count into your capacity model.
The honest answer: there's no settled "new agile" yet
Teams that don't need audit trails should seriously consider dropping heavy process altogether. Teams that do need transparency should treat this as an active experiment — the goal is finding the minimum viable process that keeps stakeholders grounded without creating drag your engineers resent.