Agile in the Age of AI
TL;DR:AI breaks core Agile assumptions. Cross-functional teams matter less when AI fills knowledge gaps — teams shrink to 2 humans plus AI. Coding stops being the bottleneck, so sprints shorten to days. More small teams means coordination moves up a level. Developers become mini-POs deciding what to build, not writing every line.
Scrum is over 30 years old, the Agile principles are over 20 years old, and we are now entering the Age of AI — a strange new world where intelligence is available as a service. How does AI impact Agile?
Most Agile practices and principles are based on assumptions about human behavior and team productivity. Some of these assumptions still hold true, but some need to be challenged and reevaluated — and this will impact the practices.
This article is a mix of observation and prediction: what I've seen happen already, and some speculation about what I think is going to happen in the near future. The main takeaway for the reader is simple — be ready for change. I don't know exactly how things will change, but I'm confident that Agile in the Age of AI looks different from before. Take a step back, look carefully at how you work today, and start questioning everything.
Cross-functional teams
Agile development is normally done by small, self-organizing, cross-functional teams. Cross-functional means the team members have different skills that complement each other — overlapping circles of knowledge.
But why do we actually need cross-functional teams? The underlying assumption is that the team needs a mix of complementary skills, otherwise they can't build whatever they are supposed to build. A cross-functional team has all the skills it needs to autonomously build a shippable product increment with minimum dependencies on other teams.
With generative AI, every person effectively has an AI colleague who is blazingly fast and knows every programming language, every popular framework, every design pattern. The AI's "knowledge circle" is vastly bigger than any human circle (although there is still some human knowledge the model doesn't have).
The models aren't perfect yet — they need human oversight. But one or two people with strong prompt-engineering skills and access to a top-notch GenAI model will outperform a traditional cross-functional team — in both speed and quality. I experience this regularly: with an AI colleague I can build things in hours that would have taken days, and in days what would have taken weeks.
So cross-functional teams are great, but not as important as in the past, since knowledge isn't really the bottleneck any more. A team of 1–2 people + AI has access to most of the knowledge they need. Why 2 people, not 1? Because it's nice to have another human to talk to, and easier to deal with vacations and sick leave.
What happens when team size shrinks to 2 people? Do we fire everyone else? No — smart companies will AI-empower everyone, instead of AI-empowering a few and firing the rest. Firing a bunch of people creates a culture of fear and kills innovation: people won't explore the technology further if improved effectiveness means more people getting fired.
So let's say we originally had 2 cross-functional teams of 5 each. This might now be split into 5 teams of 2 + AI. What do they work on? Depends on context. It's a luxury problem: we now have increased development capacity — what shall we do with it?
Smaller teams = more teams
One consequence of AI-empowered teams: smaller teams, and more of them.
Smaller teams need less internal coordination. If they sit next to each other (physical or digital) and talk informally whenever needed, they hardly need formal meetings — for example, less need for a daily standup when they can just talk. (Although they might do it anyway for social reasons.)
On the other hand, more teams means more cross-team coordination — at least if they're working on the same product and share dependencies. Each team can be seen as a single team-member in a larger "super team", and the rituals (retrospectives, planning) happen at the team-of-teams level.
Most companies will end up with some kind of daily sync and some kind of planning session every few weeks. But the structure changes: cross-team meetings rather than team-internal, planning sessions that focus on the big picture rather than backlog items.
Software engineers (mostly) don't write code
A clear trend: AI models are getting really good at writing code. Not perfect yet, but good enough that it makes sense to have your AI colleague write most of the code. This fundamentally changes the role.
As a software engineer you still need to be in charge — think about the architecture, write the prompts, review the results, take responsibility for code quality. But the actual craft of writing the code — AI will, for the most part, do that faster and better than you. This is partly true already today. Within a year it will likely be true 90% of the time. A developer who insists on manually writing all code in the Age of AI is likely to become a bottleneck and a source of bugs.
Developers essentially become mini-Product Owners: their job is to decide what code needs to be written, not to write it. Comparable to how you write high-level code in a modern language and the compiler turns it into machine code — except now we raise it one level and the AI writes the high-level code too.
Your AI colleague can even work in the background. Imagine this conversation between Bob, Lisa, and their AI colleague MrFixit over morning coffee:
- MrFixit: "Good morning folks! A couple of bug reports came in last night, two of them were pretty straightforward so I fixed them and put up PRs."
- Lisa: "Great, I'll review in a moment. Any risky stuff there?"
- MrFixit: "I needed to change the login a bit. I added more tests so it's probably fine, but that part might be worth some extra reviewing."
- Lisa: "OK, will do."
- Bob: "Hey MrFixit, did you see that Slack discussion on security holes?"
- MrFixit: "Yeah, want me to look into it? I have some ideas."
- Bob: "Yes please."
- MrFixit: "OK, hold on... Done! I put up three PRs with three different approaches. See the PR descriptions for details. Ping me if you want to discuss."
- Bob: "Awesome!"
Sounds exotic now — within a year I think this will be the norm for many teams.
The result: coding is no longer the bottleneck. So what does this mean for Scrum Sprints — a timeboxed period (usually 2–3 weeks) to let the team focus on development? If work that took a week now takes a day, and work that took a day now takes an hour — do we need sprints?
1-day sprints?
My guess: sprints will gradually become a lot shorter, or disappear entirely. Maybe 1-day sprints. Start the day with a quick sync with your human and AI colleagues, decide what to focus on, finish it up and release by the end of the day, do a quick review before going home. Daily Standup and Sprint Planning become essentially the same thing.
With multiple teams working together, there's still a need for a higher-level sync — maybe weekly — to keep alignment. This is true with or without AI, but it gets stronger as we shift to more small teams instead of a few large ones.
There's still a human need for some kind of sync and planning every few weeks. But its purpose and structure will change when development cycles shorten and there's no longer a need to batch weeks of work just because coding takes time.
Roaming or shared specialists?
What about specialists? Say our teams need to deal with databases and persistency, and need specialist knowledge.
Traditionally we'd put a DB person on each cross-functional team. In a 2-person AI-empowered team, the humans lack some skills and rely on the AI colleague. Enough for routine tasks. For advanced tasks, a human specialist is still needed — to formulate the prompt, evaluate the result, build tools, decide which AI models and tools fit, or fine-tune the models to make them better at that specialized knowledge.
My guess: we'll have either roaming or shared specialists. Some agile teams do that anyway — it will become more common. For example with 5 teams, maybe one or two have a DB specialist (the teams that do most DB work), and they're shared specialists who sometimes help other teams. An alternative: roaming specialists who don't belong to any specific team and go to whatever team needs them most.
The job of the Scrum Master or Agile Coach
Traditionally the Scrum Master / Agile Coach teaches and mentors the team — how to effectively split a user story, run a retrospective, work as a team.
An AI-empowered team has all this knowledge already, if it chooses to seek it. So the role becomes more coach and less mentor. If the team wants to know how to split a story, sit with them and write a prompt to ChatGPT. There's the old edict: give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for a lifetime. Now that teams can catch their own fish, you have time to coach more teams and help them figure out how to use those fishing rods.
User feedback loop
User feedback remains a critical part of agile development, even in the Age of AI. But the practicalities change. We release more often, so customers and users should be ready to receive small updates often instead of large updates seldom. Users take a more active part. Some appreciate this; some don't.
If the user isn't available as often as needed, we can create mock users by asking an AI model to role-play a particular type of user — mock user research, mock interviews, eventually mock users trying our system directly and giving feedback. Mock users won't be as useful as real users, but they're faster and more frequent — a useful complement that surfaces the most obvious design issues.
Additional points to consider
Just for fun, I gave this article to Claude Opus and asked it to suggest additional points. Here is the unedited response, which I thought was quite good:
- Impact on product backlog and prioritization: With AI-empowered teams delivering faster, the backlog may need updating more frequently. The Product Owner role might evolve toward strategic prioritization and stakeholder management.
- Changes in estimation and planning: Story points and ideal days become less relevant when AI accelerates development. Teams might need new approaches to planning and forecasting.
- Adaptations in Agile frameworks: Scrum, Kanban, SAFe may need to be adapted. Sprint Planning, Daily Scrum, Sprint Review frequencies and durations will likely shift.
- Impact on team dynamics and collaboration: AI enhances productivity, but consider its impact on team dynamics. Teams will need new ways to foster human connection, creativity, and innovation in an AI-driven environment.
- Continuous learning and skill development: As AI takes over certain tasks, members need new skills — prompt engineering, AI model selection, result evaluation. Continuous learning becomes more crucial.
- Ethical considerations and transparency: Teams will navigate AI ethics — bias, fairness, transparency. Agile practices may need to evolve to ensure responsible AI development.
Recalibrate
My friend Kent Beck tweeted something that captures the essence of what we are facing in all roles and professions: we need to recalibrate what we spend our time on. What does it mean to be an Engineer, a Scrum Master, a Product Owner, an Engineering Manager?
Same goes for Agile. We need to recalibrate our practices. That starts with self-reflection. What do we spend time on? What are our rituals, roles, artifacts? What needs to be challenged, changed, or reevaluated as we enter the Age of AI?
