3 Aspects of Team Boundaries
3 Aspects of Team Boundaries
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
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.
– Gödel, Escher, Bach (Douglas Hofstadter)
In my own organization, with many small projects and dozens of developers and testers in multiple locations, team formation has always been a challenge. We’ve changed our team formation approach more often than Madonna changed 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 constructed;
- how individuals relate to teams;
- and how teams change over time.
Self-selection of teams is possible in organizations where people have a high level of “empowerment maturity”. In such an organization you create a pool of potential team members, and then you leave team formation to the group itself. 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 a small team can. So in order 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 and 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. 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 and keep people together in teams with longer life spans, where the same teams work on one project after another.
(image by Chris Willis)
This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.
Published at DZone with permission of Jurgen Appelo . See the original article here.
Opinions expressed by DZone contributors are their own.