2

Building the Team

In today’s fast-paced business environment, building an effective Agile Team is crucial for success. Just like in sports, teamwork is key to achieving goals and delivering results. The Covid-19 Pandemic has highlighted the importance of social connections and collaboration, and this has translated into the workplace as well.

In this chapter, we will delve into the essential components of an Agile Team, the roles that each team member plays, and the various types of Agile Teams that can exist in an organization. We will explore the characteristics that make Agile Teams unique and examine how they operate within an Agile Framework.

In this chapter, we’ll cover the following topics:

• What is an Agile Team?
• Agile Team Roles and Responsibilities
• Team Types

Additionally, we will provide practical tips and best practices for building and managing Agile Teams, as well as the challenges that can arise in the process. By the end of this chapter, you will have a comprehensive understanding of what it takes to create a successful Agile Team in your organization.

What is an Agile Team?

An Agile Team is a group of individuals working toward a collective goal. It typically consists of 10 members or less that together have the skills to deliver value to the customer. This includes the ability to define the work, build or do the work, test the work, and ultimately, release or deliver it to the customer.

This is a cross-functional team as they have all the necessary skills to complete and deliver the work. There is often a perception with a cross-functional team that everyone on the team needs to be able to do everyone else’s job. That, however, isn’t the case; we are looking for the team to have the skills, not each individual.

As we consider high-performing teams, we are looking for individuals to be able to flex and help in other areas outside of their primary expertise to ensure long-term team success. An example would be a person who primarily develops code but could help develop test scripts or execute tests. We would then consider this person to be T-Shaped. A T-Shaped individual has a deep area of expertise, and knowledge in other areas, although not as deep as their primary competency.

When we build our teams, we want to optimize them to allow for effective communication and to deliver value each iteration. Often when building a team, you will need individuals from different parts of the organization to work together. This helps improve communication and reduces handoffs and thus waste.

A second consideration when creating a team is that they are self-organized and self-managed. This doesn’t always mean that teams get to do what they want when they want, but that they are aligned toward delivering value and are organized in a way that allows them to be largely self-sufficient and, over time, become self-managing.

Pro tip

Can the teams really be self-organized? If you haven’t read Sandy Mamoli’s book Creating Great Teams: How Self-Selection Lets People Excel [11], then I suggest that you add it to your reading list. However, you must read the Pretty Agile Blog of Team Self-Selection with SAFe® and Structuring the ART [1]. This is a practical example of how this can be achieved with an ART.

When we establish teams, they don’t naturally work together seamlessly from day one. All teams, including professional sports teams, mature to become high-performing teams. Tuckman [2] has defined four stages of group development that teams progress through to become high performing. Tuckman later refined his theory in 1975 and added a fifth stage to the Forming, Storming, Norming, Performing model: Adjourning. This is also referred to as Deforming and Mourning.

Figure 2.1 – Tuckman’s stages of team dynamics (© Scaled Agile, Inc.)

Our high-performing teams know each other, their strengths, and their weaknesses, and work together on a daily basis for as long a period of time as possible. Long-lived teams are key to long-term success as this allows the team to progress through the stages to achieve high performance.

As an organization, it is important to create a working environment for the teams to work together. This may involve investing in infrastructure and tooling, supporting team formation (for example, supporting social time or team building events), establishing working agreements, and rewarding teams and not just individual performance.

To ensure success, Agile Teams have two key roles that are members of the team: the Product Owner (PO) and the Scrum Master/Team Coach (SM/TC).

Agile Team Roles and Responsibilities

As mentioned previously, we have two specialty roles on our Agile Teams. These two individuals work together to help the team become high-performing and to deliver value to the customer in small incremental batches.

Pro tip

In SAFe® 6.0 the Scrum Master role has been retitled to Scrum Master/Team Coach to reflect that SAFe® embraces not just Scrum but also Kanban and other team execution methodologies.

Figure 2.2 – Scrum Master/Team Coach and Product Owner Responsibilities (© Scaled Agile, Inc.)

