Stable Product Team

If your organization is not using stable product teams, they should be. A lot of organizations are still using an outdated balanced matrix structure. As an example, a company may have different departments or groups for each area of expertise. The project managers belong to one group, the developers belong to another, QA to another, and so on.

Before the fiscal year begins, the balanced matrix business conducts a prioritization process. They define what projects will take place for the year. Once projects are determined, a scramble takes place to form teams around projects. A battle will then ensue between management to staff the best people per project.

This model results in chaos and disorganization. It also results in creating teams that have little chemistry. Even worse, you end up with people assigned to many projects, resulting in switching costs. Some studies suggest that people can lose up to 40% of their productive time by shifting between tasks.

This must stop. Management shouldn’t move people around to different projects because a spreadsheet shows the people have ‘capacity’. It’s 2018, we now know that the highest performing teams are stable teams. The people on the stable teams should be 100% dedicated. What management should be concerned with is the throughput of the team, not resource usage. Efficiency does not always improve by increasing resource utilization. In fact, the opposite will happen if resources are over used.

The biggest reason for stable teams is related to team development. In 1965 Bruce Tuckman outlined four stages of group development, the ‘forming-storming-norming-performing’ model. Aside from having a catchy name, the model still holds true. It means that it takes time for teams to start performing well. This is a big part of the reason why it’s so valuable to have cross functional stable product teams.

Below are 5 huge reasons why your company should have cross functional stable product teams:

  1. With stable product teams, you no longer need to scramble to build teams around projects. All the chaos and competition around forming teams around projects goes away. No need to assign people to projects, instead, let product backlog items flow through stable teams.
  2. With stable product teams, work gets fed right into an already high performing team. This means you don’t have to deal with the forming-storming-norming phases of Tuckman’s model.
  3. Stable product teams improve quality. Quality improves because of the focus and attention the product receives. Team members also grow their domain knowledge and expertise. When team members are 100% dedicated, they won’t have to deal with switching costs.
  4. Work gets done faster and teams get better at predicting velocity. This reduces risk to the release schedules.
  5. Finally, stable product team members tend to enjoy their work. When team members sit together for a while, they get to know each other and they have fun. All the stable teams I’ve been a part of loved to joke around, bring in food, and come up with creative ways to have fun.

The stable product team model works well, perhaps best, using Agile Scrum. If your organization is not using Agile, stable product teams can still work well.

Whatever delivery process you use, let work flow through stable teams. Take advantage of teams that already have momentum, expertise and chemistry. Companies like Best Buy, Target and Pearson have long realized the benefits that stable teams have to offer.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.