- Feed Them Two Pizzas
- Favor Feature Teams
- Self-Organizing Doesn't Mean Randomly Assembled
- Put People on One Project
- Guidelines for Good Team Structure
- Onward
- Additional Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
Guidelines for Good Team Structure
This section presents a set of guidelines to consider in designing an appropriate team structure. Each guideline is presented in the form of a question to be asked of a current or proposed team. The questions are intended to be asked iteratively. Ask each question of a current or proposed team, changing the structure as appropriate based on the answer. As the structure changes, reask the questions until you can answer "yes" to each.
Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members?
People don't enjoy being on a team where they are not able to make use of their strengths or are constantly required to do things they are bad at. Good team members are willing to do whatever is necessary for the success of the project, but that doesn't relieve us from the goal of trying to find a team structure that accentuates the strengths of as many team members as possible.
Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)?
A well-conceived team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If the organization is not attempting too many concurrent projects, yet more than 10–20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
Does the structure maximize the amount of time that teams will remain together?
If other factors are equal, you should favor a design that allows team membership to persist over a longer period. It takes time for individuals to learn to work well together. Amortize the cost of that learning over a longer period by trying to leave teams together as long as possible, ideally even finding a team structure that can outlast the current project.
Are component teams used only in limited and easily justifiable cases?
Most teams should be created around the end-to-end delivery of working features. In some cases, it is acceptable to have a component team developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
Will you be able to feed most teams with two pizzas?
Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have between five to nine members.
Does the structure minimize the number of communication paths between teams?
A poor team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams. Some interteam coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, as I've seen, then the communication overhead is too high.
Does the structure encourage teams to communicate who wouldn't otherwise do so?
Some teams will just naturally communicate with each other. An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord. In fact, one valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person's time between those two teams is easily justified.
Does the design support a clear understanding of accountability?
A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities.
Did team members have input into the design of the team?
During the early stages of your transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint. Similarly, some individuals may be initially too resistant to Scrum to contribute to team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial team structure. While doing so, however, they should remember that this is a responsibility that will eventually need to be turned over to the team as a whole.