In this section, we share how to guide team development. We first share conditions that support effective team growth. Next, we delve into characteristics you can expect to see in Agile teams. We close by sharing coaching techniques to guide team development and facilitate healthy team dynamics.

The Building Blocks of the Agile Organization

Agile organizations regard the Agile team as an asset because they are the value-creating unit in the organization. For example, a Scrum team generates value by solving complex problems. To increase the chances that teams become and stay effective value-creating units, Harvard professor J. Richard Hackman proposes five enabling conditions that management can put in place to support team effectiveness:

• Real team: Ensure that team members have a shared task, it is clear who is inside or outside ofthe team, the teams’ authority is defined, and team membership is stable.

• Compelling direction: Provide the teams with clear goals, which are both challenging and consequential.
• Enabling structure: Ensure the team has the right people with the appropriate team norms, autonomy, and technical and social skills to perform the work.
• Supportive context: Develop the organizational system to recognize and reward the team’s performance, not just the performance of individuals.
• Competent coaching: After the preceding four conditions are in place, provide access to expert team coaching. This coaching can come from an external person, a manager, or a team member such as a Scrum Master.

What Makes an Agile Team?

If you’ve ever worked in a great Agile team, we are confident that you still remember this experience very well. We have been lucky enough to work in great Scrum teams several times, and that was fantastic. There was a strong feeling of belonging and a shared passion for reaching an overarching goal. 

Commitment

When people can say what they need to communicate and engage in productive discussion with their team members, they feel heard and respected. Whatever the team then decides, everyone is more likely to respect and fully support the team’s decisions, even if the solution is not necessarily the individual’s idea. Each member is committed—to each other, to the organization, and to their growth.

Constructive Conflict

In an Agile team, it is not necessary that the members like each other personally. We have been in great teams where not everyone went out for beers together. However, the team should provide an environment where everyone can speak up without fear of embarrassment or rejection. A healthy team considers different opinions on handling issues, performing work, and achieving the goal to solve complex problems. Its members discuss different points of view and enter into conflict about these matters—but it’s constructive conflict.

Integrity and Trust

Every Agile team should rely on a foundation of trust. Knowing that your team members are competent, and reliable, will behave according to expectations, and have your best interests in mind gives the team more time to focus on performing together. There’s no more wasting time worrying about how things will get done.

Team members keep their commitment to each other and as a team to their stakeholders. To feel committed to a decision requires the trust to engage in constructive conflict with your peers. Therefore, an Agile team seeks to get disagreements out in the open so the members can find the right answers. In poorly performing teams, you can expect to find people who hold on to their mental models, making learning difficult. Integrity is the most crucial characteristic of an Agile team. Do the team members trust each other to do the right thing for the right reasons, even when no one is watching?

Respect

During meetings, everyone participates, and everyone’s opinion is heard. People are respected, though not necessarily supported in their opinions. There is a thin line between respect for the person and respect for the person’s opinion or work. One can completely disagree with an opinion but still, respect the person. When people can separate these two types of respect, they can accept and act on feedback more efficiently.

Self-Control

Agile teams are self-managing teams. Researchers point out that a self-managing team includes the following characteristics:

• The team plans and schedules its work.
• The team takes action on problems.
• It meets organizational goals and gathers information.
• There is a whole task for the group.
• Team members each have a number of skills required for the completion of the work.
• The group has the autonomy to make decisions about methods for carrying out the work.
• Compensation and feedback about performance are based on the accomplishments of the team as a whole.

Role of the Leadership

Agile teams do not exist in isolation. They are part of a larger organization that strongly influences their performance. You can work with the leaders in an Agile organization so that they support the teams in the following ways:

• Improve the organizational design to better support the teams.
• Communicate to teams what is expected of them—their purpose, and how success is measured at the product group level.
• Repeatedly encourage people to reflect on what they learn, apply it to their work, and then pass their learning on to others.
• Be confident in their ability to create an atmosphere of trust and vulnerability.
• Create transparency by sharing relevant information. The teams need to understand why they do what they do to take ownership of their process and results.

Have you ever struggled with building cross-functional teams because of the elusive multi-skilled specialist? It can be a daunting task to create a cohesive team where each expert is willing to broaden their skill set for the benefit of the group. In our next discussion, we’ll dive into this very topic and explore effective ways to inspire and motivate your team to embrace new skills and work collaboratively towards success.

Coaching Multifunctional Learning

An agile team is multidisciplinary and contains a whole arsenal of skills and competencies needed to deliver value to users. The workload on a single speciality is mostly uneven in a complex environment, which means such teams are highly susceptible to bottlenecks. Peak loads on a specific speciality may vary from iteration to iteration. For example, in Iteration N, the team may have a peak workload in the business analysis skill; in Sprint N + 1, the peak workload might shift to testing.

