The five stages of Scrum Master AI maturity
Article content
Article sections
When I first heard about the internet I thought it was a cooler way to send memos. My son, when he was small, could not understand the phrase "data in the cloud" because clouds are weather. My brother, the first time I described AI chatbots to him, asked why anyone would use one when you could just google it. And I will tell you that for the first six months I had access to an LLM, I did not understand how an agent was meaningfully better than a chatbot, because the only problems I was trying to solve were the problems a chatbot already solved.
Each one of those moments is the same moment. We meet a new tool and we ask, in good faith, how it can be used to solve yesterday's problem. We do not yet have the experience to ask whether a whole new class of problems has quietly arrived. The question is invisible to us until we have crossed into the place where it becomes visible, and then we cannot unsee it.
Over the past two years I have climbed a ladder of five stages in how I personally use AI in the Scrum Master role. Most Scrum Masters I talk with are still on stage one, and most do not yet know there are four more stages above them. Each move up the ladder is a paradigm shift you cannot see from the rung below. Each one also produces a new bottleneck that you did not have to think about at the rung below, and the new bottleneck is usually what tells you it is time to climb. This is the first post in our Jagged Intelligence series; the ladder is a way to see the shape of the journey before you are inside it.
The five stages, in the order I climbed them
Before I walk the ladder I should say one thing about how it works. Each stage is a paradigm shift, which means it is a different way of seeing the tool, not just a different way of using it. The reason I am saying that up front is that most readers will see stage three or stage four described and assume it is fancy stage one. It is not. The thinking has to change before the tool change is worth anything; the tool change is the last thing that happens, not the first.
Vibecoding by hand
You write a prompt into a chat window. The LLM gives you a result. You read it, decide whether to trust it, and paste it into wherever you actually do the work, which is usually a doc, a slide deck, a sprint plan, or a piece of code. Almost everyone starts here, and a lot of very productive Scrum Masters never move off this stage, which is fine for what it is. I built two websites and the registration automation for one of our courses doing this for about a year.
New bottleneck at this stage: trusting the output. The LLM is occasionally wrong in confident-sounding ways and the only check is your own eyes. The work scales with how much you can read carefully, and reading carefully is the slowest thing humans do.
Let the agent iterate on its own work
You give an agent (Claude Code is the one I use; there are others) access to your codebase, your shell, and the file system, and you let it iterate against a problem until the problem is solved. The first time I watched an agent run a test suite, see a failure, fix the failure, run the suite again, and keep going for thirty minutes without me, I understood something about the previous stage I had not understood from inside it. The copy-paste loop was missing the iteration. An agent has iteration built in, and that is what makes it qualitatively different from a chatbot.
The unexpected consequence at this stage is that you stop reading every line. You start reading the agent's plan, watching its progress, and reviewing the final state of the change. The skill you have to develop is a different reading skill; less close-reading, more diff-reading. That took me about six weeks to develop and is, I think, the second-most-undertaught skill in agile coaching after vertical development.
New bottleneck at this stage: data security. The moment your agent has access to anything sensitive (an API key, a customer database, a private repository) the question of what the agent is allowed to read and what it sends to the model provider becomes a serious one. Most stage-two practitioners are doing this on personal machines with personal context; the moment the company asks you to do it on the company codebase, the security review starts.
An agent per product, living where the team lives
The next paradigm shift, for me, was the move from a personal agent I used in my own terminal to a per-product agent that lives in the team's Slack channel and that anyone on the team can prompt. We did this for one of our courses first, then for the others. The agent watches the channel, gets called by name, picks up context from the channel history when relevant, and writes to a small set of tools we have given it (Notion, our scheduling sheet, our CI). The team treats it like a teammate who has a very narrow expertise but who is always available.
What surprised me here is how quickly the team's expectations of the agent grew. The first week it was a curiosity. By month two, when the agent was down for an hour, three people pinged me asking if it was sick. The agent had moved from "thing Erkan uses" to "thing the team relies on," and that move is real organisational infrastructure even though there is no headcount line item for it.
New bottleneck at this stage: cost. A personal agent costs a few dollars a month. A per-product team-shared agent that runs all day, picks up tasks, and uses the frontier model class can cost more in API credits than the team's coffee budget. AI is no longer democratised at this stage; you are paying for what you use, and the company has to decide whether to fund it.
One agent that delegates to the others
By stage four I had several per-product agents, and managing them was starting to feel like managing five direct reports, which is to say it was eating my calendar. So I built a delegating agent. It watches my email and our shared inbox, classifies what comes in, and routes the work to whichever per-product agent can handle it. When a student registers for a course, the super-agent accepts the registration, fixes the automation if it broke, and replies to the student. When a tool is misconfigured, it asks the right per-product agent to fix it. When something genuinely needs me, it surfaces only that. I am still in the loop for the hard ten percent.
The unexpected consequence here is how much it changed what I spend my own time on. The bottom of my list (email triage, registration plumbing, small fixes) more or less disappeared. The top of my list (the coaching conversations, the curriculum decisions, the writing) got more space. The team feels the same shift; we are not faster at the small stuff, we are absent from the small stuff.
New bottleneck at this stage: leadership. A super-agent that delegates to other agents is, structurally, a leader of a small team, and the question of how it leads (its instructions, its escalation thresholds, its tone with the humans it interacts with, its handling of disagreement between sub-agents) is a leadership question. Most Scrum Masters arrive at this stage with no formal leadership training beyond their lived experience, and the new thing they have to learn is leadership at a scale they could not have practised before because the team did not exist before.
Multiple agents collaborating without you
The last stage is the one I am only just starting to live in, which means I am writing this with less authority than the earlier four. An agentic team is several agents, each with a different role, each able to talk to each other and to the tools they need (often through something like the Model Context Protocol), with one of them (or a small leadership layer) coordinating the work, and with the human (me) involved only at the planning level and the exception level. This is the stage where the team is genuinely autonomous on a class of tasks, and where the question of what to delegate to the team versus what to keep for the humans becomes the central daily decision.
This is also the stage I cannot describe well yet, because I am inside the shift right now and the language for what it actually is is still being invented. The closest analogue is running a small department; the difference is that the department's tools are LLMs and the department's commute is your monitor.
New bottleneck at this stage: orchestration. With five or ten agents working in parallel, the question is no longer can-the-agent-do-this; it is which-agent-should-do-which-piece-of-this. Designing the work-allocation across an agentic team is a discipline of its own and the practitioners who are good at it are scarce. Expect this to be the highest-paid skill in the role in two years.
Why naming the bottleneck at each stage matters
The bottleneck at each stage is the practical reason you cannot just decide to leapfrog. It is also the cue that tells you when to climb. If you are at stage two and you find yourself bumping into data security in every conversation with the team, you are not failing; you are about to graduate to stage three, and the way the graduation happens is by getting the security frame solved. If you are at stage three and your monthly API bill keeps surprising the CFO, you are not unprofessional; you are about to graduate to stage four, where the delegating agent can route work to the cheapest model that does the job rather than always using the frontier one.
This is the reason the ladder helps. It changes the question from "am I doing AI right" to "what is the bottleneck I am bumping into, and what does the next rung do with that bottleneck." That is a much easier question to act on. And it has the side benefit of stopping the comparison to other practitioners at other stages, which is mostly a waste of attention; we are not in a race, we are in a climb.
What changes when you climb
Two things, and they are both quieter than the LinkedIn discourse would suggest. The first is that the variety of tasks you can actually finish in a week goes up substantially. Not the speed at which you do one task; the number of tasks you can keep alive in parallel. The bottom of your list stops being where work goes to die. The second is that the texture of what you do changes. Less plumbing, more design. Less doing, more deciding. That texture change is the one most practitioners I talk with did not expect, and is the one they end up enjoying most.
The texture change is also the place where the connection to the rest of agile coaching becomes obvious. The five-stance map for a Scrum Master and the five-stage AI ladder are not the same thing, but they rhyme. Both name a place where most of us start, both describe a series of paradigm shifts as you move up, and both have the same uncomfortable property that the higher rungs are invisible from the lower ones. The five-stance map is about how a human Scrum Master meets a team. The AI ladder is about how a Scrum Master meets a fleet of agents. Both rest on the same underlying skill, which is the ability to read what the situation in front of you actually needs.
What to do this week
Pick the rung you think you are on right now. Be honest; almost everyone reading this is at stage one or stage two, and being at stage one is not a failure of practice. Then read the description of the next rung up. Notice the bottleneck described for your current stage; ask yourself whether you have started to feel it. If you have, that is the signal that it is time to climb. If you have not, do not climb yet; the bottleneck below is what makes the move worth its cost, and climbing without it is usually how practitioners burn out on AI before they get any value from it.
This is the first post in our Jagged Intelligence series. The next five posts will walk the Product Owner version of this ladder, a verification field guide for when agents lie to you, the stance map updated for the age of agents, an AI risk facilitation exercise for your retro, and a longer treatment of why prompt engineering is a stage-one skill. If you would like the series delivered to your inbox as each post lands, the series subscribe form is on the series index page. If the AI side of the Scrum Master role is the one you want to develop fastest, our CSP-SM programme is where we walk through the leadership skill the higher rungs ask for, and our companion coaching mindset piece is the right place to sit with the stance question before you act on the technology.
Write back when the welcome email lands if you want to talk about the bottleneck you are currently feeling. Most of what surfaces in those conversations is that the bottleneck has been there for a while and the practitioner has been carrying it without naming it. Naming it usually does most of the work. The replies reach Brock and me directly.