Across the organization, the Agile process is running smoothly. With multiple teams in place, Agile is well on
its way to being fully accepted, understood and utilized. The majority of the teams are productive. They work well together, and development is progressing at a solid, sustainable pace.
Here's the thing: The teams are busy, but some are less so than others. Why not move team members around to speed the progress of the busiest teams? This resource-switching approach could support the Agile process by allowing project managers to plug team members in and pull them out as needed.
Shuffling members among different Agile teams sounds like a good idea, doesn't it? But don't do it. It's a bad idea.
In this tip, I explain why stable teams deliver the best software quality over time -- and why resource switching is not an effective strategy for boosting productivity and producing better software.
Forming, storming, norming, performing
It might not be evident at first, but on any established team, members have already learned how to work together to support the Agile process. Disrupting a stable team doesn't improve software quality or boost team productivity. In fact, it can have the opposite effect. Resource switching doesn't work because the team has already gone through the "forming" process.
When teams first come together, they go through the stages of forming, storming, norming and performing.
The process of forming a productive team isn't easy, and it requires a significant commitment of personal energy, time and concentration from each member. When teams first come together, they go through the stages of forming, storming, norming and performing. These are Agile terms for getting to know one another and mapping out strategies that turn strangers into members who grow into stable, productive and high-performing teams over time. When project managers switch out team members, that process has to start all over again. When a stable team is disrupted, you force them to regroup and re-form. When a team stabilizes, it's a sign that members have learned how to optimize their skills within working relationships. In the most successful Agile teams, members develop a bond that allows them to be productive and interact on a personal, genuine level.
Optimizing Agile processes
Another advantage of stable teams is that they have learned how to optimize their processes. By "processes," I mean Agile methods and technical processes, such as unit testing, giving demos to testers, code reviews and test reviews, to mention a few. Continuous improvement processes tend to bind members together so they work efficiently. Each time you move members in or out of a team, you force the team to redefine or rework processes. After all, if you think about it as a manager, the members of each team spend a great deal of time and effort getting to know each other -- and getting to know how each person responds to varying viewpoints, egos and differences of opinion until they hash out an effective professional working relationship. Once that balance is reached, it's best to maintain the balance and not disrupt the formative, personal work that's already been accomplished. The team's energy now needs to be spent in developing and testing, not in reestablishing team connections.
Stable teams boost productivity, quality
Stable teams have higher productivity and established velocity. They already know how each member works and what they can expect from one another. They've established a working order that results in a set velocity that results in more accurate planning. That enables project managers to reliably predict the outcome of a team's work. But if the team is disrupted -- and forced to incorporate new members -- velocity and productivity will be in flux until new members find their place in the established team flow.
How do stable teams affect software quality? It's easy to fall into the trap of thinking that adding more testers will boost quality. The more testers you have, the more testing that occurs, the greater the quality and the lesser the chance that defects will make their way into production. But this isn't true for stable Agile teams. In Agile, the whole team bears responsibility for testing, not just the testers. And in my experience, stable and productive teams devote more time to quality. They keep the customer experience in mind and focus on reducing customer issues and defects. Software professionals don't want to hear that customers of their software have run into a problem. And within an established team, it's even more personal: The team, not the testers, missed an issue.
Agile produces personal satisfaction
Stable teams provide higher quality and productivity. They also allow members to experience a higher degree of personal satisfaction. "What?" you might be asking. "Personal satisfaction? What has that got to do with anything?" Here's what: Stable teams provide personal satisfaction. In small groups, most people are able to shine and showcase the depth of their abilities. Stable Agile teams produce star members who might not have been noticed otherwise. As a project manager, it's vital to provide a consistent, stable work environment to improve employee satisfaction and retention.
Yes, it's difficult to resist the temptation to switch out team members to fill gaps and holes in other projects. And, yes, even stable teams are likely to change at some point. However, to provide the maximum positive impact on quality, productivity and employee satisfaction, it's critical that stable teams be kept intact. Plug-and-play simply doesn't work with real, working people.