I think it is not possible to implement a sustainable Agile practice thinking only in terms of teams of 5-10 people, especially a sustainable Agile practice in large companies. I have nothing against small teams – quite the contrary! But there are distinct advantages to including our teams in a larger organism that supports and sustains the Agile teams.
We need to think in terms of Tribes.
I have been familiar with the ideas around Tribe for a very long time, and have been part of creating Tribe on many occasions. Dedicating people to a Tribe and allowing them to move around to different teams within the Tribe provides distinct advantages without the thrashing and loss of velocity that occurs when we move people between teams that are not part of a Tribe.
What is a Tribe? A Tribe is a group of around 100 people who are dedicated and co-located, and who have a commonality of interests. A Tribe develops its own language, culture, and rituals distinct from other Tribes. A Tribe contains people of many ages and experience levels, with the most knowledgeable people acting as “elders” who guide and mentor those with less experience. People in the Tribe work together, play together, and eat together.
Why about 100 people? It is large enough to get a varied pool of talent and skills, and small enough that everyone can get to know everyone else. These are very important elements to creating a stable Tribe.
Doing paired development is the best way I know of to help a Tribe form. Not just paired programming, but pair all the tasks of the Tribe. As people move around pairing with a variety of other people within the Tribe, we get terrific knowledge sharing, and people get to know each other and how to work together. It is this broad knowledge sharing and knowing how to work together that lets us have fluid teams without the disruption we usually see when people are moved on and off a team.
Advantages to a Tribe are many:
- Allows Tribal members the opportunity to broaden and deepen their experience by working on a variety of teams with a variety of people
- Allows for load balancing of work among a number of teams without the disruption that typically occurs when people move between teams
- Knowledge is spread among many people so you do not risk losing the one person who knows X
- It is easy to bring new people into the Tribe and get them quickly up-to-speed
- If your company has pools of specialists who are stretched thin trying to help so many teams, a Tribe of 100 may be large enough that one specialist can have enough work to be dedicated to the Tribe so the Tribe does not have to wait for their time.
Many companies do form Tribes, though they probably do not call it that. They dedicate a group of analysts, testers, developers, technical writers, etc. to one product line, and within that product group, individual teams work on specific work packages. It works quite well, and fits nicely with the Agile focus on Products rather than Projects.
We can do more to promote the idea of Tribe as a purposeful construct, deliberately forming a Tribe by co-locating people with many different skills and experience levels, dedicating them to the Tribe, pairing all tasks to share professional knowledge and get to know how to work together, and encouraging the most knowledgeable people to mentor those less skilled.