AI Breaks the Agile Sweet Spot For Team Size

AI Breaks the Agile Sweet Spot For Team Size How big should your Agile taem be? Does Agentic AI change everything? Lets listen and explore how team sizes may EXPLODE! How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ https://www.agiledad.com/ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ https://www.instagram.com/agile_coach/ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ https://www.facebook.com/RealAgileDad/ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/ https://www.linkedin.com/in/leehenson/

• 0:15Speaker 00

  When doing agile software delivery, there's something called a sweet spot in terms of team size. Some people say, well, it's got to be less than 15. Others say teams of three or better. But we have to make a resolution. So others might say multiple teams of five would be better. But everyone agrees that a large team, like something bigger than 10, is usually not a good idea. When I've ever done larger teams, I've seen miscommunications. I've seen things fall through the cracks. So I've always tried to err towards smaller teams with clear boundaries when possible.

• 0:56Speaker 00

  So making sure that the teams are sized correctly isn't even near as important as making sure the work is broken down into bite-sized pieces that small groups of independently invested individuals could do together and deliver in a timely way. There's another way. A newer way that Agentic AI requires us to think differently about how software engineering goes about doing its thing. So there's a lot of factors that are coming into play here. On a recent project, I saw five people working together and everyone of them had an Agentic team.

• 1:33Speaker 00

  Which then comes to the question, is there a sweet spot in terms of an Agentic-supported team? On a human side, there certainly is, but with Agentic teams, I don't know that I think so. Because I think that their communication is going to be perfect no matter what the size is. But there are still massive advantages of breaking down the work into clear boundaries. This helps with context, size, it helps with testing, and it's generally just a good practice in general. But when it comes to agents, what is the correct number of agents with regard to AI? Right now, I have one agent team that's running with thirty-four different agents. And all in one sprint and a bunch of those running parallel to complete some work faster.

• 2:16Speaker 00

  That took four agents and created nineteen teams of them. And then it had a coordinator and a task viewer to check on statuses. This meant at any given time, there could be up to seventy-eight agents running during a sprint. But I guess someone could argue that this was nineteen teams. However, for one big architecture and design test, there could have been up to thirty agents. Plus the main Claude model all running through the completion of a test. What I'm trying to say is this gets confusing really quick. And I could see the future of having much bigger teams, both in terms of form and central dispatch working out. But also in terms of complexity of the team itself.

• 2:58Speaker 00

  What I'm saying is when you start including multiple agents and multiple individuals in there, it's gonna make things a lot different and typically a lot easier. In those thirty-four agents, there were industry experts, users, technical experts, test managers, test strategists. So all of these different people were behaving as agents. Now, I want to be careful because there is a different, there's a huge difference between having a group of agents and having a panel to talk to. Uh, so things like site reliability engineering or penetration testing or red teaming, user acceptance testing, these are things today that happen periodically at specific points in the development process.

• 3:40Speaker 00

  But there isn't a reason that these couldn't be actively incorporated into an agentic team. Indeed, in a complex project with lots of parts, there's a good reason to have agents from each, from each of the other teams who can act as a liaison or a broker. For instance, ensuring that APIs are called as defined and that any issues are automatically submitted to its correct team. Some people might scream, no, all just be one big great model that knows everything. But that's not right. That's wrong, actually. Not only do you now see with chat GPT, this sort of multi-agent behavior is normal.

• 4:18Speaker 00

  But there are basic reasons that having constrained context is a good idea. Having one agent that works on behalf of the customer and another that's optimizing for costs will inevitably lead to some contention or disagreement. And being explicit in how the negotiation should run is important. If you want a security reviewer who drops the ban hammer on libraries and code you never want, uh, you, you, in code, you never want a discussion within a single context. I'm willing to bet that before the end of the year, we'll all be running projects where there'll be multiple agentic teams that have over a hundred roles each and it'll be running 24/7, not only building new features, but constantly looking to review and improve and improve itself.

• 5:03Speaker 00

  And of course, now it isn't just one team that's working. We're now at swarms of teams that are writing in code and using Codex, which means that now, uh, we're trialing projects that have four separate teams all working together and each of those teams have large numbers of individual agents. I've got two teams doing development, one doing security, SRE, and generally being a pain in the backside to the development teams about leading practices and not creating security goals. And another team acting as a finance team complaining about using big models, uh, and how it's all formatted. I've not got to the stage yet where they've started throwing virtual chairs, but we're probably getting close at this point.

• 5:48Speaker 00

  At the moment, my solution to coordination is that the main agent does two things. Construct specific subsets of specific tasks and acts as the ultimate decision maker, including, uh, on escalations that come to me. The idea is to have a lazy dictator one that delegates all the work to subagents and only steps in when there's a genuine challenge. One other top tip from doing larger Gentic teams is your role and also where you allow agent teams to challenge each other. This, this is where documentation comes in two ways. Architecture review and architecture AI understands. So what I do is get AI to create its view in JSON

• 6:29Speaker 00

  or similar, then use that to create the human readable form. I then debate with the agents on the architecture, debate the design, but when it comes to the code, I leave the review of that to another agent, which is reviewing against AI readable definition. Does that mean there's a risk? Of course. How do I solve that risk? By having an agent that verifies the human readable form matches the AI form and what it came up with. When the AI goes wrong in the code, it's normally because there was an architectural design or design decision that went wrong. So I roll back to that point and then make the correction. This isn't necessarily vibe coding,

• 7:09Speaker 00

  it's being structured using a team and actually very high formalism, if you think about it.

• 7:17Speaker 00

  So, one of the things I want to make sure you understand is when you start a project with people, you always look to the skills that you need and you should do the same with AI. This is delegation to an AI team and making it easy for people to really understand how AI agentic integration works best and breaks that agile sweet spot. That's going to do it. I hope you enjoyed this article. If you have a topic you want us to discuss, learn more at agiledad.com. I'd love to hear from you. And as always, we encourage you to stay healthy, stay well and stay agile, my friends. Until next time, do take care. Bye now.