A stable team is one in which team membership doesn’t change often and, instead, is consistent over time.
Why should we care? Isn’t Scrum like basketball where you can change the players on the court anytime there is an interruption? Let’s find out…
High-performing teams —or teams that gets stuff done with insanely high quality— is the goal of many who arrive in Scrum expecting to get amazing performance out of their system. But building a high-performing team from scratch takes time. The popular picture of Tuckman’s Model of Team Formation shows a team going through the stages of Forming -> Storming -> Norming -> Performing. (Caveat:the picture exists to simplify understanding. The dynamics of a real team will be messier than shown).
It’s easy to form a team and then speed right through the storming stage. Storming is characterized by conflict, as people sort out roles and relationships.
Norming and performing are considerably more difficult in unstable teams, and they occur repeatedly. Every time there is a change in team membership, there is a good chance of returning to storming because of the new interpersonal dynamics. I warn organizations that, when you need to make change, there is a risk that the change will not only send them back to storming, but it might also be damaging enough that the team doesn’t recover at all. How often to you want to roll that die?
Most of the work in academic literature deals with familiarity, not stability. Roughly speaking this means “we’ve worked together enough in the past to understand each other as individuals”. Whether you call it familiarity or stability, the premise is the same – people need time to learn how to understand each other and communicate effectively, the key is familiarity is weaker than stability.
How Stable Teams Affect Quality
When team members are familiar with each other, you see the benefits in the level of quality of work from that team. Take, for example, surgery. I hope most Scrum teams are doing work that is less exciting than surgical procedures, however surgery (for obvious reasons) is well-studied, so it gives us a good source of data.
There’s an orthopedic surgeon who does more than 500 knee surgeries a year, which is 2.5 times as many as anyone else at his hospital. He has implemented dozens of techniques to improve his surgeries. Instead of working with a changing cast of nurses and anesthesiologists, he has two dedicated teams and “he says that few of the methods he has pioneered would be practical if not for the easy familiarity of working with the same people every day.”[1]
Killing the patient is the ultimate error. Not killing them is a fairly low bar of quality success. Nonetheless, cardiac surgeons who worked across multiple hospitals but maintained stable teams had a lower rate of mortality, even with more surgeries performed. The study’s authors attributed that level of quality work in part to team familiarity.[2]
Aviation and aeronautics are also widely-studied fields with data that supports the importance of stable teams. “73 percent of the accidents for which information was available occurred on the first day the captain and first officer had flown together.”[3]
“A NASA study found that fatigued crews who had a history of working together made about half as many errors as crews composed of rested pilots who had not flown together before.”[4]
And to bring it back down to earth, a study of the Wipro software outsourcing firm found that increased familiarity reduced defects by 19%.[5]
How Stable Teams Affect Predictability
There isn’t any data for predictability of surgeons, which I think might be a good thing.
The Wipro study showed “deviations from budget decreased by 30%”. Let’s ignore the cringing focus on budget, when it should be on building the right product, as it does show that familiarity aids predictability.
In the “Impact of Agile Quantified”[6], Larry Maccherone showed that stable teams had 40% better predictability.
How Stable Teams Affect Throughput
We shouldn’t really be chasing “more features produced faster” as an outcome. Instead, we should focus on better value and outcomes. That said, I’ve never met anyone who didn’t want to see their team get more stuff done.
At Wipro, “We also found that familiarity was a better predictor of performance than the individual experience of team members or project managers”. More impressive data from “The Impact of Agile Quantified” showed that stable teams are 60% more productive. In many organizations, this is the lever that allows us to unlock the stable teams.
Just remember to focus on outcomes over output.
Why Stable Teams Work
- Team Mind (or Shared Mental Model). We know what other people know, and who can be relied on to get certain things done.
- Coordination and better collaboration are easier when we know each other well.
- Flexibility. Team Mind and ability to collaborate allow the team to adapt more easily when bigger product changes happen.
- Continuous Improvement requires the same cast of characters, so we don’t keep on rehashing things we learned months ago.
- Team Mind and Continuous Learning Process deepen the team’s knowledge of their problem domain, technical skills and knowledge of their code base.
Why Stable Teams Can Be Difficult
So if stable teams are a good thing, what makes it hard to achieve them?
- Matrix organization
When team members report to different managers, each manager will have different agendas/needs. As a result, team members may be moved, even when a more elegant solution might work and allow them to remain in the team. - Reliance on outside experts
When a team relies on outside help for specialized skills, they often try to include the “expert” in the team. That rarely works well. A better solution is to use them as a consultant/coach but not have them do the hands-on work. Instead, they coach team members how to do the work in question, maintaining the team dynamic and improving skills at the same time. - Organizational Politics
Ugh. Enough said.
When Stable Teams Aren’t Desirable
There some cases where the problem complexity (see: Complexity and the Cynefin Framework) is such that team member skills are changing rapidly, stable teams might not be a priority. In this case, we might sacrifice performance, reduction in errors, etc, to have a fighting chance of tackling the problem in the first place. Problems of this nature are incredibly rare. Please contact me if you think you’ve found one, I want to check in.
Reteaming
Sometimes the product that is being worked on is no longer as important, and the organization needs to reduce costs and move team members around. Redgate Software has pioneered a technique to balance stability with adapting to changing market conditions[7], where the organization annually makes strategic decisions around where to focus. Once the decisions are made, team members can self-select which team they want to move to.
Prefer stable team membership over a cast of changing characters. When you don’t have a choice, examine the circumstances and make sure the organization understands what it is giving up.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Leave a Reply