Design for stable teams

Introducing the concept of stable delivery teams in an organization can be hard. Especially if the concept is new to both employees and management. Creating the team structure and getting buy-in for the change might be challenging. However, if there is something that the past 20+ years has proven, then it’s that modern leadership focuses on empowering stable teams over maximizing the utilization of individual employees.

 What happens when you do not have stable teams – and employees are allocated to several projects and other day-to-day work:

• Employees have to work on several high priority projects and can only give each project few hours per week
• Employees end up having to prioritize each individual project against each other on a day-to-day basis
• Employees may face conflicts in project priorities, e.g. all project are important
• Employees may find themselves in a situation where they have promised something to a given project and local management may have prioritized different work
• Employees work with several context switches per day due to different objectives for different projects
• Employees find themselves participating in many status meetings, e.g. one for each project, leaving few hours available for flow work

From a project perspective, the issue of employees having low focus on each project will result in a low completion rate of work to be done. This can be observed several places:

• Burn down chart: The curve is either stagnating or descending very slowly due to low completion rate of work items
• Task board or Kanban board: Activities are stale and stay in same status for a longer period due to context switches and lack of priority
• Project backlogs or plans: Forecasts based on expected velocity will drift due to a decreasing velocity and completion rate

Introducing an organisation based on stable teams could produce the following behavior that will accelerate end-to-end time from idea to execution:

• Employees may be allocated to projects, but they bring work back to their product backlog for prioritization
• A product backlog must be managed to coordinate and prioritized between interfacing projects, non-project work, support, etc.
• Employees should not consider day-to-day prioritization since this is handled at product backlog level and thusly can work focused
• Projects and stakeholders interface at product backlog level on prioritization and coordination
• Transparency and visualization of backlog to assert progress and impediments to requesting projects for them to adopt and/or react to changes
• Employees can focus on the work selected for the backlog and not focus on participating in various status meetings with interfacing projects
• Each employee is associated to 1 (and only 1) team
• Team plans in 2-4 weeks iteration

 Our perspective is clear; The benefits from stable teams by far outweigh the perceived flexibility of moving people to tasks. This is why we always recommend continuously pushing back, when proposals are made for moving people to tasks.

On a final note we also strongly recommend you look into Team Topologies and from Project to Product for more inspiration on how to setup your company for success.