What is the Right Team Size?

Team in front of Computer Code, generated by DALL-E 2

 What is the right size for a team? Can it be too big or too small? I worked with a team once that had 3 developers. They spent most their time mob programming in front of a 42 inch monitor, taking turns at the keyboard. They didn't need to do traditional stand-ups because they were swarming around one thing at a time. The Scrum Master kept an eye open for impediments, but otherwise was focused on the next thing that would improve the team's productivity. 

I also worked with a team of 15. My first thought was that was too big, but as I watched the team work, I saw that wasn't the case. The team was doing data-science kind of work. They needed people who could write SQL to pull data from legacy systems and put it in data lakes and people who could take that data and package it in a report with Tableau. For this team, having all the skills on one team meant they didn't have dependencies with other teams. 

An often cited paper by George Miller states the magic number at 7 +/- 2 people (sometimes referred to as Miller's Law). The 2-pizza rule says a team should be small enough to feed with 2 pizzas. Robin Dunbar's research suggests 15 is the upper limit of the number of people we can deeply trust. 

There are other considerations beyond just the number of people. As I pointed out in my last post, dependencies slow teams down. My 15 person team was big, but still effective at delivering because they didn't have dependencies on other teams. 

This larger team also had true cross-functional skills. My smaller team was effective because they were developing in a narrow field and didn't need a broad range of skills. However, if they found they were having dependencies on another team because of a missing skill, enlarging the team to include this skill could be a smart move. 

In the book Team Topologies, Matthew Skelton and Manuel Pais talk about cognitive overload. Teams can only handle a limited number of different areas of focus. If the team is asked to do too many different types of work, the effectiveness of the team will suffer. Just like individuals can't multi-task effectively, neither can teams. So when deciding on the team composition, this should also be taken into account. My 15 person team was probably suffering from cognitive overload, but I wasn't looking for that at the time. 

Too often I see teams put together without much thought. Worse yet is when people are partially allocated to more than one team. I think regardless of what framework or methodology you are using, you need to start off with deliberate thought about how to set up teams. I would recommend the book Team Topologies for guidance on this topic. 

Even the Best Chefs can't make a bad recipe taste good; why someone else's Agile Transformation recipe may not work for you

 I've been reflecting on some of the agile transformations I've been involved in over the past few years. In some cases, I see some real progress made. Other times it seems like just re-arranging the deck chairs on the Titanic. An organization follows some recipe, but they don't get the results. Why?

I was working with a large financial institution. They had adopted the "Spotify Model" (yes I know, it's not a real thing) and after that they adopted another scaling framework. I came in and started looking at what was going on and discovered they had a huge challenge with dependencies across teams and products. They failed to realize how much the dependencies on other teams was slowing any one team down.

I took some on-line training recently, a course called Agile Physics - the Math of Flow led by Troy Magennis. In it, he talks about Amdahl's law, which was developed in the late 60s to explain parallel processing. The bottom line is that there is always going to be a limit on how much additional output you can get by adding more processing power. Troy points out the law applies to people and teams as well as CPUs.

One source of the limit is how much can be done in parallel, or said another way, how much dependency there is between teams. So two processors (teams) in parallel with no dependencies can produce twice the output of one. However, as less of the work can be done in parallel (ie, dependencies), the output drops. Using the formula Amdahl developed, if you have 4 teams and 80% parallelization, your output is 2.5 (not 4). If you want to learn more, take the course...it's free and some really interesting ideas.

Back to my client with all the dependencies. What could have helped them? Maybe if before they applied the recipe for scaling, they took some time to look at how their teams were set up and came up with a better approach there, that is, one that reduced/eliminated dependencies. More on this idea in a future blog post.