Due to the importance of each of these roles, let’s take a look at each in more detail as well as outline the responsibilities for our Agile Teams.

Product Owner (PO) and the Agile Team

The PO role is a particularly challenging role in that it often requires both business and technology knowledge and experience. The individual has to manage numerous relationships including with the team, with customers, and with product management at a minimum.

There are some key characteristics you will want to consider when identifying a PO for your Agile Team:

• Vision: A PO contributes to the vision of what the product should be and what it should achieve. This vision should align with the company’s goals and should inspire the team to work toward that vision.
• Effective Communication Skills both Written and Oral: A PO must be able to communicate effectively with different Stakeholders. This includes the Agile Team, management, customers, and other parts of the organization. They should be able to convey ideas clearly, listen actively, and respond appropriately.
• Ability to Understand Customer Wants and Needs: A PO must have a deep understanding of the customers’ wants and needs. They should be able to identify customer pain points and prioritize stories that address those issues. They should also be able to communicate customer feedback to the team.
• Good Business Sense: A PO should have a good understanding of the business side of the product. They should be able to identify the market opportunity, competition, and potential revenue streams. They should also be able to balance customer needs with business goals.
• Technical Knowledge: A PO should have a good understanding of the technical aspects of the product. This includes knowledge of the software development life cycle, software architecture, and design principles. They should be able to communicate technical requirements to the team.
• Good Negotiation Skills: A PO should be able to negotiate effectively with Stakeholders. This includes customers, team members, and management. They should be able to resolve conflicts and reach agreements that benefit everyone.
• Trust: A PO should be trusted by the team and other Stakeholders. They should be able to build and maintain relationships based on mutual respect and trust.
• Courage: A PO should have the courage to make tough decisions. This includes making decisions that may not be popular or may require taking risks. They should also be able to take responsibility for the outcomes of their decisions.

Pro tip

Often, organizations consider the Product Owner role as a “staff-level” position as there is a perception that they just write User Stories. Consider the characteristics outlined previously and the responsibilities outlined as follows and look at individuals who are currently in management roles to become your Product Owners. To be an effective manager, they likely already possess the characteristics we are looking for and may already be informally serving in this role when providing and guiding existing team or individual work.

In SAFe® 6.0, responsibility wheels have been introduced for each role. Let’s look at the responsibilities of the PO in Figure 2.3, starting at the top right:

Figure 2.3 – Product Owner Responsibilities (© Scaled Agile, Inc.)

• Connecting with the Customer: A PO is responsible for connecting with the customer to understand their wants, needs, and pain points. They should gather customer feedback and use it to inform the product strategy in conjunction with Product Management.
• Contributing to the Vision and Roadmap: A PO is responsible for contributing to the ART Vision and Roadmap. They should ensure alignment with the priorities and help communicate the Roadmap to the teams and Stakeholders.
• Managing and Prioritizing the Team Backlog: A PO is responsible for managing and prioritizing the team backlog. They should collaborate with the team to ensure that the team backlog items are clear, concise, and achievable. They should prioritize the team backlog based on customer needs, business goals, and technical dependencies.
• Supporting the Team in Delivering Value: A PO is responsible for supporting the team in delivering value to the customer. They should be available to answer questions, provide guidance, and remove obstacles that prevent the team from delivering high-quality work.
• Getting and Applying Feedback: A PO is responsible for getting and applying feedback from various sources. They should gather feedback from customers, Stakeholders, and the team and use it to continuously improve the product. They should also be open to constructive criticism and willing to make changes based on feedback.

Pro tip

The PO role is a challenging and essential role and isn’t a part-time activity. To ensure the best possible success, we recommend a single 100% dedicated PO for each Agile Team. Finding a PO and ensuring they are set up for success will go a long way in creating a high-performing team.

Scrum Master/Team Coach and the Agile Team

The Scrum Master/Team Coach (SM/TC) is the servant leader and Coach for the team. They facilitate the team events, processes, and practices, and support the team in delivering value.

