Sergej Khackimullin - Fotolia
Here's your goal: Across the company, Agile processes run smoothly. With multiple cross-functional teams in place, development and delivery progress at a solid, sustainable pace.
But it's easy to throw off that productive stability -- or get Agile team organization wrong from the start. First and foremost, Agile relies on balanced representation from different IT departments. It also relies on team cohesion. It might sound helpful to shuffle members among different Agile development teams to spread the productivity around, but don't do it. It's a bad idea.
Use this guide to find and maintain the right mix of personnel to include in an Agile team setup -- without messing with a good thing. It covers the Agile team organization members and their roles, techniques to work together successfully and Agile leadership.
Who is on an Agile team?
Agile teams are cross-functional, meaning people with different specializations come together to focus on a single project or product. The roles involved often vary. Most commonly, Agile team structure consists of:
- a product manager
- a software architect
Optionally, especially in a large company, Agile teams also include:
- a Scrum Master
- a project manager
- technical documentation teams
Team members might be permanent employees or contractors. Many cross-functional teams work together for years, while others might form to fulfill a temporary business need or project.
The development team designs and codes the software. Developers also fix defects that testers in QA and other team members report. Additionally, developers often determine the most effective coding platform or programming languages to use. Agile development teams work with the software architect on aspects of the entire system, including the platform, back-end processing systems and security technology, patches and protocols.
The testers, or QA engineers, check the code in logical groups as it is completed. QA professionals develop manual or automated test scenarios and plan for different test execution types, such as functional or regression tests. Testers often set up and manage the test server system, which includes deploying release builds of code to evaluate as developers complete stories.
The product manager, or product owner, controls how the application is designed and defines its function. The person in this role gathers customer requirements and creates a vision for the overall business objective design. Product managers set the work in user stories and prioritize them for developers. They also contribute their knowledge of stakeholders' and customers' expectations to design decisions.
The software architect, or optionally the enterprise architect, works with the team to ensure consistency of design. The software architect is essentially a development project manager and designer. This individual often also assists QA professionals in acquiring or creating test data for the testing server system.
The Scrum Master manages the team members. The Scrum Master is highly experienced with Agile practices and keeps the team on track. For example, if a story is blocked in QA because no test data exists or an integrated function fails, the Scrum Master addresses that challenge so quality work can continue. This role is similar to that of a project manager, who may also appear on Agile teams.
If the team includes a technical documentation role, that person creates end-user documentation and help menu information. Technical writers typically work with the product manager and tester to understand and document the functionality accurately.
Should Agile team members change?
It might be tempting to move team members around to balance out busy periods on different projects. In theory, this resource-switching approach enables project managers to plug team members in and pull them out as needed.
But Agile resource switching is a better idea conceptually than in practice. Stable teams deliver the best software quality over time. On any established team, members have already learned how to work together to support the Agile process. Disrupting a stable team neither improves software quality nor boosts productivity. In fact, it has the opposite effect. Resource switching doesn't work because the existing members have already gone through the team development process.
Instead, use these options to achieve stable Agile team organization.
Forming, storming, norming, performing. Forming a productive Agile team requires a significant commitment of individual energy, time and concentration from each member. When Agile teams first come together, they go through what psychologist Bruce Tuckman termed the stages of forming, storming, norming and performing.
At first, everyone must figure out the team dynamics. After a team forms, it establishes hierarchies of decision-making and leadership. Everyone finds their place and function within the team. This process takes time, as team members find their niche within the group's overall normal. In the normalizing phase, the team functions smoothly, with less arguing or trying to rise above the others. The group becomes a team rather than a collection of co-workers. When a team stabilizes, it's a sign that members learned how to optimize their skills within working relationships. The most successful Agile teams develop bonds that allow them to be productive and interact on a personal, genuine level.
When project managers switch out team members, team development starts all over again. When a stable team is disrupted, it must go through the forming, storming, norming, performing process all over again.
Optimize Agile practices. One advantage of stable cross-functional teams is that they have learned how to optimize their Agile methods and technical processes, such as unit testing, demos, code reviews and test reviews.
Each time you move members in or out of a team, you force the team to redefine or rework processes. Think about it as a manager; the members of each team get to know each other -- and get to know how each person responds to varying viewpoints, egos and differences of opinion. Eventually, they hash out an effective professional working relationship.
But innovation doesn't stop there. Continuous improvement processes tend to bind members together to help them work efficiently. The Agile team members produce original ideas and challenge each other constantly to come up with better approaches, leaner methods and more effective coding and testing methodologies. In most Agile development teams, there is always a push to be better, do better and create better.
Maintain the balance and competitive spirit; don't disrupt the formative, personal work that's already been accomplished. The whole team's energy now needs to be spent in development and QA.
Stabilize teams for productivity, quality. Stable Agile teams have established a working order that results in a set velocity. Agile team velocity is used for accurate project planning. Project managers can reliably predict the outcome of a stable Agile team's work.
It's easy to think that adding more testers to a team will boost software quality. The more testers you have, the more testing occurs, so less chance that defects will reach production -- or so the logic goes. But this isn't true for stable Agile teams. In Agile, the whole team bears responsibility for testing, not just the testers. Stable and productive teams keep the customer experience in mind and focus on reducing customer issues and defects.
Boost personal satisfaction. People on stable Agile teams experience a higher degree of personal satisfaction in their work. Team size matters too. In small groups, most people are able to shine and showcase the depth of their abilities. Stable Agile teams produce stars who might not have been noticed otherwise. Project managers should provide a consistent, stable work environment. The effort can 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 lose and add members at some point. After all, people's needs or career choices change. Still, stable teams ultimately provide the maximum positive impact on quality, productivity and employee satisfaction. Plug-and-play simply doesn't work with real people.
Many Agile teams are temporary. They may include contractors who work with the team for a single development project, or shift to different projects on a rotational basis. The same principles of forming, storming, norming and performing apply to these teams. These temporary teams are aware of the project goal and that the team will dissolve. But you can still minimize distractions by stabilizing who is a team member.
How leaders can manage multiple Agile teams
Agile teams thrive when managers can commit their time and attention to the project at hand. Getting leaders to support more than one team is a workable Agile management strategy, when you have a flexible, fair leader. It's certainly preferred to manage a single team, but that is not always realistic.
Even the best managers struggle to excel with Agile across multiple teams. Multi-team Agile management isn't easy, given the unique issues that can arise within and between each group. Here are a few Agile management challenges to consider.
Clarify team roles and responsibilities. Sharing team leaders in roles such as product manager, Agile project manager or Scrum Master is feasible, if the organization approaches it with care.
First, consider the personality characteristics Agile team leaders need to be successful. For example, to manage multiple Agile teams, leaders must understand and embrace the concept of teamwork. Treat team members as peers and communicate clearly. You'll see better collaboration, which improves development velocity. Also, gain a technical understanding of the products that the teams support. Spend time actively involved with each team. When Agile leaders understand the product and are up to date on project progress, there is less time spent on explanations.
Agile leaders who manage multiple teams are most successful when they have a visible role and produce tangible work. They must set priorities and build out work for the team. In cases where there's both a Scrum Master and a product manager, the two leaders should meet and set priorities for each of their shared teams. They should collaborate on the business objectives and detailed requirements needed for team members to complete work.
It's in the organization's best interest for Agile leaders to manage teams that work on the same product, or products that fall into the same general area. The more similar the products, the easier it'll be to track multiple projects. This approach results in less disruption for leaders and enables effective Agile management.
Eliminate distractions. Agile leaders who manage multiple teams require the ability to focus. Control external distractions, such as additional projects that don't directly contribute to team goals. These projects don't enhance or contribute to the product, its quality, or the team's productivity. Agile leaders cannot support multiple teams successfully when they are pulled away by unrelated work.
For example, a Scrum Master that heads two Agile teams is asked to create a new process for the Scrum Master group to improve its ability to plan team tasks. While it's a worthwhile project and idea, it's still an external distraction because it did not originate from the development teams -- and it's not a necessary action. Acting on the request won't do anything to improve the velocity, quality or productivity of the Agile development work.
Communicate clearly. Finally, increase the communication among teams to successfully share Agile leadership. Teams that are organized to share Agile leaders must work together and plan meetings so that leaders stay engaged and involved.
Working together also enables team members to become more independent -- over the long run, they will be less reliant on the day-to-day functional activities the leader performs. It also provides a growth path for team members interested in moving into leadership roles.