Note that a bottleneck determines a system’s throughput and that spending time optimizing non-bottlenecks will not provide significant benefits. As you can see in the snapshot in Figure 1, the bottleneck at that moment is in testing, because the largest queue is right before this point.

If such a picture is consistently observed in a team, then testing is considered a system bottleneck. When the rest of the team continues doing more analysis and coding tasks, this will overload the bottleneck even more. This is pointless (a suboptimization) if we want to optimize the system performance.

When a subsystem’s goals dominate at the expense of the total system’s goals, the resulting behavior is called suboptimization (Donella H. Meadows. Thinking in Systems).

The Pitfalls of maximizing Utilization in Agile Teams

When an Agile team preserves the goal of maximizing utilization of single-skill specialties, it has multiple implicit backlogs, not one. The existence of multiple implicit backlogs in a team with interdependent tasks leads to a serialization of the team’s work and increases the end-to-end time to get it done. At the end of a iteration, some team members must process the remaining tasks, while the others sit idle, or even worse start working ahead. A focus on individual skills also forces the business to change the order of the Product Backlog to ensure there are tasks for each individual’s single specialty. Thus, the team doesn’t work on the most critical features from a customer perspective.

When a team feels that there’s a significant skill gap between what’s required to develop the product’s critical features and what they currently possess, it can be stressful. As the gap widens, the pressure mounts to increase the number of implicit backlogs, leading to further strain on team members. In such scenarios, knowledge gaps can become so significant that even new teams with separate backlogs must be created to address them effectively.

Focus on making people “busy” impacts the speed of delivering value in the long term. More backlogs mean more local efficiency, but more dependencies and reduced value delivered. The more dependencies, the less probability that a customer-centric feature will be “done” in an iteration.

From single-skilled to multi-skilled, the path to Agile excellence

The fundamental obstacle to optimize for value delivery while maximizing throughput and minimizing cycle time is the absence of multi-skilled specialists, which allows the team to balance the workload across its members.

You can consider implementing an optimizing value strategy in two steps:

• Step 1. Create a single customer-centric Product Backlog that reflects the current understanding of the most important features from a customer perspective.
• Step 2. Ask the team(s) to respect, in general, the order of the customer-centric Product Backlog in development.

Working from a single Product Backlog creates an inevitable knowledge gap in single-skilled team members. The larger the knowledge gap, the more that the developers need to work together and help others in the team acquire additional skills. Over time, team members develop secondary or even tertiary skills and become multi-skilled specialists.

Agile organizations do not train people to create efficient resources. Instead, they form teams capable of embracing change and minimizing bottlenecks. When the system is heavily loaded, even a small change in capacity can lead to a significant difference in cycle time. In Managing the Design Factory, Donald G. Reinertsen writes: 

This ability of autonomous teams to align resources to bottlenecks is extremely important because

it minimizes queues in the development process. Since these bottlenecks can shift rapidly and

unpredictably during a program, the flexibility of team members to work outside of specialty is a critical

tool for dealing with such bottlenecks.

Breaking free from the ‘Make People Busy’ mentality in Agile Teams

There are many options to deal with the situation when Agile teams are used to working in “make people busy” mode. But first of all, you need to reveal the system to itself and create awareness. How to do that?

1. Point out the tendency of the team to focus on resource utilization instead of increasing agility.
2. Conduct a system modeling workshop and let people gain insights into the “making everyone busy” strategy and the consequences associated with it. 
3. Create an awareness that people are working on the less critical stuff from a customer perspective by creating a single queue of requirements (Product Backlog). 
4. Gradually reduce the number of queues (backlogs) over time if there is a painful knowledge gap.

We provide some practical tools and techniques that can help Agile teams to enable multifunctional learning.

Provide Enabling Structures

Whenever possible create the organizational structures that support multifunctional learning and improving

cross-functionality in teams. Remember that from a Systems Thinking perspective the behavior of the people is the product of the system. Don’t simply try to influence people’s behavior.

• Remove the functional manager roles and establish a cross-functional manager position so that managers encourage multi-skill growth.
• Reduce the number of titles and leave one “product developer” title for everyone so that people can’t use it as an excuse to work on something else.
• Introduce multifunctional career paths so that the organization properly values multi-skilled people.
• Plan additional slack time for education and training.

Learning and mastering is a natural trait for human beings. But organizational structures may impede learning and generate dysfunctional behaviors. The prevailing mental model might suggest that people do not care or want to learn, but the organizational system often makes it hard to do so. Resolving organizational impediments and creating enabling structures creates the necessary conditions for cross-functional learning.

Visualize Flow of Work