There are a few key characteristics a Scrum Master/Team Coach should possess:

• Servant Leadership: A Scrum Master/Team Coach should embody servant leadership, which means they prioritize the needs of the team above their own. They should listen actively, support team members, and help remove obstacles that prevent the team from being successful.
• Understands and Empathizes with Others: A Scrum Master/Team Coach should have a deep understanding of the team members’ perspectives, strengths, and weaknesses. They should be able to empathize with the team members and help create a safe and collaborative environment.
• Encourages and Supports the Development of People and Teams: A Scrum Master/Team Coach should encourage and support the professional development of team members. They should help identify areas for improvement and provide opportunities for growth. They should also foster a culture of continuous learning and improvement within the team.
• Uses Influence over Authority: A Scrum Master/Team Coach should rely on influence rather than authority to get things done. They should build relationships based on trust and respect and use their influence to facilitate collaboration and alignment within the team and with external Stakeholders.
• Thinks Beyond Day-to-Day Activities: A Scrum Master/Team Coach should be able to think beyond day-to-day activities and focus on the long-term goals of the team. They should help the team to continuously improve by identifying areas for improvement and experimenting with new approaches.
• Helps Without Diminishing the Commitment of Others: A Scrum Master/Team Coach should be able to help the team without taking over or diminishing the commitment of others. They should provide guidance and support when needed but should also empower team members to take ownership of their work.
• Protects the Team: A Scrum Master/Team Coach should protect the team from external distractions and disruptions. They should help create a safe and collaborative environment where team members feel comfortable sharing their opinions and ideas without fear of reprisal.

Pro tip

Often, organizations consider the Scrum Master role as an entry-level position. Consider a professional sports team – would you select someone who hasn’t coached before as the Head Coach? Probably not. Make sure you don’t overlook the importance of this role. Many organizations have “Team Leads.” These individuals may be good candidates for a Scrum Master/Team Coach as they have already demonstrated the desire already in that type of role.

The following Scrum Master/Team Coach responsibility wheel outlines five key responsibilities of an Scrum Master/Team Coach, in Figure 2.4:

Figure 2.4 – Scrum Master/Team Coach Responsibilities (© Scaled Agile, Inc.)

• Facilitating PI Planning: The Scrum Master/Team Coach facilitates the PI Planning Event, ensuring that the team understands the goals and objectives of the upcoming PI and that the PI plan aligns with the overall business strategy.
• Supporting Iteration Execution: The Scrum Master/Team Coach helps their teams to plan and execute iterations effectively via the team events. They help the team identify and resolve any impediments that may prevent them from achieving their goals.
• Improving Flow: The Scrum Master/Team Coach continuously seeks to improve the flow of value through the team. They identify and eliminate bottlenecks and impediments to ensure that the team can deliver value quickly and efficiently.
• Building High-Performing Teams: The Scrum Master/Team Coach helps to build high-performing teams by facilitating team-building activities and promoting collaboration and communication. They also encourage the team to continuously improve their processes and practices.
• Improving ART Performance: The Scrum Master/Team Coach works with the ART to continuously improve performance. They facilitate collaboration, build trust with Stakeholders, help the teams inspect and adapt, and facilitate Continuous Improvement events.

The Scrum Master/Team Coach role is critical to the success of the team and their ability to deliver. SAFe® recognizes that this can be a part-time or full-time job depending on the size of the team, maturity of the team, responsibilities, and context. Consider your organizational constraints and the experience and training of each Scrum Master/Team Coach when having them support multiple teams or deliver work for the team.

Pro tip

Organizational constraints may influence and push compromises for key Agile Roles and look to have the PO or Scrum Master/Team Coach be a single role or to even have one person fill both roles. You will want to avoid a single individual serving both roles at all costs. It is a conflict of interest and, ultimately, will hamper the team’s ability to reach high performance. The compromise I would be willing to make would be to Train and have team members rotate the responsibilities of the Scrum Master/Team Coach; this comes at a cost as the team won’t be able to deliver as much work each iteration. As teams mature and are kept together as long-lived teams, the need for a full-time Scrum Master/Team Coach may diminish.

