AI Is Changing Scrum. We Still Need Iteration.

I’m starting to think Scrum is becoming obsolete for some of the work we’re moving toward with AI. We still need iterative development, although I’m less convinced we need all the meetings and administration we’ve built around it. As the way we build software changes, I think we need to reconsider how we organize that work.

Last night, I had a conversation about this and built a dashboard around the idea: teamwork, tracking work, and figuring out where AI could handle documentation, status updates, and Azure Boards maintenance. Building the dashboard doesn’t mean I’ve automated all of that. It helped me think through what the workflow could become and how much effort we spend describing work, updating the systems that track it, and explaining those updates again in meetings. I want AI to take on more of that so we can spend more time thinking through the actual problems.

What happens to Scrum when the team changes?

If a lead developer is coordinating several AI agents, the coordination needs are different from those of a team of developers. The lead still needs to define the problem, divide the work, manage dependencies, review changes, and decide whether the result is useful. Agents working simultaneously can conflict with each other or make incompatible assumptions, so coordination still matters. What changes is how we get the information we need and where human discussion adds value.

A daily meeting to collect status becomes harder to justify when the system could assemble that status from the work itself. To be fair, the Scrum Guide describes the Daily Scrum as a way to inspect progress toward the Sprint Goal and adjust upcoming work. A status report alone doesn’t fulfill that purpose. Automating a report doesn’t automatically replace a useful conversation, either. People still need to resolve uncertainty, disagree about priorities, and make decisions together.

If a meeting mostly consists of reading information that could already be available, though, I think we should reconsider it. As more implementation moves to agents, I expect more of the familiar Scrum routine to lose its purpose. I’m not predicting that every development team will become one person directing agents. I am questioning whether the same process makes sense when the way we produce and coordinate work changes this much.

We still have to think

I keep coming back to Robert C. Martin’s work on Clean Code. The way I understand its purpose from several posts from Bob Martin himself is reducing the headache of maintaining code gives us more time to think about the problem we’re trying to solve. AI pushes that possibility much further. It can help produce code, explain existing code, draft documentation, and work through changes. There’s an opportunity to remove a substantial amount of repetitive effort and give developers more room to think.

I’ve also seen the argument that AI is a snapshot of the past being presented as the future. I think that’s a shortsighted way to judge what it can do. Existing knowledge can become useful in new ways when we connect it to a different problem, and AI lets us explore those connections at a speed that would be difficult to manage ourselves. That ability is a large part of why I see so much potential in it. I don’t think relying on existing information makes the results inherently unoriginal or unhelpful.

That said, somebody still has to understand what should happen and recognize when the result is wrong. An agent can complete a task based on a bad assumption, and several agents can produce a lot of code before anyone notices that the original requirement was misunderstood. A generated update can sound convincing without providing evidence that the behavior works. The developer still needs to ask whether we’re solving the right problem, whether the design fits, and whether the checks support the claim that we’re done.

That’s the part of the job I want more room for. I want to spend less time maintaining records of work and more time understanding the system, making decisions, and checking what we’ve built. AI can help with those activities too, although I still need to be able to examine its assumptions, inspect its work, and take responsibility for the result.

The cards need to change too

I’m also thinking about how we define the work before an agent starts. A board with well-defined cards and an “Outstanding Questions” section gives us somewhere to organize what we know and what still needs an answer. When agents use that board to carry out work, the information on those cards becomes part of the instructions they act on. That changes what I’d want a card to contain and how carefully I’d want it maintained.

A lot of the value I see in working with agents comes from setting clear guardrails. I can specify the changes I want, the parts of the system they can touch, the behavior they need to preserve, and the checks they need to run. Keeping a change small helps me review it, although small doesn’t automatically mean well defined. A request to fix one thing can still leave an agent making decisions I never intended to delegate.

For example, a card asking an agent to “improve validation” leaves a lot open to interpretation. A more useful card would identify the invalid input, describe the expected behavior, limit the affected area, and explain how to verify the result. It could also say when the agent needs to stop and bring back a question, such as discovering that the change requires a database migration or affects another interface. Those boundaries would give me more confidence in letting the agent proceed.

