Powerful ways to build amazing teams (5 of 5)

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.

— 2016 Scrum Guide

Amazing teams are almost always small teams. The quote from the 2016 Scrum Guide makes it clear why team size is so important. There is a tremendous amount of research on this topic. Doing a Google search for “optimal team size” gave “about 333,000,000 results.” Is the Scrum answer of 3-9 people correct? Spending a bit of time combing through the top Google results shows responses of 3-5, 5-6, fewer than 5, and “it depends on the manager” (which is probably my personal favorite because it was in an article from a company that focuses on management!). The most common answer seems to be 5-6 people. When ignoring the most common answer, it is clear that smaller than 3 is too small and larger than 6 is too big, so we can almost certainly narrow it down to the 3-6 range. That’s a smaller range than 3-9!

Why is the optimal team size number so small? Once again, I will use recent videos from our #AgileDailyDose videos to give you some ideas. First, we are going to explore how team size affects overall communication within a team.

The number of communication pathways becomes very difficult to maintain on larger teams. That leads to breakdowns in overall communication, resulting in missed opportunities and lower overall effectiveness. There is a second issue caused by having large teams. On larger teams “social loafing” is possible. We have a video that touches on this topic in a roundabout way.

All of this information makes sense, but how does it help you in the real world when you have massive projects to work on and you need a lot of people to do the work? This is a make or break question for the success of agility in many companies. The traditional mindset about projects says big projects require lots of people on the team to get the work done. An agile mindset says big projects require a lot of breaking down of the project into smaller chunks so smaller teams can attack it successfully. I recognize this isn’t as easy as it seems, but teams of any size need to understand how to break work into small chunks that can be attacked in sprints/iterations. It is a key skill to success with agile.

The problem I see just as often is on the other end of the size spectrum. Many companies have lots of small projects that one or two developers work on until they are done and move to the next project. This situation allows more projects to be worked on simultaneously, which seems reasonable. However, in my experience, it is often better to combine those small teams into a larger team of 5-6 people. Why? Because it allows them to decide how to split that same work across the group. It will enable the team to self-manage how the work gets done, and that will almost always be more effective than externally managing how the work gets done by assigning small teams to the projects. The team may decide to create small subgroups to attack the various pieces of work in the way they had done it before, BUT they have the option not to do it that way. There may be something they can do differently and better when they are part of a larger team with more diverse skills.

In summary, if you want to have the best chance of having an amazing team you should:

1. Make teams that are the right size. No fewer than 3 people on a team, and no more than 6. Based on all the coaching I’ve done with teams over the years, my strong advice is to stay with 5-6 people on software teams.
2. Split up big teams. If your team is larger than 5-6 then consider splitting it into two groups. How difficult this will be, hinges on the cross-functionality of the team. Can two similar cross-functional teams be created from one team? If yes, then the split is easy. If no, then the team’s splitting needs to take into account how the skills on each team can work together to create value every sprint.
3. Combine small teams. Making one team of 5-6 people out of multiple smaller teams will give more options for working effectively. More choices lead to better overall throughput and effectiveness. Empowering teams to self-manage the way they do their work generally leads to benefits beyond just the overall throughput of the work. Morale goes up while turnover goes down. Increased morale leads to more gains in effectiveness. It turns into a very positive upward cycle!

My closing thought for today is this: Always ask, “How can I break the project down so teams of 5-6 people can attack it?” instead of “How many people do I need on a team to do this project?” Thinking about smaller chunks will always end up better. I don’t recall where I read this, maybe a recent Standish Group CHAOS Report, “In any large project, there are dozens of smaller projects dying to get out.” That’s good advice!

Use the comments to let me know your thoughts and experiences on this topic. Feel free to join our Agile Community to ask questions or learn more on this topic. We recently launched the Agile Community, so there isn’t a lot there yet, but it is free to join right now. I hope to see you there soon.

Read part 4 of this series here.