The Agile Team Responsibilities

Just like the PO and Scrum Master/Team Coach have specific responsibilities, our Agile Teams have five key responsibilities, as depicted in Figure 2.5.

Figure 2.5 – Responsibilities of an Agile Team (© Scaled Agile, Inc.)

• Connecting with the Customer: Agile Teams are responsible for building products or delivering services that meet customer needs. They need to connect with customers regularly, to gather feedback, and incorporate it into their work to ensure customer satisfaction.
• Planning the Work: Agile Teams are responsible for planning their work, breaking it down into smaller, manageable tasks, and estimating the effort required to complete the work. They create a backlog of work items and prioritize them with the PO.
• Delivering Value: Agile Teams are responsible for delivering value frequently, typically in small batches within short iterations. They need to ensure that their work integrates with others and meets the Definition of Done (DoD).
• Getting Feedback: Agile Teams are responsible for getting feedback on their work from different Stakeholders, including customers, POs, and other members of the organization. They use this feedback to improve their work and ensure that it meets customer needs.
• Improving Relentlessly: Agile Teams are responsible for continuously improving their work processes, tools, and techniques. They need to identify areas of improvement, experiment with new approaches, and incorporate best practices to improve their performance over time.

Pro tip

Task switching, also known as context switching, is the act of switching between different teams and/or tasks. When it comes to team members that are not full-time on a team, task switching can be costly in terms of productivity and efficiency.

The cost of task switching with a team member can be significant. When team members are constantly switching between teams and tasks, it can lead to the following:

1. Reduced productivity: It takes time to switch between tasks and get back into the right mindset. This can slow down progress and reduce productivity.

2. Increased errors: When team members are constantly switching between teams and tasks, it can be easy to make mistakes or overlook important details.

3. Increased stress: Task switching can be stressful, especially if team members feel like they are constantly juggling multiple responsibilities and being pulled in different directions by different teams.

4. Reduced creativity: When team members are constantly switching between team tasks, it can be difficult to get into a state of flow and tap into their creativity.

People are often unaware of the cost of task switching so here is a simple exercise that I get an individual to run.

I ask the individual to horizontally create the following pattern on a flip chart:

I time the whole process. I then ask them to do exactly the same but this time, concentrating on one element at a time:

I compare the timings of the first run with the second; the results are significant. On average, the first run takes about 45 to 50 seconds. The second run was less than 30 seconds. For a simple task, this is a 30% to 40% improvement when not task switching between numbers, alphabet, and Roman numerals.

Now that we understand what an Agile Team is, who is on it, and the responsibilities of an Agile Team, let’s look at the types of teams and how we can organize them in our companies.

Team Types

When we create our Agile Teams, we want to ensure they are organized to deliver value. As described in the book Team Topologies [7], there are four primary ways to organize our Agile Teams, as shown in Figure 2.6:

Figure 2.6 – Team Topologies ( © Matthew Skelton and Manual Pais from Team Topologies)

