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:
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 projects. 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. Therefore, 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. The initial formation of the team will take them through the Tuckman cycle, and any change to the team that takes them through this cycle again will go faster as they know each other. A Stable Team grows in familiarity and consistency of 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. [3] A team can use its Velocity to measure its improvement in capacity for work. In Scrum we use Velocity as the key to predictability and the basis for establishing release plans. 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 being the same team members over a longer period of time. Cross-Functional Teams will benefit the most from long-term stability. 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 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. A Stable Team builds a collective identity that can be a foundation of a shared in Product Pride.
[1] Tuckman, Bruce W. “Developmental sequence in small groups.” Psychological Bulletin 63 (6): 384–399, 1965. [2] Brooks, F, The Mythical Man Month. Reading, MA. Addison Wesley, 1975 and 1995. [3] Diane Coutu, Why Teams Don't Work. Harvard Business Review, May 2009, https://hbr.org/2009/05/why-teams-dont-work.
Picture from: https://pixabay.com/en/dressage-tournament-equestrian-1547262 (under CC0 license). |