Stable Teams

… teams are formed and have worked together for some time.

✥      ✥      ✥

Stakeholders want to know when the product is estimated to be delivered, so we want to optimize our ability to predict.

In project management there is a tendency to confuse human beings with human resources. It leads to “resource management” where resources are defined as context-free working hours within a professional domain.

It often results in moving people from team to team when starting projects, or crisis to crisis during delivery, and leads to an unstable environment with added costs of:

  • administration to track of what people are working on;
  • reduced effeciency as teams need to integrate a new member and the new member needs to learn about the team;
  • exposure to Brook’s Law (‟adding manpower to a late software project makes it later”). [1]

When teams are formed from a resource pool, the resource utilization often leads to multi-tasking with people distributed across several teams and often on several products. Add in changing requirements and the instability becomes unbearable. So we need to fix something — the stable and unstable parts have to be balanced. For years the response has been to freeze the requirements so our ever-changing resources are able to deliver at a (hopefully) predictable time. Locking down the requirements of our products prevents us from learning and adapting to changes that are needed in the product to create the Greatest Value so this is not a good solution.


Keep teams stable and avoid shuffling people around between teams. Stable teams tend to get to know their capacity, which makes it possible for the business to have some predictability. Team members should be dedicated to a single team whenever possible.

✥      ✥      ✥

Members of Stable Teams get to know each other. The team members experience each other’s work style and learn how much work they can do together. A Stable Team grows in familiarity and consistency of meeting mutual expectations and starts developing a Community of Trust

Research has shown that fatigued NASA crews that had worked extensively together made about half as many mistakes as teams of rested pilots with no prior joint work experience. [2] This is because many of the factors that related to effective team work (such as shared mental models, cohesion, climate and psychological safety) can only be developed by teams that have consistently worked together. [3], [4]. People that work together for only a short period of time will probably not invest much energy in improving their work processes or social interactions with each other because in a couple of months (or less) they will be working with other people. On the other hand, if people understand that they will stay with the same colleagues for longer periods of time, they are more likely to invest energy in creating an enjoyable team environment and to improve their work processes.

A team can use its velocity to measure its improvement in capacity for work. Many Scrum Teams use velocity as a key to predictability. Velocity is currently the most proved praxis to improve the level of predictability. But what is often forgotten in the process of measuring a team’s velocity is that the only way that a team can get to know their velocity is by having the same team members over a longer period of time.

Cross-Functional Teams will benefit the most from long-term stability because there are more opportunities to share knowledge and experience. Specialized teams (e.g., that provide services for specialized skill sets or technologies) will also yield some benefits but have broader negative consequences for the organization, e.g. creating queues and requiring extra administrative overhead for work.

Stable Teams will create pressure on the pipeline of work. Work will now need to be structured to fit with the teams, rather than teams structured to fit with work — or crises. This will, in turn, highlight capability issues that occur within the organization that need to be addressed such as specialist skills that are needed across several teams.

Initially specialists may need to be focused with teams requiring these skills the most and then used to consult with other teams distributing their knowledge.

Start using Stable Teams by committing to keeping teams together, potentially using Self-Selecting Teams. The work will then need to be managed to fit this structure and to accommodate gaps in capability for the teams, and the organization will quickly emerge. These issues will need to be addressed to support the team.

The need to be “flexibleˮ where people are shifted from crisis to crisis will need to change to be about being flexible with work, and giving the organization a true understanding of capability and capacity leading to more accurate forecasting. Moving people between teams to be “flexibleˮ will quickly show the cost of this flexibility to the organization.

This pattern helps establish a Moderate Truck Number within the team.

A stable team that uses Estimation Points and lets the Pigs Estimate can get a realistic number for their velocity after a few Sprints; see Running Average Velocity.

Having a stable team allows an individual to master the work of the team. When there are multiple Development/Delivery Teams or multiple Scrum Teams using Birds of a Feather can support further mastery.

A Stable Team builds a collective identity that can be a foundation of a shared sense of both Product Pride and Team Pride.

[1] Brooks, F, The Mythical Man Month. Reading, MA. Addison Wesley, 1975 and 1995.

[2] Diane Coutu, Why Teams Don’t Work. Harvard Business Review, May 2009,

[3] Kozlowski, S. W. J. & Ilgen, D. R. (2006), Enhancing the Effectiveness of Work Groups and Teams, Psychological Science in the Public Interest, 7(3), pp. 77-124.

[4] Frazier, M. L., Fainshmidt, S., Klinger, R. L., Pezeshkan, A. and Vracheva, V. (2017), Psychological Safety: A Meta-Analytic Review and Extension. Personnel Psychology, 70, pp. 113–165. doi:10.1111/peps.12183.

Picture from: (under CC0 license).