97 Things Every Engineering Manager Should Know

Chapter 82. Team Stability Matters

Bill Horvath

If you’re running an engineering department, you may find yourself tempted to move people around between teams to address fluctuations in demand from customers and other business stakeholders. While we welcome changing requirements, even late in development, changing team composition to address them is a mistake.

Why?

Teams that stay together are better, in all kinds of measurable ways.

All else being equal, a team with stable membership will perform better over time. And there’s lots of empirical data to back this up: studies show team stability leads to high performance, predictable velocity, and outcome quality, just to name a few.

Team performance data only has meaning when the team membership doesn’t change.

Some software development teams measure their performance in terms of velocity; others use measures of code quality (such as bugs that escaped into production); still others use even simpler gauges, such as number of features delivered. But regardless of the data that’s collected, the more the team’s membership changes, the less meaningful the data becomes, because the unit of measurement has changed. A stable team’s work metrics have meaning because the team is stable.

There’s an interactive effect between team stability and product owner effectiveness.

In an Agile shop, the product owner constructs work items with the capabilities and past performance of the team in mind. Their knowledge of the team can have a profound ...