Visualization is critical for any Agile organizations—it reveals the queues and helps to optimize the flow of work. In digital service and development organizations, in contrast to production and assembly lines, inventory is invisible. If we could do just one single thing when coaching a team, we would visualize the flow of the work. By visualizing the flow of work, one can see the bottlenecks and create awareness.

Introduce a Start Map

A star map is a simple competency matrix that visualizes the cross-functionality of the specific team. It reveals gaps in knowledge and uncovers potential bottlenecks. The rows of the matrix are just a list of team members; the columns contain the competencies and skills needed to deliver value. You can use various symbols to fill the matrix, but the simplest set that we used were as follows:

• “Star” is a deep expertise in a particular skill.
• “Dot” is an intermediate skill.
• “Book”—I want to develop this competence to help the team later.
• “Skull”—In no case do I want to do this, just do not count on me.

Figure 3 provides an example of a star map.

Ideally, we would like to see two or more stars in each column, because then the team becomes truly flexible and can fight the peak loads. The combination of a star and a dot is a good one, too. If we find columns with no stars, this is a wake-up call. But the most problematic columns, in which there are no designations (except for books), indicate dependence on external expertise. 

Here are a few guidelines for using the star map:

• Inspect the tool at least once per quarter.
• The workshop should end with concrete steps to improve cross-functionality. 
• Post the star map as an Information Radiator in a team room.

Use Three Modes of Development

We are convinced that there is no better way to strengthen cross-functionality and simultaneously reduce WIP in an Agile team than by continually working in one of three modes: pair programming, swarming and mob-programming (Figure 4).

Mobbing is a single-piece flow activity. From a flow efficiency perspective, it is the most efficient way to develop, if the team can reduce the transaction costs to the point where it becomes economically feasible to work on one feature from the start to done states. Working in three modes has many advantages. Here, we list just some of them:

• It is one of the best ways to enable multifunctional learning in a team.
• No or little extra code review is needed.
• Trust increases, as the team is forced to learn to negotiate and listen to different points of view, to come to a consensus.
• No transfers or losses of information occur.
• There is collective code ownership.
• High-quality decisions are made, because everyone knows what is going on.
• With perfect flow, the team works on one feature at a time—that is, in one-piece flow (WIP = 1).

We often invite teams to actively experiment with the three modes for a month. After that, they can decide for themselves whether to return to their previous style of work or continue. As a rule, a month is enough for the main benefits to become visible for any Agile team. Most teams continue to work this way.

Introduce Slack Time

Under full utilization, there is also no space for innovation, creativity, or learning. Why? If a team has a tight schedule, muscle memory makes people exploit their primary specializations and current skills instead of sharing knowledge and looking for innovative ways to solve the problem. We recommend using the Slack Time practice described in eXtreme Programming. It is a time buffer that a team explicitly designates in an iteration for unexpected work and multifunctional learning.

Slack time has many forms and could be used for the following activities: 

• Book clubs
• Self-directed discovery and exploration time
• Adding tests to legacy code
• Paying off technical debt
• Architectural redesign
• Participating in communities of practice

The next section is vital in terms of building a high performing team. We mentioned before that a real team needs expert coaching. Coaching comes from an external person, or a team member such as a Scrum Master. The tricky thing is that it is a special type of coaching because the team is a social system. Therefore, you need a systems team coaching.

Systems Team Coaching

As Russell Ackoff reminds us, “The performance of the system depends on how its parts interact, not

on how they act taken separately.” Thus, you can improve the performance of a system by improving the interactions of its parts. interdependent tasks—a social system—suggests that you can improve the performance of a team by improving how the team members interact.

Rather than focusing on individuals or the content of what is said, ideally you will take a holistic approach to identify the circular relationships to help the team understand how their thinking and behavior led to their current reality. Working with an individual outside their team reduces the possibility for overall improvement.

For example, when a team member comes late to meetings, repeatedly slowing the team down, do you focus on that individual? Or do you instead focus on the whole team? In the systems approach, we address the entire team and make transparent to the team how it allows the individual to come late to meetings: If you’re part of the system, you’re part of the problem. 

There is no root cause for complex problems; there is no blame, because all team members play their role in creating their current reality. Therefore, the golden rule of systems team coaching is simple: 

Address the team as a whole.

In team coaching, the system or the team is perceived and addressed as one unitary and coherent client whole (Figure 5).

That is why the client of a systems coach is the system and its relationships. By improving the interactions,

you enhance the synergy between individuals in the teams.

Insights from Systems Coaching

We would like to share some essential insights upon which we build. When we work with teams, we rely on the following systems insights:

