Stable Teams – Predictability Edition

Today I am addressing a key component to help teams succeed. Stable Teams.

Stable Teams Defined

I find that many people interpret those two words in many different ways. Here’s my definition.

A stable team is a team that stays together for ideally multiple releases or quarters. They have a few characteristics:

1. Individuals on the team only belong to one team.
2. The Team has one backlog.
3. The backlog is formed by a consistent entity.
4. The team stays together for multiple releases or quarters barring life events like illness, HR issues, etc.

Context

Stable teams can be applied at any level in an organization. Communities of practice, agile delivery teams, programs and portfolios all have a backlog.

Results

Plenty of studies have been done on the appropriate size of the team or how productive the teams can be if they are stable. Here are the key points:

1. Teams that stay together have a higher throughput.
2. Teams that stay together are more predictable.
3. Teams that stay together are happier.

The Softer Side

Our community is multi-dimensional in how agile is implemented.  I implement a structure first approach. Some implement a cultural approach so that they change the mindset of the organization. Still, others implement a practices approach where practices are taught and the teams are responsible for the outcome.

The reason I choose a structure approach is fairly straightforward. It’s not that I don’t care about culture and practices, but it’s out of respect for the longevity of the team, the culture, and the practices. I am intentionally creating a container that protects the team.  Protects them from what you might ask?

Culture

With a cultural approach, the worst thing I can do is teach accountability, self-organization, and how to be a generalist and have that subverted by team members being swapped off of teams. Teams that stay together figure out how to use each others unique strengths over time. They can be responsible for their own outcome and held accountable for it too. They can figure out how to best do the job at hand. If I pull someone out of the team, that kills accountability and their self-organization is blown to bits. Go ahead and try to hold them accountable. They will hate you for the long hours they pull trying to get the work done.  Respect the structure, and seek to change culture after protecting the container.

Practices

With a practices approach. The container for the team to take those practices and run with them isn’t created. The team may not be able to effectively create a working agreement or retrospect to come up with new ways to improve or implement the practice. They can attempt to self-organize, but it’s beyond their control much of the time.

Structure

So I turn to structure. If I structure the team, protect the team, and support them, they have the best chance for success. Not all teams will succeed. Some will improve slower than others. But they have a shot at changing their own culture. We can hold them accountable for their outcome because we have enabled them to do so. They can become generalists over time so when life events happen, the team can cover and prop up their team member. When attrition occurs, the team can absorb the change more readily.

Assuming that all made sense, what the heck is preventing stabilization of teams?

To list a few:

1.  Focus on individual utilization.

Some organizations focus on maximizing individual utilization, they even overbook. In large PMO organizations that focus on utilization of individuals, there is a sense that team members aren’t always working. This just isn’t accurate. While in the short term a team member or two can be underutilized, that is a maturity of practice issue that can be overcome. Utilization can indeed be improved. Not only that, but those people managing how much individuals are used across the organization can focus on something else because utilization is stable too. Knowing how much capital investment you have vs opex is much more valuable than scheduling someone’s percentage of work on a feature.

2. Side Projects

Kill them with fire.   Actually no… some side projects make great candidates for the backlog of the organization. Providing a single source of truth gives clarity to teams. Tech Debt can be prioritized along side of features. Teams need to be able to quantify the value. That’s generally easy to teach them. In the end, they will find that they get much more done. On another note, if the team is receiving work from the side. On the down low. That needs to stop. It’s an impediment to Team Stability. Find the source, figure out why it’s happening and eradicate it. That’s not simple, people have side projects for a reason. They are trying to solve a problem. Figure out if it’s an education issue, an alignment issue, or otherwise.

3. Dependencies on other teams

Dependencies are always a truth and cost of doing business in my opinion. There are some really cool things we can do to get rid of them, but in the meantime, we need to shoot for the most capable team with the fewest dependencies on other teams that we can. Capability modeling can be a life-raft to help with this. Structuring around your existing capabilities and enabling the teams by putting what they need to take care of those capabilities is critical to predictability. Dependencies still need to be managed, but not as much if we are smart about how we staff the team to enable them and figure out capability ownership by the team.

Stable Teams are a non-negotiable part of a predictable system.  Sure, there are outliers, but by and large, stable teams are one of the biggest ways you can help yourself and your organization.  If you can’t figure out how to do it or are not empowered, get help.  And remember, this isn’t just about Scrum teams, it’s about teams.