Practice: Whole Team
The Whole Team practice describes how a development team organizes itself to enable it to work effectively.

The single most important productivity factor is the people on the team and the way that they interact. The Whole Team practice describes strategies to increase overall productivity through streamlining the organization structure of the team and through streamlining collaboration within the team.

Main Description

Whole teams are self-organizing, cross-functional, fluid, and highly collaborative. 

Self-organization means that everyone on the team works together to determine the best way to perform the work required fulfilling the goals of the team. 

A whole team is cross-functional, containing people with the combined expertise to perform the work. This includes people with modeling skills, testing skills, management skills, and programming skills. It also includes stakeholders with the required domain knowledge. 

Fluidity refers to the idea that the team composition will vary over time. For example, at the beginning of the project, you may need someone with deep build experience to help organize the team's build strategy, but after this work is finished, this person leaves the team. Whole teams work in a highly collaborative manner, adopting the most effective communication techniques for their situations and striving to work together as closely as possible. It is through collaboration that people make each other better.

The goal of the Whole Team practice is to ensure that:

  • Everyone has a sense of belonging on the team, of being in it together. There should be no "outsiders," no "them" but only "us." When everyone is on the team, people avoid blaming others. Instead, there is a sense of collective ownership.
  • The team includes everyone required to build the system. Ideally, you want a self-contained team that has the skills and knowledge to get the job done. Realistically, this is not always possible at all points, and sometimes you will need to bring in outside experts for brief periods of time for specific goals. For example, you might need someone with experience at setting up the database at the beginning of the project or, in the middle of the project, someone with specific expertise in a certain aspect of the domain.
  • Everyone on the team contributes any way that they can. With a whole team approach there is a move away from specialists who focus on a specific category of work, such as analysis or database administration, towards generalizing specialists who may have that expertise but will also work outside of their specialty to help address the current need.   
  • The team is self-organizing. The people best-suited to plan and organize the work are the ones who do the work. This results in better estimates (particularly when people know that they'll be held to those estimates), more realistic schedules, and increased acceptance of the plan by the team.
  • The team maintains a sustainable pace.  Just as you don't sprint throughout a marathon, you can't go for weeks or months at a time working unrealistic levels of overtime. Tired people are not productive people.
  • Everyone works together closely. Not only is it safer, it is better to ask others for help when you need it. Another strategy for improving collaboration within the team is to have daily standup (scrum) meetings where you share your current status and explain any problems that you might have. Non-solo development practices, such as pair programming and modeling with others, are also common in the Whole Team approach.
How to read this practice

These are the three best ways to understand this practice:

  1. Familiarize yourself with its overall structure -- what it is in it and how it is organized.
  2. Read the main description to understand the thinking behind the practice.
  3. As appropriate, read these detailed guidelines: Maintain a Sustainable Pace, Daily Meetings, and Self-Organize Work Assignments.

For more instructions on how to adopt this practice, see How to Adopt the Whole Team Practice.

Additional Information

For more information on the Whole Team approach:

  • Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck and Cynthia Andres (Addison-Wesley Professional, 2004)

  • Generalizing Specialists by Scott W. Ambler