Developing Stable Teams, and Dealing with Dysfunctions
Having stable teams that exist over projects can be beneficial for agile software development. With such teams, work is organized and fed to existing teams, in stead of defining new teams at the start of each project and dismantling them when the project finishes. But what can you do if a stable team doesn’t function as expected? Several authors blogged about establishing and nurturing stable teams, and about dealing with team dysfunctions.
In the blog post we want a stable team, Joe Little explains why he thinks that it is important to have stable teams:
(…) coming up with a great product requires something special. And I believe the ‘special thing’ these days is far more likely to come out of a good Team. So, from a business management viewpoint (and it is the managers we most need to convince about this) — we need a stable Team.
Teams need to include business people and technology people according to Joe. And it should be more fun and satisfying to work in such a team. If you have a great team, he suggest to keep it stable:
[A great team] improves in the 5x-10x range. (…) This is the goose that laid the golden egg. (…) if you continue to give them good satisfying work to do, they may never need to change.
Stable teams ask for a shift in orientation in how we organize the work that needs to be done:
We no longer start with projects, and find people to do them. We now start with a Team, and find good work for it to do.
Everett Zufelt wrote a blog post building teams & avoiding dysfunctions, in which he looks at team dysfunctions, and how to grow teams. He starts with his definition of a team:
(…) there is a sharp distinction to be made between a group of people working on the same project, and a team working toward a common result. A team is attentive to its common goal, and sacrifices self-ego for team-ego.
To growing a strong team that can deliver more value to our clients, team members need to know each other. Everett explains how this becomes easier over time, as we get to know those with whom we work.
Recently we have adopted the goal of "stable" teams. This does not mean teams that never shift or change, but it does mean that we are paying attention to changes in the size and composition of our teams. Along with other potential benefits, I believe that stability is an important part of building teams that have the ability to be attentive to collective results.
Roman Pichler shares his recommendations on how to create stable teams. He starts by explaining the needs that he sees for stable teams:
Changing the team composition too frequently is undesirable for the individuals and the organization. To flourish, teams need stability. With markets, requirements and technologies frequently changing in an agile world, a stable team provides security and continuity.
He advices to minimalize changes to the teams within and across product releases:
Changing the team composition makes this teambuilding process start all over again and, as a result, productivity and self-organization suffer. (…) ensure that the majority of the team members continue to work on the product to avoid loss of information, defects and delays.
In the value of stable teams, Kelly Waters describes an organizational structure that support stable teams. She explains how creating such a structure is valuable:
As a senior manager, one of the most valuable things you can do for any development team is to create an organizational structure that enables stable teams. Permanent, lasting teams; not teams that assemble for a project and then disband to reform around a new project.
Kelly explains the stages that teams go through: ‘forming, storming, norming and performing’. Getting a team through these stages takes time:
With some teams, they hit it off straight away and get through the process very quickly and with only a little tension along the way. Other teams remain stuck in the storming process for far too long and it’s a long while before they really start performing as a team.
How can your organizational structure support stable teams? Kelly suggests take the products that are delivered as a starting point:
(…) it is best to align teams with specific products or product portfolios. That way they can move together from one project to the next without having to re-establish themselves as a team each time, and with the full benefit of already optimized relationships, processes and velocity. The idea here is about assigning projects to established teams, rather than assigning people to projects and forming a new team each time.
Steve Martin writes about how you can change the team composition in his blog post the dysfunctional agile team member. He start by explaining that sometimes you want to consider the option to remove a team member from a team:
(…) many of my clients don’t want to switch up teams – it’s a sacred cow. “Oh, no. We can’t reconfigure the team. This is who we have. There’s no one else. Period.” I’m saying, “Yes. You can make changes.” No, I’m not talking about flat-out firing someone (although, there are the exceptions where this is the clear and obvious course of action). And no, mixing up team members is not something you do frequently. But, sometimes you just need to switch out team members for the good of the team, stakeholders, and your customers.
To consider team changes, Steve uses a matrix of capability vs willingness of team members:
Capability refers to “technical skills”, such as coding skills, testing skills, business analyst skills, etc. as well as demonstration of Agile values and principles. Willingness refers to the “people” portion of skillset – how they openly embrace and buy into fundamental Agile values and principles, such as collaboration, responding to change, feedback, working as a complete team (not as a specialist), and so forth.
The preference is to have team member which are both capable and willing. Team members with low capability and high willingness can develop their technical skills with pairing, thus increase their capability. For team members with high capability and low willingness, you can invest with personal coaching to increase the willingness, or decide to make this person a consultant to the team in stead of a team member. For team members with low capability and low willingness you have to consider if you want them to be part of your team:
Finally, for those with low capability and low willingness, there needs to be heart to heart conversations from the outset. I have asked even in a first sprint to have these types of folks removed from the team altogether, sometimes with very negative impact from management. This typically passes over time, especially when the team performs.