Part II. The team: people and agents

The Scrum Master doesn't need to master AI: they need to see what it does to the team

Self-management and high performance with AI

Two people who review everything

In the GymApp Sprint Retrospective, Olga, the Scrum Master, asked each person to say how much time they spent each week reviewing code they hadn't written. Germán said almost half his week. Unai said the same. Aitana, who had joined two months earlier, said almost none, because whatever she generated with AI, they reviewed.

Nobody had decided this. It had just happened. Since the team started using AI to write code, the two most senior people had become the filter for everything, and they were exhausted. The team was delivering more than ever, and Germán had gone three weeks without touching the booking architecture, which was what worried him most.

Olga didn't know how to code with AI better than they did. But she was the only one watching how the team worked, not just what it delivered.

The same job, looking somewhere else

The Scrum Master still does the same thing as before: help the team self-manage (in Spanish) and perform at a high level. Self-managing means the team decides how it works. High performance means it learns fast, delivers with quality and knows why it does what it does.

With AI, what changes is where to look. A team can't self-manage if it can't see how it's working, and AI changes the way people work without anyone deciding it. Each person uses it their own way, for different things and with different results, and none of that shows up on any board.

Three things the team needs to see

The Scrum Master's job with AI is to make the team aware of three things.

How it masters AI. Who uses it, for what and with what result. This isn't about surveillance. It's about the team knowing what works and what doesn't. When someone discovers a way of asking for something that saves an hour a day, that's team knowledge, not a private trick.

How it organizes itself around it. Who reviews what, when an agent comes in, what work is never given to it, what happens with what it generates. These are working agreements, just like the Definition of Done or the work-in-progress limit (in Spanish). If they aren't written down, they form on their own, and they usually form badly.

What problems it brings. The most common ones:

Dependency: the team stops knowing how to do things it used to know.
Reviews piling up in front of two or three people, as at GymApp.
Quality that only looks good: code or documents that are flawless on the surface but that nobody has checked.
The fatigue of verifying all day, which is more tiring than writing.
Knowledge concentrated in whoever is best at asking AI for things.
A gap between those who use it a lot and those who don't, which ends up as two speeds within the same team.

Diagram. What the Scrum Master helps the team see. You don't need to be an AI expert: you need to look where nobody is looking. How it masters AI: who uses it, for what and with what result; How it organizes itself around it: who reviews what, what is never given to it, what happens with what it generates; What problems it brings: dependency, piled-up reviews, apparent quality, verification fatigue. With what: Questions in the Sprint Retrospective, Flow data, Written working agreements, One-Sprint experiments.

You don't need to be an expert

The Scrum Master doesn't need to be an AI expert, just as they never needed to be the best programmer on the team. They need to understand how AI affects flow, quality and people, and ask the questions nobody asks because everyone is busy delivering.

Their tools are the usual ones, aimed at AI:

Questions in the Sprint Retrospective. The three above, one per Sprint if needed.
Flow data. How long work waits before review, how often it goes back, who reviews what. With that, the situation with Germán and Unai would have been visible a month earlier.
Written working agreements. One page, reviewed every few Sprints.
One-Sprint experiments. Try a change, measure it and decide whether it stays.

Outside the team too

There's a risk that comes from outside: the organization starting to measure people by how much they use AI. Number of queries, self-reported hours saved, percentage of generated code. These measures are easy to inflate and say nothing about value. The Scrum Master also helps senior management avoid falling into that, and chapter 14 offers alternatives.

At GymApp, the agreement that came out of that Sprint Retrospective fit in five lines: whoever generates code reviews their own first; reviews are shared among everyone; nobody reviews more than four hours a day; large changes are split before requesting review; and every two Sprints we check how it's going. Aitana was the first to ask to review other people's code.

In short

Self-managing with AI requires seeing how it's used. The Scrum Master makes three things visible: how the team masters AI, how it organizes itself around it and what problems it brings. They don't need to be an expert; they need to look where nobody is looking.

Try it this week

Take these three questions to your next Sprint Retrospective: How are we using AI? How are we organizing ourselves around it? What problems is it bringing us? Write the resulting agreement on one page and set the date when you'll review it.

If you're looking for ideas on using AI in the Sprint Retrospective itself without losing the team's judgment, you'll find them in AI in retrospectives, refinement and metrics (in Spanish).