The Shift Upstream: Why Scrum Must Evolve

For two decades, Agile and Scrum focused entirely on the Implementation Layer. We built rituals (Standups, Sprint Planning, Poker) to manage the scarcity of developer hours. Then we put those rituals in frameworks (SAFe, Scrum@Scale) to improve operating big teams to do big things. While we would argue that these have neglected a real and growing bottleneck for a decade (product vision, operations, backlog), the primary focus of these operating models treated coding as the constraint because it was slow, expensive, and error-prone.

‍

2025 has been the start of an entirely new era for software product development. Bottom line: In the age of AI Agents, code generation and user interfaces are a commodity but vision, architecture and user experience are NOT (although we expect that conclusion will be different one year from now).

‍

Manufacturing principles argue that flow is always better than batch - meaning that we should continuously target a smaller and smaller batch size for any process and eventually we get flow. Like adding points to a square until it becomes a circle, one of my favorite basic geometry lessons. In product development (or the current term “software engineering”), batches are sprints and they are executed as part of scrum practice.

‍

If you give a modern AI agent a perfect specification in January 2026, it can deliver code, tests, and documentation in minutes. The bottleneck has shifted. The new scarcity is not “velocity” (how fast we write code); it is fidelity (how clearly we think).Unfortunately, we don’t yet have the tools for instant fidelity like we do for the code, tests and documentation; therefore my argument for this ecosystem of software product development TODAY is: We don’t need to kill Scrum. We need to move it Upstream.

The New Topology

Providing every existing engineer access to AI coding assistants but keeping them in the current scrum practice will have minimal impact on the overall product delivery. Theoretically every engineer can “write more code”, but operating in time-bound sprints in existing separations of responsibilities among teams will hold us back. Conversely, we can just make each developer or designer or QA engineer a full stack AI cowboy delivering completed and tested features but if those are still “scrum-bound” will not realize the potential of AI enabled product building.

Anyone with a critical eye will recognize that “Agile” might just be “small waterfall”, if not in theory then in practice. It has long been a problem that the design tasks are not discovered and delivered with the proper cadence and definition as the traditional product manager and engineers require. So when we consider a new model we need to also avoid “micro waterfalls” which might exacerbate the design-development timing and flow.

The Producer: Responsible for harmonizing the two cadences

The new technology and the new model require a new role. The Producer is the single role accountable for product intent, priority, and coherence in an AI-driven development model, replacing the traditional Product Owner. As implementation speed accelerates under AI, the primary constraint shifts to clarity and judgment: what to build, what it means, and whether it is worth building at all. The Producer owns that constraint end-to-end. They set priorities, define outcomes, and translate vision into high-fidelity intent that is safe to execute. Rather than managing backlogs or story acceptance, the Producer ensures that Context Packets represent coherent, deliberate product decisions and that rapid AI-assisted delivery produces a unified product rather than a collection of disconnected features.

To be successful, a Producer must operate with real decision authority and strong technical and experiential fluency. Their effectiveness comes from knowing when to slow thinking down so execution can accelerate, enforcing clarity without over-specification, and making trade-offs explicit early. Great Producers design tight feedback loops between discovery, delivery, and real-world usage, continuously refining intent as learning emerges. They do not act as intermediaries or process managers; they are owners of product truth. In a world where building is fast and cheap, the Producer’s value lies in disciplined judgment, ensuring that what ships is intentional, coherent, and worth the cost of maintaining.

Right-Sizing Definition Output for Limitless Execution

We must stop forcing AI agents into human-speed sprints and humans into AI-speed chaos. The solution is to decouple the organization into two distinct operating modes that connect via a rigid API: the Context Packet.


1. Upstream: The Context Team (Scrum “moves” here)

• The Cadence: 1 week Sprints.
• The Team: Producer, Architect, Context Engineer.
• The Goal: They deliver “Context Packets” defining new product capability and the constraints for how it will be implemented to best align with the product architecture and operating model.
• Definition of Done: A packet is “Done” only when it includes the Schema, the Business Rules, and the Constraint Tests (e.g., specific MSW states or Postman collections) required to validate the AI’s output.
• Why Scrum? Humans need time to debate, think, prioritize, and collaborate. Use of a 1 week sprint is proposed because a smaller team moves faster and we DO of course have AI agents which make this process fast.

2. Downstream: The Implementation Team (Kanban)

• The Cadence: Continuous Flow (No Sprints).
• The Team: A product dependent mixture of engineers who use code, design, test and delivery agents to turn context packets into functioning ready to use software. The team will require a number (proportional to implementation team size) of agent engineers who are not executing on the context packets but rather managing their toolchain of agents, infrastructure, observability and metrics. They are critical in our current era of rapid change for any team to be successful.
• The Workflow: Team operates from a Queue, not Scrum.
• The Secondary Output: In addition to the product delivery, a single team using the same tools will empower our next important evolution toward prompt efficiency, multi-agent tasking through context RAG, testing feedback loops, etc.
• ‍