Tip

Multi-team Agile process: Shuffling members to meet shortfalls?

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.

    Requires Free Membership to View

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.

Have you shuffled members among Agile teams? Let us know and follow us on Twitter @SoftwareTestTT.

This was first published in April 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.