- About Environment, Products, Size, and People
- Consider Specialization First...
- ...And Generalization Second
- Widen People's Job Titles
- Cultivate Informal Leadership
- Watch Team Boundaries
- The Optimal Team Size Is 5 (Maybe)
- Functional Teams versus Cross-Functional Teams
- Two Design Principles
- Choose Your Organizational Style
- Turn Each Team into a Little Value Unit
- Move Stuff out to Separate Teams
- Move Stuff up to Separate Layers
- How Many Managers Does It Take to Change an Organization?
- Create a Hybrid Organization
- The Anarchy Is Dead, Long Live the Panarchy
- Have No Secrets
- Make Everything Visible
- Connect People
- Aim for Adaptability
- Summary
- Reflection and Action
This chapter is from the book
This chapter is from the book
This chapter is from the book
Watch Team Boundaries
In Chapter 12, "Communication on Structure," we saw that people tend to form groups. And when a group is small enough and has a shared purpose, we may call it a team. The concept of a team is very useful because it is a way of identifying a number of people as one entity. In psychology they call that chunking:
The idea of "chunking": a group of items is perceived as a single "chunk". The chunk's boundary is a little like a cell membrane or a national border. It establishes a separate identity for the cluster within. According to context, one may wish to ignore the chunk's internal structure or take it into account.6
In my last job, with many small projects and dozens of developers and testers in multiple locations, team formation was always a challenge. We changed our team formation approach more often than Madonna changes her image. But management of team boundaries is an important part of a manager's responsibilities, and it's important to try and get things right. After all, teams don't operate well when people don't know what the teams are and who they can rely on.
There are three aspects to boundary management: the way teams are structured, how individuals relate to teams, and how teams change over time. Self-selection of teams is possible in organizations in which people have a high level of "empowerment maturity" (see Chapter 7, "How to Empower Teams"). In such an organization you create a pool of potential team members, and then you leave team formation to the group. There might be projects that many people want to be on and projects that nobody wants to do. The great thing is that the group has to find its own rules for team selection, and as a manager you can just enjoy the heated discussions from the sideline. Self-selection of teams is something I have rarely seen in real businesses. It is worth considering, but you have to be sure that people understand how to form teams. One team of 30 developers and one team of 20 testers might not be a good option. Just consider the example of popular boy bands: Though they can have 30 members, in which case we tend to call them boy choirs, with such a size they rarely have the agility to keep up with trends in entertainment as much as a small team can. So to increase their chance of success, you might want to define and discuss some constraints on team formation first, concerning size, diversity, and other parameters.
How individuals relate to teams is another constraint you should take into account. Is a person allowed to be a member of more than one team? It is common for people not to perform as well as they could when they are asked to spread their loyalty across multiple teams. Mick Jagger never joined the Jackson Five to complement the Rolling Stones, and for good reasons. Such situations lead to task-switching, conflicts of interests, loss of commitment, and loss of motivation. Try to make sure that every person is dedicated to just one team. People cannot act as a team when they do not know what the team is. They may occasionally assist other teams and help out with other people's projects or perform some duets, but each person should have exactly one base team to return to.
Finally, the time span of a team is also an important issue. Research shows that teams perform much better when they are long-lived. Not just in software development [Larman, Vodde 2009:149/153] but also in other businesses, like airlines [Hackman 2002]. It is best for teams to exist for as long as possible because it takes time for communication paths and rules in a team to grow and pay off. It also takes time for them to learn, as a team, which information is important for them and which is not. Just think of this: What is the best pop group ever? And how long did they stay together? More than a few years? Yes, I thought so. When projects in your organization are by their nature short, try to keep people together in teams with longer life spans, where the same teams work on one project after another.