Part II. The team: people and agents

Fewer people, not less judgement

Team size when there are agents

Do I have three people too many?

At the budget review, Ramón did the sum that many technology directors were doing that year. GymApp had six people and delivered twice as much as before it used agents. Wouldn't three be enough?

Olga didn't answer with an opinion. She proposed recording, for two Sprints, where the team's hours went. The result surprised Ramón. Writing code, which was what the agents had made cheaper, took up less than a fifth of the time. The rest went on reviewing what the agents generated, talking to members, deciding what went in and coordinating with other teams.

And there was something the sum didn't capture: the week Germán was on sick leave, nobody else knew how to review the changes to payments.

Ramón didn't remove anyone. He didn't leave the team as it was either.

Writing code no longer sets the size

The Scrum Guide (in Spanish) says a Scrum Team is typically ten people or fewer: small enough to move fast and large enough to complete significant work within a Sprint. For years, most teams have had between five and nine people, because you needed people to build.

With agents, building needs fewer people. But agents are not team members (chapter 5) and they don't reduce all the work equally. They greatly reduce the work of writing. They barely reduce the work of reviewing, discovering, deciding and coordinating, which are exactly the human clocks of chapter 12. The size of a team with agents is set by its capacity to review and decide, not its capacity to build.

What determines how much you can shrink

There is no single figure that works for everyone. There are six factors worth looking at before you decide:

1. Review capacity. How many changes the agents generate per week and how many hours of quality review the team has. If they generate more than can be reviewed, you have too many agents; you don't need people who approve faster.
2. The judgement required. Every risk the team takes to production needs someone who knows how to judge it: product, design, testing, security, data, the business. One person with agents covers more areas than before, but in each one someone has to know when what an agent proposes is wrong.
3. Continuity. Holidays, sick leave, someone who leaves. If only one person knows how to review payments, the team is only as big as that person.
4. Product risk. An app with payments, health data or minors needs more eyes than an internal tool.
5. Discovery. Talking to users, preparing tests and understanding what's happening takes people's hours, and agents shorten it very little (chapter 10).
6. The safety net. Specs, automated tests, a demanding Definition of Done and agents that check every night. The better the net, the less human review each change needs, and the more you can shrink.

With all of that, my starting point today for a product that is really used is a team of three to five people, each working with their own agents. Below three, continuity almost always fails or the second pair of eyes is missing.

Large teams, small teams

The dynamics change with size, and with agents they change more.

In a large team with agents, of seven to nine people, each person multiplies their changes and all of them touch the same product. Communication channels grow fast: with n people there are n × (n - 1) / 2 pairs that have to understand each other, 21 with seven people and 36 with nine.

It's the sum Fred Brooks made famous in The Mythical Man-Month (1975), and with agents each channel carries more changes. You get clashes between changes, the review queue in front of two or three people (chapter 4) and the temptation to split into subgroups that don't talk to each other. If a team grows that far, it's usually better to split it in two around the value stream (chapter 18).

In a small team with agents, of three to five people, there are fewer channels, from 3 to 10, and decisions are faster. The risk moves elsewhere: each person directs several agents and becomes the reviewer of everything they generate. If nobody watches for it, verification fatigue appears, along with quality that only looks good. In a small team, the working agreement from chapter 6 and the review limits are not optional.

And there's the extreme case, one person with agents. That's the case of our website: me, with three agents that work every day. It works for a small product, and it has two limits I know well. Every decision goes through one person, so my attention is the bottleneck.

And there's no second pair of eyes: the agents check a lot, but when we measured it, I was the one who found most of the defects (chapter 5). I wouldn't recommend it for a product that thousands of users depend on.

More agents is not a better team

Inside the team, something similar happens with the number of agents. Up to a point, more agents means more capacity. Beyond that point, the person directing them stops reviewing and starts approving. There are three signs that a team has more agents than it can handle:

• The review queue grows Sprint after Sprint.
• Rework after integration goes up.
• Someone says "I approved it, but I didn't read all of it".

When they appear, the solution is not to put more people on approving. It's to launch less work at once, make smaller changes or improve the safety net.

There's another consequence: in a team with agents, each person needs more skills. Product judgement, testing, design and security carry more weight. In Team Topologies (2019), Matthew Skelton and Manuel Pais call it cognitive load: a team can't own more product than it is able to understand. With agents, the team builds faster and that limit arrives sooner.

How to calculate it for your team

Before removing or adding anyone, measure two Sprints:

1. How many changes the agents generate per week and how much review each one needs.
2. How many hours the team has for quality review, without going over four a day per person.
3. How many hours go on discovering, deciding and coordinating.
4. Which risk areas only one person knows how to review.

If the review needed exceeds the review available, the problem isn't fixed by removing people. If there's spare review capacity and no area depends on a single person, the team can be smaller, or it can take on more product.

GymApp kept its six people, but with a different split: fewer hours writing and more reviewing and talking to members. Germán taught Aitana to review the changes to payments. And the next person GymTonic hired didn't go to GymApp: they went to the second team, the bookings and payments team (chapter 18).

In short

With agents you need fewer people to build, but not to review, discover and decide. Size is set by those capabilities, continuity and product risk. Three to five people is a good starting point for a real product; below three the second pair of eyes is missing, and more agents don't make up for less judgement.

Try it this week

For one Sprint, record where the team's hours go: writing, reviewing, discovering, deciding and coordinating. And list the areas that only one person knows how to review. The two together tell you whether your team can be smaller, and what would have to happen first.

To design the team and its agreements from scratch, you have the Team Canvas (in Spanish).

Chapters