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:
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.
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).
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.
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:
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.)
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.
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:
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.)
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.
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.)
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.
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)
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.
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.
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.
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.