I think this changes the audience for the cards. We often use them to communicate between developers and management, track progress, and explain what’s planned. They would still serve those purposes, while also giving agents the context and limits they need to do the work. The card needs to be readable enough for us to inspect and precise enough for an agent to use. If an important decision only exists in someone’s memory or in an unrecorded conversation, the agent is missing part of the task.

The outstanding questions matter here because a card can look complete while still depending on an assumption nobody has checked. I’d want to distinguish questions that block implementation from questions an agent can investigate within the agreed scope. Some work should begin with investigation and return with findings before anyone authorizes a change. That would let us make progress without treating every unknown as permission for the agent to choose an answer.

Uncertainty and risk might be more useful measures

This also makes me wonder whether we need different measures for the work. An estimate of effort tells us something, although it doesn’t tell us how well we understand the request or what happens if the change is wrong. A task could be quick to implement and still carry substantial risk. Another could take longer while being straightforward and easy to verify.

I’d like to explore an uncertainty factor and a risk factor on the cards. Uncertainty would describe the gaps in our understanding, such as an unclear requirement, an unfamiliar dependency, or behavior we haven’t reproduced. Risk would describe the consequences of getting the change wrong, including the systems or data it could affect and how difficult it would be to reverse. I’d keep those separate because knowing exactly what to change doesn’t necessarily make a change low risk.

I’m not sure yet whether those should be numbers or simple categories with an explanation. I wouldn’t want a precise-looking score that gives us confidence we haven’t earned. What interests me is whether these measures could help decide how much investigation, review, and testing a card needs, along with how much freedom an agent should have. As the work progresses, new evidence could reduce uncertainty or reveal a risk we hadn’t considered.

Iteration still matters

I don’t see AI removing the need to build something small, inspect it, get feedback, and adjust. The Agile Manifesto’s principles already emphasize frequent delivery, working software, and regular reflection. Those ideas still make sense to me. Faster implementation gives us a reason to revisit how we practice them, especially when the time needed to produce a change becomes much shorter than the process surrounding it.

The workflow I’m interested in would start with a small, clear objective, explicit boundaries, and an agreed way to check the result. Agents could help with implementation and routine records. A developer would inspect the changes and the evidence, then get feedback from the people who need the software. What we learn would determine the next piece of work, including whether the next card is ready for implementation or still needs investigation. That still requires discipline, even if it involves fewer scheduled meetings.

Some teams will still benefit from a sprint cadence, while others may need a different rhythm. I don’t think every decision should wait for a scheduled ceremony, and faster code generation doesn’t mean we should rush review or interrupt users constantly. The cadence needs to fit the feedback we need and the risks involved in making a change.

For the dashboard, I’d want updates connected to evidence: what changed, what was checked, what failed, and what needs a decision. Automatically marking a board item complete because an agent says it finished would give us very little confidence. The useful automation would make it easier to inspect the work, see which questions remain open, and understand why a card is ready to move forward.

Teaching developers gets more complicated

Education is the part I’m still working through. Developers need enough understanding to challenge what an agent produces, including the ability to read code, debug failures, test behavior, understand data, and recognize when a design is becoming difficult to maintain. They also need to learn how to define work clearly, identify assumptions, and recognize decisions that require more context. At the same time, I don’t think education can ignore tools that are changing how the work gets done.

There’s a difficult balance here. If AI handles every hard step for someone learning, they may miss the experience that helps them recognize mistakes later. Making them do everything manually doesn’t necessarily prepare them for the workflow they’ll actually use, either. We need to think carefully about which experiences build understanding and how AI can support those experiences without doing all the thinking for the learner.

I’d like to see more emphasis on explaining decisions and demonstrating understanding. A learner could use AI to help build something, then explain the design, investigate a failure, change a requirement, and show why the result is correct. They could also define a task for an agent and explain the boundaries they chose, the questions they left open, and the evidence they would need before accepting the work. Getting working output is part of that. Being able to examine it, change it, and take responsibility for it needs to be part of the assessment too.

For now, I want to keep developing the dashboard around this approach: automate more of the documentation and tracking, make the evidence easier to inspect, and define work clearly enough for both people and agents to use. I still need to work out how the cards should represent outstanding questions, uncertainty, and risk, and how those should affect what an agent is allowed to do. That gives me a concrete next step to build and evaluate.