• An Agile team is a social system. A social system has a tendency to remain in a stable state, called homeostasis. Homeostasis ensures that the internal conditions remain relatively stable while the environment changes. The team wants the internal conditions to remain stable because that satisfies the outside expectations of the team.
• The stable interaction patterns in a team come mainly from the individuals’ mental models and resulting behaviors.
• Observing the team’s interactions can uncover interaction patterns that show how a team

keeps itself in a stable/blocking state.

• You can probably never determine the root cause of a complex problem. And even if you could, others will likely bring in alternative explanations and you could end up assigning blame instead of solving problems. Therefore, do not look for root cause explanations, but instead help the team discover how their interactions and thinking contribute to current problems.
• A team can define systems improvement actions when team members understand how they keep themselves in the current problematic state.
• Each team is part of a larger system that influences its performance.

Next, we describe techniques that you can use for the following purposes:

1. Perform circular observations to identify patterns of interactions
2. Assess the current team situation

In these techniques, the overarching theme is to not think about linear cause-and-effect relationships

and explanations, but rather loops of influence. These feedback loops help to make transparent

the patterns and underlying mental models.

Perform Circular Observations to Identify Patterns of Interactions

We like to say that when you listen and observe a particular interaction three times, you can consider it potentially to be a systems issue. At the third observation, you can think “Bingo!” and ask yourself: What is going on here? Which thinking is generating this recurring behavior? How does the team keep repeating itself? What are the loops that keep this team from progressing? Figure 6 shows a simple interaction loop.

Loops produce stable patterns of behavior, and they are very powerful. As an example, consider the following loop. 

• The more the Product Owner shows behavior <Pressure the team to commit>, the more

the team thinks <We have to be careful>.

• The more the team thinks <We have to be careful>, the more the team shows behavior <Hold back and ask for more details>.
• The more the team shows behavior <Hold back and ask for more details>, the more the Product Owner thinks <The team is passive and is not committed>.
• The more the Product Owner thinks <The team is passive and is not committed>, the more the Product Owner shows behavior <Pressure the team to commit>.

Figure 7 illustrates this dynamic:

If such a loop is present, your goal is to help the team discover its existence by asking questions and sharing observations. Instead of focusing on the content of the interaction, we focused on its quality. The question is not “What do the people say?”, but rather “How are they saying it?” You are not looking for linear cause–effect relationships, but instead looking to make transparent the circular behaviors, the quality of the interactions, and the underlying thinking.

The next section is about improving team dynamics and trust which is important because it is a component of psychological safety. We shall briefly explain two practical tools that you can use in your team coaching to unleash and build trust in your team.

Improving Team Dynamics: Trust

Despite the significance of trust for team performance, it’s often overlooked in organizations. According to scientific research, trust directly affects a team’s effectiveness. In cross-functional teams, the impact of trust is amplified because Agile teams are characterized by the interdependence of work, large diversity in skills, and high team autonomy. More trust means that more energy is spent on valuable discussions and actual problem solving instead of on political issues and interpersonal conflicts. ORID: Focused Discussion

ORID is a specific facilitation framework that enables a focused conversation with a group of people to reach some point of agreement or clarify differences. Focused dialogue honors the different perspectives people maintain instead of searching for a single “truth.” It is helpful in stopping criticism and avoiding a rush to false conclusions. It provokes team participation.

The ORID method is based on a four-phase model. Each phase addresses a specific area to get a better understanding of reality and collect different points of view. The four levels of reflection form a pattern from which innumerable conversations can be drawn. It simply flows from a natural internal process of perception, response, judgment, and decision. Here is a short description of the phases:

• Objective: Perceptions—what we often call “objective reality.”

• Reflexive: Feelings, emotional reactions to information received from the outside.

• Interpretation: Analysis, understanding of the information and why it is important.

• Decision making: Next steps and conclusions.

Radical Candor

When the “Agile leaders” do not challenge teams, the management, and the whole organization, they become useless. The most effective Agile leaders whom we have seen had the courage to ask the uncomfortable questions, and to keep advocating for the principles and values of Agile. In our experience, they are mature individuals with clear goals and strong backbones. Furthermore, they practice radical candor.
To clarify how leaders can best provide feedback, Kim Scott developed a simple model entitled radical candor, as illustrated in Figure 8.

Radical candor is the type of feedback in which we challenge others directly while simultaneously showing care for those people.

Summary

A cross-functional team is the main building block of any Agile organization. We examined five conditions for team effectiveness and identified characteristics of a successful team: constructive conflict, commitment, integrity and trust, respect, and self-management. Multifunctional learning is a necessity when creating a flexible team. Approaches that facilitate learning include the three modes of development, slack time, star maps, and explicit agreements. Systems team coaching starts with performing circular observations, and is then followed by a systems assessment. Applying techniques that help in building trust can improve communication within the team.