• Stream-Aligned Team – This team is organized around the flow of work and can deliver value directly to the customer or end user. This is the most common type of Agile Team. Stream-Aligned Teams are empowered to build and deliver value as quickly, safely, and independently as possible. Stream-Aligned Teams are responsible for building and delivering customer value with minimal dependencies on other teams and should be cross-functional and long-lived, developing knowledge and creating efficiencies over extended periods.
• Complicated-Subsystem Team – This is organized around specific subsystems requiring deep specialist skills and expertise. They build and maintain specialized system components, safety-critical systems elements, specialty algorithms or business rules, or parts of a cyber-physical system. Complicated-Subsystem Teams collaborate with Stream-Aligned Teams, maintain their level of expertise, and take responsibility for built-in quality, performance, and architectural robustness.
• Platform Team – This is organized around developing and supporting platforms that provide services to other teams. They provide internal services for Stream-Aligned Teams, reducing their cognitive load and increasing their autonomy. Platforms are treated as products, and Platform Teams should focus on usability, incremental development, and collaboration with Stream-Aligned Teams. Their services should be well-documented, easy to use, narrow in scope, and offer reuse opportunities.
• Enabling Team – This is organized to assist other groups with specialized capabilities and help them become proficient in new technologies. Enabling Teams are teams that provide support and guidance to other teams, assisting them in gaining new skills and expertise around specific technical or product management areas. They are an essential construct in organizations that regularly integrate new practices and technologies, as they help teams get up to speed with emerging technologies. Examples of Enabling Teams include the System Team, which assists Agile Release Train (ART) teams in building and supporting the Continuous Delivery Pipeline (CDP), and specialized teams that provide support in areas such as DevOps, testing, and security. The responsibilities and behaviors of Enabling Teams include identifying opportunities for improvement, collaborating proactively, communicating regularly, and promoting a Continuous Learning Culture.

SAFe® has a specialized Agile Team, which is the System Team, and has specialty roles and services needed for ART success, which is Shared Services. Let’s briefly explore both of those.

System Team

The System Team is a specialized Enabling team that supports the ART in building and maintaining the underlying infrastructure that supports the delivery of value. The team’s focus is on the CDP, the development and deployment environments, and release management. The System Team has several responsibilities, including building and evolving the CDP, developing and maintaining the shared development and test environment, supporting the release management process, and identifying and implementing improvements to the system’s architecture and design. They work closely with other ART teams to ensure that the underlying system infrastructure is reliable, scalable, and secure. For more information on the System Team, their responsibilities, and how they support an ART, check out Chapter 6.

Shared Services

We recognize that Shared Services isn’t a team per se; they are important in providing support to the Agile Teams but are not dedicated full-time. Shared Services are centralized groups that provide specialized technical or business services to the teams. They help to eliminate redundancy and promote consistency across the organization, allowing teams to focus on their core competencies. Shared Services can also provide economies of scale, reduce costs, and improve quality by consolidating resources and standardizing practices. Examples of Shared Services include HR, finance, and legal.

Summary

In this chapter, we learned that an Agile Team is a cross-functional group of individuals who collectively possess the skills necessary to deliver value. We discovered that teams progress through stages of group development to become high-performing and that long-standing teams are critical to long-term success.

We also learned about the importance of self-organized teams that are largely self-sufficient and self-managing. The chapter outlined the key roles of the Product Owner and the Scrum Master/Team Coach in helping the team become high-performing and deliver value in small incremental batches.

Finally, we learned about different types of Agile Teams, and we now have a comprehensive overview of the key elements necessary for an Agile Team to succeed. Let’s next take a look at what an Agile Team does day-to-day.

Further reading

1. Pretty Agile Blog: https://prettyagile.com/2016/12/preparing-for-team-self-selection-with-safe-structuring-the-art/
2. Tuckman, Bruce W (1965). Developmental sequence in small groups. Psychological Bulletin. 63 (6): 384–399. doi:10.1037/h0022100.
3. Agile Teams: https://scaledagileframework.com/agile-teams/
4. Remote Teams: https://scaledagileframework.com/working-successfully-in-agile-with-remote-team-members/
5. Product Owner: https://scaledagileframework.com/product-owner/
6. Scrum Master/Team Coach: https://scaledagileframework.com/scrum-master-team-Coach/
7. Pais, M., & Skelton, M. (2019). Team Topologies: organizing business and technology teams for fast flow. IT Revolution Press.
8. System Team: https://scaledagileframework.com/system-team/
9. Shared Services: https://scaledagileframework.com/shared-services/
10. Team Topologies: https://scaledagileframework.com/organizing-agile-teams-and-arts-team-topologies-at-scale/
11. Sandy Mamoli, David Mole (2015). Creating Great Teams: How Self-Selection Lets People Excel. Pragmatic Bookshelf.