This post originated from an RSS feed registered with Agile Buzz
by Mark Levison.
Original Post: Choosing the Team Size in Scrum
Feed Title: Notes from a Tool User
Feed URL: http://feeds.feedburner.com/NotesFromAToolUser
Feed Description: Thoughts about photography, software development, reading, food, wine and the world around us.
Nearly every client I work with asks me this question at some point during consulting: How large should the Development Team be? How many doers (i.e. exclusive of ScrumMaster and Product Owner) per team? The Scrum Guide offers very limited guidance, suggesting 3-9, without giving reasons or context for those numbers. Clearly one generic answer can’t define optimal team size for everyone, but it’s worth knowing what factors should be reviewed, and what the tradeoffs are. Factors that take into consideration the Development Team’s needs are more important than an arbitrary number: A sufficiently broad set of skills to build their product – aka Cross Functional Team members dedicated to one and only one team Stable membership – i.e. team membership is consistent over a long period of time[1] Diversity of thought (and also background) – a sufficiently broad set of ideas, ethnicity, religion, gender, and life experience all spark creativity and diversity of thought. Once the Team is formed, the following factors seem as important as team size when predicting success: Psychological safety – i.e. the environment makes it safe for all team members to share ideas[2] Collective Intelligence of the Team – which is strongly correlated with average sensitivity of team members[3] Equal Communication – the most expressive team member is no more than twice as expressive as the quietest[4] Open Mindedness and Willingness to Learn[5] Team Size Numbers The earliest Scrum and XP books all suggest a team size number of 7+/-2, applying Miller’s number[6] – the number of integers you can hold in short term memory – to team size. I’m troubled by the applicability, as I can’t see why one’s ability to keep track of numbers should be correlated with team size. In addition, more recent research[7] has demonstrated that as the things you’re keeping track of become more complex, the number of items you can keep In short term memory drops to 4 or less. So we need more applicable sources. Many coaches cite historical examples going back to the Roman army and earlier, with small unit sizes of around 8 people. Others observe that Bonobos often split into groups of 6-7 to forage for a day. However, since neither example is about teams doing knowledge work, the relevance to Scrum is limited. Relationships between Team Members The official equation is N (N – 1) / 2. But what exactly does that mean? More importantly, how is it going to help us? Let’s take what resembles a math class problem, and turn it into something we can actually use in real life. Who knew? Basically, it tells us how many different relationships will exist within a team of a certain size. N = the number of people in the Team. So in the first example, for N=5 we have 10 relationships. 10 different combinations of team members interacting and developing a relationship with another team member. In the second example, n=7 so we have 21 relationships, and at n=9 we have 36 relationships. Each pair of people represents one relationship and that relationship is how they collaborate. High-performing teams need to have strong relationships between each of the team members. Why does this matter? Because each new person adds some individual productivity to the team, however each new person also increases the communications overhead. To increase a team from 5 to 7 people, we have slightly more than double the communication costs to maintain those relationships. To go from 7 to 9, we don’t quite double it, but the jump is still large. Just how expensive is it to maintain these relationships? Anecdotally, having studied team member interactions at clients’ sites, I can say that in teams of 7-8 people, upwards of 90 minutes, per person, each day is spent interacting with other team members[8]. This excludes pair programming time. Some of the interaction is talking about work, but just as much is spent socializing. Which is fine, and important, because it’s the combination of work and socializing that builds a team’s resilience and ability to handle challenges effectively. (See the water cooler section in “Five Steps Towards Creating High-Performance Teams“.) So relationships between team members, and the time investment they require, needs to be a factor that is considered when choosing team size, because it will influence productivity. A general rule of thumb suggests that people typically have from 3 to 5 hours of productive time at work each day. So as a Team gets larger, we either lose productivity or, more often, we start to withdraw socially rather than sacrifice productive time on interacting with our peers. We need strong relationships to become a high-performing team but, as group size grows, we start to avoid the interactions that build those relationships[9]. Research Backed Evidence The American Sociological Association published a study by Hackman JR, Vidmar NJ of the “Effects of size and task type on group performance and member reactions”[10] In this study they got people to complete a number of tasks – a mix of Production (writing), Discussion, and Problem-solving. The participants were placed in different groups sized from 2 to 7. After completing each task, volunteers were asked a number of questions, including two that this graph displays: “was your group too small?”, “was your group too large?”. As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The oft-cited number is 4.6. Key experimental conditions: the volunteers were undergraduate students (all men, sadly), the tasks had a cognitive load but were not programming, and the groups weren’t together long enough for a real sense of “team” to form. Nonetheless, it is an interesting data point. By the time Hackman wrote the book “Leading Teams” his rule of thumb for team size was 6.[11] Jennifer Mueller cited in “Is Your Team Too Big? Too Small? What’s the Right Number?”: if companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is […]
Previous Topic
