Hi, everyone. This is Kumar Danatran with agile Meridian, and this is our 30 eighth episode of the Agil shorts. And A bunch of a bunch of Agil shorts. That is. That is a lot of Azil shorts. Yeah. Uh, you have lots to pick from. So today, we're gonna be talking about team size. What is the ideal team size? And, you know, for me, it's not really an agile thing or It's just it's a thing. You know, small teams to me are more efficient, more productive. And in my experience, uh, helping our clients team seemed to just grow and grow and grow. And, um, you know, we've got teams of 15, 18, 20 people, And, um, they're trying to be agile. They're trying to be nimble. They're trying to deliver, and it's just not working. Um, so I'll I'll turn it I'll turn it to my colleagues, uh, Jolly and Chris, and we can talk about this. Maybe a little bit. What what do you think, uh, jolly in terms of small teams versus large teams? Yeah. 1 of the big things, whether you are, uh, in in the office or remote, uh, is, is that the more the number of people like, we have way less tomorrow. I mean, you and I started off this, um, uh, agile Meridian, it was just you and me. And now we have more people, and it takes more effort to communicate with each other, and and to make sure that we can collaborate with each other. Not all times work for everybody. Uh, we have to have all 4 people on a call to make sure that all the decisions Uh, at least everyone knows about it. Otherwise, you know, if someone might miss out. So the more the number of people in our current pandemic to enroll, the more difficult it is to communicate and collaborate with each other. And, uh, that's a crazy math. I am sure 1 of you guys know how that formula works. But, uh, every time it goes about, like, I think the number the magic number is, like, maybe 5 to 6. After that, the number of communication paths you need just to make sure that everyone is informed, just informed skyrockets. Right? It's an exponential run, almost. Uh, when you cross a standard sample, how many number of communication paths they are. So small genes I have seen, uh, there was a Harvard business uh, study, which came out, uh, review study, HPR review, which said 4 to 6 was the ideal 1, even though scrum used to say, uh, less than 10 now. Uh, they said 4 to 6, which sounds about right. Uh, and and maybe that didn't include, like, a scrum when the product owner, but still, like, 4 to 6 is, uh, maybe 2 to 3 or 2 to 3 devs and, uh, 2 to 3 key way, uh, people. Right? That kind of makes sense. And, logically, that, uh, sounds like the right number. Uh, I have worked with only 1 team in that size. And I can guarantee you that was a great experience for them. And for me as a coach who was working with them to kind of uh cut help them through that path of continuous improvement. Mhmm. Chris, I I don't know whether you have similar experience with Yeah. I do. It's, you know, you think about large teams and you think about how do you how do you pivot? Right? I mean, at the if you've gotta change directions and you've gotta turn you've got 15 people on a team and, hey, we're now gonna go do this. You gotta get everybody on board. And there's a lot more. You you mentioned that commute that formula, right, that communications formula. Um, you know, when you think about it, you go from, you know, when you go from 3 people, right, where you're talking about a total of 6 communication pass, to 9 people. That's 72. I mean, that's huge. Right? I mean, it's just huge. It's more than It's almost it's exponential, almost. Um, and it it it causes problems for teams. And my experience is the smaller the team, the better they do. And the better the easier they are to pivot, the quicker they get up to speed, you know, um, the more the more they become like a family. Yeah. The formula. I think that's the formula. I I stick it down there in the, uh, uh, the messages. It's n being the number of people on the team. Times the number of people on a team minus 1. That's the number of communication paths. And so you can see this is this is an exponential formula. Right? If you have 6 people, that means you have 36, 35 communication paths. Still doable. But what happens when you have 15? Right? Uh, that is an exponential number of communication paths because there's so many more people that you have to sort of keep together and keep aligned. And that's what we're seeing with our clients. And the ceremonies, the actual ceremonies, the stand ups, the planings, the you know, the demo, the retro, and all that, it starts to break down when you have large teams because not everyone can go. The stand ups become Uh, imagine standing up for an hour. Right? Because your team's so large. And you do that every day. No wonder people are like, oh, Angel doesn't work. Teams are so big. It just doesn't scale. 1 of 1 of the other things I I think is a benefit is with small teams is that when you have a small team, they can mature faster because they learn faster. You know, the, again, the communication path being, um, limited to that team, you know, a small team, 4 to 6 people, that they're gonna learn quickly. They're gonna become mature a lot faster than if it was a large team. Right? So small teams, we think that they they fail faster. They learn from those mistakes. They mature faster. I've seen this. Do they really fail faster? Or is it they recognize it that they're failing faster? Right? I mean, I We talked about this before we we jumped on here, and and I'm I don't know. What do you guys think? Do you is it they fail faster or that we recognize it? Yeah. Uh, the reason, kind of the reason is what we mentioned before, uh, because of the number of communication paths, the feedback is faster. Right? And when the feedback gets faster, it leads to what you said, Chris, which is you recognize and agree uh, and the defense comes to an agreement on what really happened. And, uh, decisions to pivot or to continue becomes easier to make because of the faster feedback loop. Yeah. That's a good point. I I think it's a recognition of it. True. Yeah. For sure. And with a small team, you know, um, uh, they they're they're definitely more nimble, right, because of that. Another thing III feel is that, um, small teams, um, they're just more transparent. Right? Uh, just from this, the this because they're small and because they're able to pivot and move faster, Uh, what happened? Where did my people go? Are you all still there? There you are. You all disappear from my screen. I don't know if that happened for you on your end. It it was me. I was I thought it was just gonna be my display. Sorry. Uh, okay. Gotcha. Yeah. So we, you know, I think that there's greater transparency with the small team. Right? You can kinda see there. Their struggles, their successes, their, um, and what they deliver faster, uh, and there's more transparency that way. What do you think, Jolly? Uh, yeah. And and 1 of the prime examples of that Kumar is what you mentioned earlier about the stand up. Right? So let's say 15 people and the standard takes 45 minutes or an hour. 90 percent of them are gonna tune out. After the after the first 5. Right? So it's not like the transparency is not there. Right? I mean, if you dictate the transparency, if you look for it, the transparency might be there. But the fact that people, don't have that much concentration. Just as an example of a stand up, is -- Right. -- is indicative of why the transparency goes away, not because it is a, it is an explicit action that anybody took to hide things. But the fact that it gets lost in the detail. Right? And then that's that is the example of the stand up. The same thing probably happens in sprint planning. Uh, yeah. I'm I'm worried about what I do. I don't wanna sit in this 3 hour sprint planning where they're discussing other people's work. Why don't even really work with that closely. Right? So that is where the things get lost. And the additional complexity of dependencies between all of these. It's almost like 2 different teams now. Right? There are so many people. There are dependencies between them and and, uh, which adds another level of complexity to the the workings of the team, um, makes it really a bit tough. I I totally agree. You know, and 1 of the teams that I'm that I'm, uh, well, any large team in my experience, um, it's almost like the teams themselves sort of morph into these little subteams, you know, almost like these little clicks, right, where a certain people tend to work together. Other certain people tend to work together. And they tune out, you know, when these people are talking, it's not really relevant to them because We can't handle it. The number of communication channels that they have to keep in keep track of. And so, certainly, smaller teams are more transparent because They all inherently know what they're doing. The stand ups are efficient. It's transparent to each other. It's transparent to their stakeholders and so on. So, uh, uh, much better. And then the finally, you know, I I think, um, oh, I we didn't really ask Chris for his opinion. What do you think about this? Yeah. I agree. I mean, just by the nature, right? There's there's less people. So you have more time to share it's easier to keep track of, you know, um, most people only have when you think about it, most people have AAA nucleus of about 3 or 4 really close people to them, right, in terms of outside their family. And and that's kind of what we're talking about with a team. Talking about a small group of people to go do the work and the bigger the group, the harder it is to communicate, the harder it is to see what's going on, the harder it is to be transparent because you don't have as much time. Um, yeah, I agree. Transparancies is definitely improved with the smaller team. So what what is what are some tips that we might have to, uh, for viewers? You know, if they if they are part of a large team, agile or not, What would you say is a path for them to get to smaller teams? I'm gonna punt that 1 to Jolly while I think. Yeah. I mean, 1 1 way of looking at it is obviously, there are different techniques that you can use to split teams itself. Uh, 1 of the 1 of the popular things among advocates of smaller teams and communicative teams is that they sell form. Right? It's not like the leaders are telling them, hey, oh, you, you, and you work together and and go from a team. So self forming teams based on the skill sets that they need to make work, uh, to get work done, uh, might be a good option. Also think something to consider is that these teams an agile kind of, uh, the principles say that we, oh, no. We keep those teams together forever. Right? And that is the most efficient thing. If this is indeed a bigger team that got into smaller groups to make sure that they work together really well. Maybe maybe they they changed that based on how what the work is. Right? The work demands change over a period of time. Doesn't change every month. But over a year, it might change. In which case, allow them to self form again so that they form the best groups possible that enable them to work forward as fast as possible. So self governance really helps. I think, uh, I hope that's 1 of my big things lately. Uh it's difficult to find management support, but I think it really works. You know, that's a really good point. Sorry, Kumar. That's a really good point there, Jolly about. Self organizing. Um, I hadn't thought about it that way, but they may already be self formed. They may already be working in there. We may call that you may call them clicks or whatever. Right? But they're they're all probably already there. I hadn't thought about that. Yeah. That's that's that's really what I see too is that they're kind of already forming that way. Uh, however, uh, management, leadership, whatever, imposes this artificial team structure because they're all sort of working in the same area. Right? Um, where I've seen to your point, the the most, uh, productive and engaged teams are where you allow them to your point to determine who they work with, right, based on the work. There was 1 company I worked with for for a long, a while a while ago, And they took a sort of an open space approach, open space agile approach to their teams, right, where they laid the workout they got all their people there, right, all of their developers and QAs and, uh, BAAs and product owners and and things like that. And they said, okay. Figure out where you wanna work. What do you wanna work on? Who do you wanna work with? And, you know, by the end of the day, they had formed into small teams, you know, 6 or so people. And we did give them some some guidance, sort sort of some, you know, constraints. You know, your team needs to be uh, obviously self organized. You need to have these types of skills, skills, whatever skills you need to do the work, and you can't be over a certain up size. Right? And and they went and did it, like, you know, and of course it didn't take the whole day to do that. That self organizing happened fairly quickly, but then it was part of the, you know, the of the day was team building and all that stuff. But it was it was a really great experience, you know, to be able to get to smaller teams you know, that maintain a familial feel. Right? They get to know each other. They understand each other's motivations. They understand the work. And then kind of allowing them the opportunity to go work on another team for a while because, um, they wanna expand their skills or They wanna work with somebody somebody else. Right? Right. Yeah. And and that's what these people did in this company is they every quarter or so, they would They wouldn't shuffle the whole deck, but they would give opportunities for people to go work somewhere else. I I think that by itself is a is an agile shot Yeah. It probably is. Yeah. That's the, uh, that's a dream. I mean, that that's the ideal. I mean, we people talk about doing that, but I have yet to see anybody really willing to go do that. And and from a leadership standpoint, right? I mean, it's very they may perceive it to be very risky. So Yeah. It doesn't happen often. Um, any and I don't know. I've been consulting coaching for a long time, and I only have 122 instances where this has happened. And interestingly, 1 was you know, um, a publicly traded company, fairly small. 1 was, um, a government organization for of all things. Right? And, um, they had large teams, and they decided just to sort of you know, have this large group of people. And every quarter, they would sort of do a release planning where the group this large group of people about to people or so, they would self organize them to small pods to do the work. And the next quarter, they would do it again, and the organization could be different, right, because they would, again, organize around the work. So every quarter was a slightly different configuration of small pods you know, 3 to 5 people per pawn that was doing the work. And this was a government agency. Uh, I was I was blown away at the time, and I haven't seen it really anywhere else. Yeah. And and and that there are many more benefits to it up than the the communication path and collaboration and all of that. Right? I mean, there is the, there is a learning path. There is a co ownership. Uh, absolutely. I mean, it's probably worth doing, uh, uh, short by itself or not. Yeah. And and I and I when I when you guys were talking, I was thinking, maybe my formula is wrong. It seems wrong, and and I found, uh, a ref reference on the web that this is the right formula. N times n minus 1, over 2. Still, you know, it's still exponential. Yeah. And so, uh, with that, any any closing thoughts before we, uh, before we end this short, We we are interested in knowing what you have out there, uh, uh, what you have tried. And please let us know in your in the in the comments. Uh, it will be interesting to see how it has worked out for you. Uh, but small all big, uh, the pros and the cons of, uh, either 1 of them. Yeah. Absolutely. Yeah. Please do. Please do let us know. Uh, well, thanks everyone. Thanks, Chris. Thanks, Jolly, for, uh, for this actual short. Uh, and we will see you all in a couple of weeks about
