2. Creating a Strong Team Foundation

Agile success starts with a strong team. Ideally that team is cohesive, cross-functional, and self-organizing, though most teams start out as a collection of individuals who have to learn how to work with each other to achieve their shared goals. Members of new Scrum Teams, especially those who are not used to working as part of a cross-functional team, often struggle at first to produce “Done” Product Increments in every Sprint. In this chapter, we consider how teams can overcome these challenges.

Forming a Team Identity

You cannot simply put a group of people together, tell them “You are a team,” and expect them to achieve great things. Forming a team means making an investment in bringing a group of people together to achieve something they could not achieve by themselves. Together, the team members form an entirely new living and breathing organism that develops an identity over time.

At a fundamental level, establishing a team’s identity is shaped by answering three questions that guide a team on its journey toward performing:

  • Why do we exist—what is our purpose?

  • What is important to us—what values do we hold dear?

  • What do we want to achieve, together?

Just as we do as individuals, every team will constantly refine and clarify its identity as its members learn and grow. A team’s beliefs about its identity help it (or hinder it) on its journey toward achieving shared goals and continuously improving its effectiveness. In the context of agile product development, an agile mindset provides a helpful starting point in forming a Scrum Team’s identity.1

1. For ideas on how to leverage the Scrum values and the Agile Manifesto values (www.agilemanifesto.org) to refine a team’s identity, see https://www.scrum.org/resources/blog/maximize-scrum-scrum-values-focus-part-1-5.

What Makes a Good Team Member?

We are human, and as such we make mistakes, even though we may have good intentions. We want to do the best we can. We want to grow and learn. We are all capable of much more than we know. We thrive when we feel a sense of connection and have community. We are also wonderfully unique.

Even in a team environment, understanding and appreciating the individual is important. Although individuals need to let go of their individual status and ego to focus on team goals and outcomes, each person on the team still has his or her own needs to be met. After all, engaged and fulfilled people will be more creative and productive and probably even more enjoyable to work with.

Three aspects are important to consider to appreciate the unique skills and talents that team members will bring to the team and to understand how being part of that team may help those individuals grow and find fulfillment:

  • Personality. People are wonderfully unique; they have different personalities, which show up as preferences and behaviors that tend to persist across a lifespan. Some characteristics are genetic in origin, whereas others are shaped by experiences. However, people can consciously choose to act differently than their innate preferences so as to meet the team’s desired goals.2

    2. https://carleton.ca/economics/wp-content/uploads/little08.pdf

    Personality differences create conflict, but these same differences create diversity that expands perspectives in ways that make teams more innovative and effective.3 When teams are effective, team members figure out how to navigate conflict in healthy ways.

    3. https://hbr.org/2013/12/how-diversity-can-drive-innovation

  • Emotional intelligence. Emotional intelligence is about understanding and managing your own emotions and behaviors and being able to recognize and influence the emotions of others.4 Emotional intelligence helps people understand when and how to express their personality traits.

    4. For more background on emotional intelligence, see Daniel Goleman’s Emotional Intelligence: Why It Can Matter More Than IQ (Bantam Books, 2005).

    According to research by TalentSmart, emotional intelligence comprises a flexible set of skills that can be improved with practice. Although some people naturally have higher emotional intelligence than others, you can acquire and grow this skill set. Furthermore, TalentSmart has found that 90 percent of top performers are also high in emotional intelligence. On the flip side, just 20 percent of bottom performers are high in emotional intelligence.5 This makes sense when we think about the nature of product development.

    5. Travis Bradbury and Jean Greaves, Emotional Intelligence 2.0 (TalentSmart, 2009).

  • Intrinsic motivation. While motivation matters for all work, self-organizing teams simply are not effective unless each team member is intrinsically motivated. As Dan Pink notes in Drive, knowledge workers are not motivated by extrinsic rewards like money; instead, they are motivated by three factors:6

    6. Dan Pink’s book Drive (Riverhead Books, 2011) provides a compelling discussion of what motivates people working on complex intellectual tasks, which is summarized in the following short video: https://www.youtube.com/watch?v=u6XAPnuFjJc. For more information, see https://www.danpink.com/drive.

    • Autonomy. People are in control of how they do their work.

    • Mastery. People have the ability to become great at something, to grow and sharpen their knowledge and skills.

    • Purpose. People feel they are working on something bigger than themselves. They see meaning in their work.

In Practice: Personality and Emotional Intelligence

A Scrum Team has built up frustration with a team member named Alex whom team members say is “negative,” “antagonistic,” and “? ippant.” The new Scrum Master has been getting these complaints from individuals for a few weeks. She has also closely observed interactions between Alex and the rest of the team and senses that Alex’s personality puts him low on the agreeableness scale.7

7. While many models for understanding personality preferences have been developed, the factor agreeableness comes from the Five Factor Model. See https://positivepsychology.com/big-five-personality-theory.

Through a series of one-on-one conversations with Alex and team members, as well as leveraging opportunities presented in team discussions about their work, the Scrum Master helps create a better understanding of differences in personality and the benefits they provide. Team members begin to realize that Alex is not trying to be negative or skeptical of their ideas. His nature is simply to question things first in an attempt to understand better, to ensure that there has been sufficient exploration. They even begin to appreciate and seek his input more often. Alex also has a better understanding of how his comments can be perceived negatively by team members and even feel hurtful, and he is more mindful of how he questions and explores his colleagues’ ideas.

By learning more about their own and each other’s personalities, team members are better able to choose how they show up in their daily interactions. In turn, they are better able to achieve desired outcomes while feeling more ease in how they work together.

Successful teams are composed of team members who are self-aware enough to understand their own strengths, have sufficient emotional intelligence to adapt their reactions to those around them, and are intrinsically motivated to work with others to achieve things that they could not achieve on their own.8

8. For more on the skills and traits that individuals can grow to become better at teamwork, see Teamwork Is an Individual Skill by Christopher Avery (ReadHowYouWant, 2012) and The Ideal Team Player by Patrick Lencioni (Jossey-Bass, 2016).

Who Should Be on a Scrum Team?

In a perfect world in which everyone has all the skills that a team might need, we would say that the answer to this question is “anyone who wants to be on the Scrum Team.” In reality, when you need to keep the number of people on the team small enough to manage the complexity of communication, and you need a lot of different skills to deliver a “Done” Product Increment in every Sprint, you have to make wise choices and thoughtful trade-offs about who is on the Scrum Team and who is not. Then, as a team, you must work within the constraints established by those choices.

Over time, you will need to continuously improve your skills. As a team, you do the best that you can with the skills that you have today and then work to grow skills to fill any gaps. Being on a cross-functional team means that team members are willing to do things to contribute to overall success even if they may not be the best or the fastest at doing that thing. Such teams figure out how to leverage the skills and knowledge they have as a whole, and they take action to grow when they discover gaps and bottlenecks that are slowing them down. Over time, this means that they will gradually develop more and different kinds of “deep” skills (see Figure 2-1).9

Three different patterns represents how team members develop skills.
Figure 2-1 Over time, team members tend to develop deep skills in more areas.

9. “T-shaped skills” is a metaphor for a person having broad problem-solving or business domain skills as well as deeper skills in an area of specialty (see https://en.wikipedia.org/wiki/T-shaped_skills). Pi and comb-shaped skills simply refer to a person having deep skills in more than one area of specialty.

Development Teams own their cross-functionality. Indeed, this is a key aspect of self-organization. A Development Team may choose to add someone to the team to gain more skills and knowledge. Team members may also choose to get formal training or spend time on self-directed learning so as to develop broader and deeper skills and knowledge. In addition, a Development Team may choose to work in a way that supports mentoring aimed at further growing existing team members. As the product and the team evolve, the distribution of skills and knowledge across team members will need to evolve as well.

Development Teams Need to Know About More Than Just Development

When you think about the skills required to deliver a “Done” Product Increment to customers or real users, consider the following questions:

  • Is it useful for Development Team members to understand how the product is used by customers?

  • Is it useful for Development Team members to understand how product changes might impact business processes or other products used by customers or in the organization?

  • Is it useful for Development Team members to understand how their product may be affected by changes to other products, business processes, and policies in the organization?

Of course, the answer to all these questions is, most emphatically, yes! Business analysis skills are an important part of delivering a working Increment of value, but this doesn’t always mean that you need a Business Analyst on the Development Team; you have to move beyond the old ways of building products.

What if someone with this business context joins the Development Team? How can this person’s knowledge and experience and skills contribute to the work in a Sprint? Perhaps the new member can answer questions to guide the direction of a Product Backlog item (PBI) while it is being developed. Perhaps this individual can contribute to improving quality by offering input on testing approaches and test case details and by assisting with the testing effort itself. Perhaps the member can play a role in developing online help, training materials, or business change management activities. Perhaps he or she can contribute to Product Backlog refinement. All of these contributions will help the Development Team meet its definition of “Done.”

Not everyone on a Development Team has to know how to write code, and creating a valuable “Done” Increment requires much more than just writing code.

How Do Scrum Teams Form Working Agreements?

Working agreements help a group of individuals with different personalities, preferences, and experiences work together effectively by being explicit about what commitment to the team looks like. Keep in mind that working agreements are not the Scrum Master’s rules to enforce. Instead, the entire Scrum Team takes on this responsibility: Team members hold each other accountable and address issues as they arise. Working agreements are not static, however, and teams should regularly revisit and update them as the team evolves.

Working agreements often address three areas:

  • Tasks, or the expected activities and deliverables for the team

  • Process, or how the activities will be carried out

  • Norms, or the ways in which team members will interact with each other

Creating a working agreement contributes to the formation of a strong team identity. Working agreements are born out of the values and principles that the team members hold dear, and developing working agreements often makes these values and principles concrete. Such an agreement establishes a foundation on which the team can self-organize. A team is more committed to team success over individual success when all members share a common set of values and principles. It is also easier to commit to team decisions even if an individual has some concerns when that person knows those decisions are grounded in values and principles.

Asking the following questions may help you develop your team’s working agreement:

  • What are our standards of quality, and how will we ensure we meet them?

  • How will we collaborate effectively?

  • How will we share information within the team and with stakeholders?

  • What are our standards for meeting attendance, promptness, and participation?

  • How will we make decisions?

  • How will we surface conflict or disagreements?

  • How do we want it to be when we are in conflict?

  • How will the Scrum values guide our interactions and our work?

  • How will we grow knowledge and skills across team members?

  • What does respectful behavior look like for us?

  • How will we monitor our performance and progress?

  • How will we hold each other accountable for our commitments?

The Development Team’s definition of “Done” is also a working agreement about how team members will ensure quality and completeness of a Product Increment.

In Practice: The Team Purpose Statement

Helping a team construct its own purpose statement (see Figure 2-2) can be a useful way to bring the team together and to bring clarity and transparency to its working agreements. A purpose statement addresses the following elements:

  • What: what customer needs the team is attempting to fill

  • How: the methods or technologies the team will use to fill those customer needs

  • Who: a description of the primary customer(s)

  • Why: the reasons why it is important to fill those customer needs

  • Special Sauce: what makes the team different

A figure shows a sample team purpose statement that reads, "We provide easy-to-use content management solutions so that our users can be more effective in doing their jobs and serving customers, trusting they are in compliance with all regulatory, legal, and security standards."
Figure 2-2 A sample team purpose statement.

What Does Self-Organization Look Like?

A self-organizing Scrum Team is able to determine how it does its work. In practice, this can manifest itself in a variety of ways:

  • Scrum Teams take ownership of their processes. They don’t blame the process. They change things that aren’t working well and challenge the organizational processes that are impeding them.

  • Scrum Teams determine a Sprint Goal together. Development Teams decide how much work they can forecast in a Sprint together. Development Teams decide how they will do the work together.

  • Development Team members don’t wait until the Daily Scrum to bring up challenges or impediments.

  • Development Team members decide how and when to swarm problems that jeopardize the Sprint Goal.

  • Development Team members update their Sprint Backlog to reflect current progress and new learning.

  • Scrum Teams determine how they will improve as a team and take ownership of implementing these actionable commitments in every Sprint.

  • Scrum Team members address and resolve their own disagreements and conflicts.

  • Scrum Teams make consensus-based decisions in a timely manner. They determine if they need to consult outside expertise.

Effective self-organization requires three things: shared goals, clear accountabilities, and boundaries (see Figure 2-3). If any of these weaken, the team may lose the ability to self-organize and become less effective.

The three important aspects needed for effective self-organization are represented in the form of a three-legged chair that requires all the three legs to stay balanced. The three legs are: shared goals, boundaries, and clear accountabilities.
Figure 2-3 Effective self-organization requires all three legs to stay balanced.

Shared Goals

All great teams need a goal—the more audacious, the better. They need something toward which they can strive and stretch, and an achievement against which they can measure themselves. Without shared goals, it is easy for team members to follow divergent paths and for a team to lose purpose and cohesion.

Shared goals usually start with the goals for the product, expressed in terms of a clearly articulated business strategy, a well-defined product vision, a clear understanding of customer value, and a clear way to measure it. All of these aspects provide guidance that helps teams see where they are headed and what is important.

The Sprint Goal is also important and provides an overarching purpose or objective for the Scrum Team while conducting the Sprint. It provides focus as the team uncovers new information and encounters challenges while building the Increment during the Sprint. You can look at Sprint Goals as the waypoints that make up the path to meeting bigger, longer-term release or business goals.

Getting even more granular, every day the Daily Scrum is focused on the work that the Development Team will undertake in the next 24 hours to progress toward the Sprint Goal.

Clear Accountability

Scrum provides clear accountabilities for each role. The organization must respect these accountabilities. This means ensuring Scrum Team members are given the authority to fulfill their roles. Team members also need the knowledge and skills to fulfill their accountabilities. This may require an investment in knowledge transfer and training. It may also mean giving people access to information to help guide decisions.

Of course, Scrum Team members need sufficient time to fulfill their roles. When team members have multiple responsibilities beyond their Scrum role, it is important to assess the impact this may have. Which role takes priority? Do individuals have sufficient time to fulfill their Scrum role? How about their other roles? What happens when the individual has to make a difficult choice to let something drop to fulfill the Scrum role, or vice versa?

Furthermore, if a misalignment occurs between how individual performance is assessed and what individual members are accountable for, this can create a dilemma for team members to navigate. Should they do what is in their own best interest for the purposes of having a “good performance review”? Or should they do what’s best to fulfill their Scrum role?

What it takes to fulfill the Product Owner role, the Development Team role, and the Scrum Master role will change over time as the product, the business, and the Scrum Team evolve. To ensure that these needs can be addressed, it is important for Scrum Teams to continue assessing what is needed now and in the near future.

Boundaries

The Scrum Framework, including its 11 elements and the rules that bind them together, provides boundaries that make it “safe” for the Scrum Team to self-organize. By “safe,” we mean that the risk of failure is reduced and the cost of failure is limited.

Time-boxes in Scrum are an example of boundaries that provide focus, create a sense of urgency, reduce waste, and limit risk. Consider how the use of time-boxes is providing these benefits to the team or where their benefits may be lacking.

A “Done” Increment is required at least by the end of a Sprint, and a definition of “Done” provides a clear boundary of what quality and completeness means to a Development Team. Note that an organization may have a minimum baseline definition of “Done”—this is an example of the organization setting the minimal boundary that a Development Team can then build upon.

There may be a need to establish and clarify boundaries beyond the Scrum Framework. These boundaries may relate to technology decisions, team development, or many other categories. Ask these kinds of questions to clarify boundaries:

  • What decisions is the Scrum Team empowered to make?

  • Who does the team need to consult for certain types of decisions?

  • Who does the team need to inform when it makes certain types of decisions?

For example, a Scrum Team may need to consult with an Enterprise Architecture group when team members want to bring a new technology into their product platform. They may simply need to inform an Enterprise Architecture group when they are making changes that grow the size of their product platform.

Another example is the decisions that a Scrum Team can make regarding team development. A Scrum Team is autonomous in how its members work together to build the Increment, teaching and mentoring each other to grow skills, but the team may have to consult a manager when it wants to invest more than a specific dollar amount for training and other learning resources.

Leadership and Self-Organization

Leadership is essential for creating the conditions for effective self-organization. In Turn the Ship Around!, David Marquet describes the relationships among the three factors of control (i.e., giving more control), competence, and clarity as a means to create a space of intent-based leadership.

The leader’s job is to support Development Teams in their efforts to increase their overall competence. The leader can help teams build competence and clarity and then give them more control. Alternatively, the leader can give more control first and then fill in the competence and clarity. The way to rapidly change and improve is to give more control first, which requires that leaders trust their teams. It is easier for them to do this when they have the boundary of a Sprint to create focus and minimize the impacts of failure.

People develop competence and clarity fastest when they learn by doing the work—that is the essence of empiricism! Even when they come up short of their goals, they learn new things that help them move closer to the goal the next time they try. Some agilists refer to this approach as “failing fast” but, in truth, the only real failure is failure to learn from experiments.

How Do Scrum Teams Collaborate?

A self-organizing, cross-functional team needs to learn how to collaborate. To do that, team members need to invest in building “collaborative assets.” Five assets help teams reap the benefits of effective collaboration:10

10. If you have read Patrick Lencioni’s leadership fable The Five Dysfunctions of a Team (Jossey-Bass, 2002), these assets may seem familiar. In his highly acclaimed book, Lencioni presents five dysfunctions. Here we focus on the opposite of these dysfunctions—that is, the assets of collaborative teams.

  • Trust

  • Productive conflict

  • Commitment

  • Accountability

  • Shared goals and outcomes

These assets, as depicted in Figure 2-4, build upon one another. If you don’t have trust, it will be impossible to have the other four assets. If you don’t have productive conflict, it will be impossible to have commitment, accountability, and shared goals. And so on for each asset.

The five assets for effective team collaboration are shown in the form of blocks. They are arranged in the following order from bottom to top: trust, conflict, commitment, accountability, and goals.
Figure 2-4 These assets form building blocks for effective team collaboration.

Trust, in this context, means willingness to be vulnerable with one’s fellow team members, such as willingness to admit a mistake or ask for help. When team members trust each other, they are open to productive conflict: They are willing to challenge each other, to challenge assumptions, and to be open to and share what they think may be wild and crazy ideas.11

11. For more on this topic, see https://www.agilesocks.com/build-trust-enable-agility/.

In Practice: Building Trust

Trust is a willingness to be vulnerable, a willingness to make something important to you be vulnerable to the actions of others. People who work in an atmosphere of trust can collaborate productively, enabling things to get done faster and at a lower cost. Conversely, when trust is absent, business slows down and costs rise as people spend more time trying to protect themselves against those whom they cannot trust.12

12. The Speed of Trust by Stephen M. R. Covey (Free Press, 2008).

There is no one sure way to build trust, and there are countless ways to destroy it. We see trust as an ongoing journey that is more about consistency in how you show up in your relationships and interactions. This journey is never complete, and you can easily move backward. Here are some techniques that we use to build trust:13

13. For a deeper insight into building trust, see https://brenebrown.com/videos/anatomy-trust-video/.

  • Go first. You may need to be the one to give trust first before you have it returned. Be vulnerable to show others it is okay to be vulnerable. Ask for help. Admit your mistakes.

  • Be willing to say no. When you overcommit, you put yourself at risk for not following through and negatively impacting others. You can be perceived as unreliable.

  • Assume positive intent. Do your best to always assume positive intent about another person’s actions or words. While it may be appropriate to address a situation when someone’s actions or words have had negative outcomes, have that conversation assuming the person had good intentions. This helps you address the conflict, resolve issues, and come to a better understanding of each other while showing you trust the other person.

  • Avoid gossiping. Talking about people is often perceived as an easy way to make conversation and bond with others. However, the unintended consequence is that it makes you appear to be untrustworthy. If you talk about someone and share something that person told you in confidence with me, how do I know that you wouldn’t do the same with something I told you in confidence?

  • Match your words to your actions. Make sure that you live up to what you profess to believe is important. If you tell your team that sustainable pace is important, yet you work long hours and answer emails on the weekends, there is a misalignment between your stated beliefs and your actions.

  • Be open and honest with people. Creating an environment in which people can be open and honest about their feelings, their concerns, and their desires is essential for trust. You may have to go first, leading by example. When creating working agreements, ask team members what agreements they need to be open and honest with each other.

  • When you make mistakes, share the learning. Rather than focusing on blaming (or worse, shaming), help everyone recognize that every mistake is a learning opportunity. Encourage team members to share their own learning opportunities with the team. You may have to go first, leading by example. Refer to your own mistakes when teaching moments arise.

  • Get to know each other as people. Encourage team members to see each other as people with rich experiences and full lives beyond the office. Create situations that help people bond over their personal stories. You may sensitively ask about family, friends, hobbies, or interests. Consider starting by sharing personal information about yourself first.

Conflict, in this context, means using conflict in productive ways to generate new ideas and explore different solutions. Effective teams use the diverse perspectives of their members to constructively challenge and improve solutions. Passionate arguments, when conducted with mutual respect and while seeking the best possible outcome, are sometimes the catalyst that enables breakthrough solutions. Productive conflict involves questioning the status quo, challenging assumptions, and overcoming limiting beliefs.

In Practice: Navigating the Conflict Spectrum

Once team members trust one another, they can exploit the power of productive conflict. Sometimes the team may even want to seek out conflict to deal with complex issues, whereas at other times they will want to defuse conflict.

So how does a team know if conflict is productive? When conflict exists because team members have diff erent viewpoints but still share a common commitment to achieving the best outcomes for their customers, stakeholders, and organization. If conflict makes you a little uncomfortable, keep in mind that positive conflict always emerges from a desire to change for the better.

It helps to understand your own natural response to conflict, which is an element of your personality. It’s not right or wrong; it’s simply a preference. You may choose to override that initial preference, if you are aware of it.14

14. The Thomas–Kilman Instrument (TKI) is one tool for understanding conflict response modes.

Conflict tends to escalate in a graduated way. It may start with simple differences in perspectives and ideas. Perhaps personal factors and environmental factors might then contribute to conflict progressing in ways that are driven by a need to protect oneself, to be validated, or to uphold deeply ingrained belief systems. Also, people may turn to techniques such as forming coalitions, undermining, or even threatening. What is important is to recognize the level of conflict and respond in ways that move people toward a shared commitment to seek the best possible outcomes.

Being able to engage in and resolve conflict productively is important for selforganizing teams. Some teams may need help in the form of learning how to engage in productive conflict. Other teams may need help with facilitating the de-escalation of unhealthy conflict. And in some cases (e.g., harassment, risk of physical or emotional harm), immediate action may be needed to intervene, separate, and take appropriate steps.15

15. We encourage you to look for additional resources to understand models for conflict. We will offer two to explore here, but keep in mind that the best model is one that helps you and your team engage in productive conflict. While Speed Leas applied his Levels of Conflict model in religious organizations, it has been embraced in the agile community and written about here: https://dzone.com/articles/agile-managing-conflict. Another model to consider is Friedrich Glasl’s nine-stage model of conflict escalation: https://www.mediate.com/articles/jordan.cfm.

Commitment, in this context, means that once the team resolves conflicts and reaches consensus, team members are committed to the decision because they perceive that their ideas and perspectives are respected by their fellow team members. We often use the phrase “disagree and commit” to reflect that team members may still hold to their own opinions, but they commit to their fellow team members to respect the team’s decision.

In Practice: Facilitating Consensus

The consensus techniques described here are ways to gather quick and transparent data about where a team stands on a decision. Here are a few examples of when these techniques could be used:

  • To determine the Sprint events schedule.

  • To confirm the Development Team’s agreement on the Sprint Goal and the Sprint Backlog.

  • During collaboration sessions for design or architecture approaches.

  • In Product Backlog refinement sessions to determine how to break down features/functions into smaller PBIs and/or how and when to run experiments for feedback and learning.

The assumption when you use these techniques is that sufficient discussion has already happened to ensure everyone’s ideas have been explored for shared understanding, and everyone has been heard.

Fist of Five is a consensus technique that allows groups of people to quickly understand where they agree or disagree. People indicate their level of support by holding up one hand and indicating a number. It may take a few rounds of discussion and check-in to reach a consensus-based decision. You can use time-boxes to help keep the discussions focused and avoid getting into analysis paralysis.16

16. For more information, see Jean Tabaka’s book Collaboration Explained: Facilitation Skills for Software Project Leaders (Addison-Wesley Professional, 2006).

Roman Voting is derived from how the Romans indicated their will in the gladiatorial arena. With this technique, people indicate their level of support with a thumbs-up, thumbs-sideways, or thumbs-down gesture:

  • Thumbs-up means I support this.

  • Thumbs-sideways means I will go along with the will of the group.

  • Thumbs-down means I do not support this and wish to address the group.

If all thumbs are down or all thumbs are up, you have quite clear consensus. In case of a mixed vote, be sure to allow people with thumbs-down to speak. Be cautious of decisions where all thumbs are sideways because the group may have some artificial harmony or unhealthy conflict that needs to be explored at a deeper level.17

17. https://www.mountaingoatsoftware.com/blog/four-quick-ways-to-gain-or-assess-team-consensus

Accountability, in this context, means that team members hold each other accountable for the commitments they have made. It takes courage to challenge a fellow team member for not upholding commitments. Because accountability is built on trust, along with the knowledge that everyone shares the same goals, the inherent conflict in these conversations is defused and channeled toward productive discussions about how to move forward.

Team members holding each other accountable is more effective than management holding teams accountable. This is also why commitment is the building block that leads to holding each other accountable. Team members will feel more accountable for their own commitments than for commitments others make on their behalf.

When team members are willing to hold each other accountable, they enable the team to set and meet higher standards. This could show up as higher quality, better solutions, greater learning, and more innovation.

When there is accountability within a team, it is then possible to focus on shared goals and outcomes.

How Do Teams Progress?

Teamwork is essential, but it doesn’t happen automatically, and it doesn’t usually happen quickly. Most teams go through a series of stages as they come together and build the assets they need for effective collaboration. Bruce Tuckman’s model of group development is one way to view the changes that a team goes through as members learn to work together (see Figure 2-5). Some teams never progress beyond the lower levels, and teams can fall back to earlier stages when setbacks occur, new members join, or key members leave.

The five stages in Tuckman's model of group development are shown. The five stages are forming, storming, norming, performing, and adjourning. Arrow marks also indicate that teams can fall back to the previous stages.
Figure 2-5 Tuckman’s model of group development18

18. See https://project-management.com/the-five-stages-of-project-team-development for more background on Tuckman’s model and its application to team development. While Tuckman’s model appears to show that teams progress in a linear fashion, the reality is much more complex. Nevertheless, the model provides a perspective on how teams evolve.

When teams are forming, they are trying to understand each other. They may be reserved in their interactions. They avoid conflict while they work to establish boundaries.

As differences begin to surface (remember the discussion about personalities) and team members become more dependent on each other, conflicts begin to arise. Tuckman calls this stage storming.

As teams begin to channel their conflict more productively and gain a better understanding of how they can work more effectively together, they are said to be norming. Members begin to focus on team goals and set standards for quality and effectiveness. They are committed to the team and take pride in being part of the team and the work they produce as a whole.

As the team evolves together, members begin to operate more smoothly and autonomously. They are now performing. You will see passionate debate among team members because they are committed and dedicated to creating the best outcomes, keeping high standards, and continuously improving themselves. While they cannot predict the future, they exude a confidence that as a team they can meet any challenge.

Adjourning occurs when a team disbands. This termination can be quite stressful, especially when it happens suddenly and is unplanned. Even the best teams can find this stage disorienting and demotivating.

In reality, teams move between these stages in response to external events. A performing team can run into new challenges that require members to expand their skills and knowledge, and the resulting uncertainty and conflict may pull them back to norming, or even forming, if they have to add new team members.

In Practice: Dealing with Setbacks

Here is a situation that we run into quite often: A team that has been performing decided in its last Sprint Retrospective to improve the test automation, forcing team members to learn new techniques and technologies. Pushed out of their comfort zone, they struggle to learn new skills while also trying to complete other work during the Sprint. conflicts and frustration emerge, and their forecasted productivity drops.

The next Sprint Review does not go well. Not only did the team members not achieve all that they had forecast, but they also did not make much progress on automating tests. In their Sprint Retrospective, they recognize that they did not anticipate the degree to which their team’s working relationships would be aff ected, or the eff ort that automation would require. Team members agree to be more mindful of these changes as they plan the next Sprint.

Stronger teams with supportive leadership and a learning culture will recover more quickly from such backtracking, whereas teams in organizations that seek to lay blame for setbacks may never recover.19

19. For more on learning cultures, see Peter M. Senge, The Fifth Discipline: The Art & Practice of Learning Organization (New York: Doubleday/Currency, 1990).

In Practice: How Stable Does a Team’s Composition Need to Be?

A stable team is one whose team members don’t split their time too much with other teams and whose team composition doesn’t change too much over time. Members of a stable team can form better working relationships because they spend more time together, which allows time for the members to develop trust in each other. These teams also tend to be more familiar with the product and the business domain because they spend more time working on a single product.

Some organizations find it difficult to maintain stable teams because their products don’t need to change quickly, so they do not need a dedicated team. Furthermore, team members may want to work on diff erent products, learn new technologies and business domains, and work with diff erent people.

Even when team members could work on one team, the team may need to vary the skills on the team over time, so it may need to move people on and off the team. Or perhaps team members may be shared with other teams when they all need the same scarce skills.

Virginia Satir created a five-stage change model that describes the eff ects that each stage has on feelings, thinking, performance, and physiology.20 As depicted in Figure 2-6, at the point of change, the team enters resistance where it experiences a decline in performance. This change interrupts stability and familiarity, and some individuals may be in denial, avoidance, or even blocking mode. Chaos is the period of erratic performance that occurs while the team members search for a way to deal with and incorporate the change in their world. When they find this transforming idea, they enter integration. During this time, performance trends upward as the team integrates this new change and even sees how it can be beneficial. Ultimately, team members find a new status quo in which they have fully assimilated the change.

The SATIR change model is depicted.
Figure 2-6 Introducing change to a team causes instability and a drop in performance.

20. https://stevenmsmith.com/ar-satir-change-model/

When we implement planned change, such as adding a team member, we are hoping that the new status quo will be greater than the old status quo. But, of course, there is no guarantee that we will achieve this improvement.

So what’s the answer? The goal is “stable enough.” The goal is for the Scrum Team to find a dynamic stability—that the team can recover quickly from a change, whether planned or unplanned. When you are implementing a planned change such as adding or removing team members to an existing team and when you are forming new teams, involve team members in the decision-making process. When possible, let them own the decision. If team members have a say, it is more likely that the inevitable drop in performance will be less severe and last for a shorter time, and ultimately the team may experience higher performance from the change.

Team stability should be something you inspect and adapt to frequently. Observe behaviors and outcomes. Get input from team members. Consider how the amount of change in your team composition could be contributing to less desirable behaviors and outcomes.

Some general advice is to move work to the teams, rather than teams to the work. Amazing teams can learn new things, but growing amazing teams takes time and usually presents the greater challenge. When a team has found that magic, take advantage of it as long as it makes sense.

Characteristics of Productive and Adaptable Teams

When Scrum Teams reach the level of performing, we expect them to be productive and adaptable, “striving to be the best they can be. It is a continuous journey toward something better.”21 When they focus on team goals rather than individual accomplishments, teams are able to create more valuable outcomes. A productive and adaptable team succeeds or fails as a team.

21. See Lyssa Adkins’ Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Professional, 2010), page 21.

At the performing stage, Scrum Teams tend to focus on the following aspects:

  • Improving the quality and completeness of a “Done” Increment

  • Improving the value they deliver to customers

  • Removing impediments

  • Growing team skills and knowledge

  • Improving their way of working through Sprint Retrospective actionable improvements

Considering the “Done” Product Increment as a shared goal, if a Scrum Team fails to deliver a releasable Increment, it has produced nothing of value and has not demonstrated business agility. It does not matter what the individuals accomplished during the Sprint—as a team they have failed to deliver a valuable outcome.

To prevent this from happening, team members adapt what they are doing and how they are doing it when challenges arise so that they can achieve the most valuable outcome in alignment with their shared goals. Productive and adaptable teams have the following characteristics:

  • Are confident that, as a team, they can solve any problem

  • Are committed to team success over individual success, considering both short-term and long-term impacts

  • Are driven by results and take responsibility for their results, seeking better outcomes

  • Are hyper-transparent

  • Make value-driven, consensus-based decisions

  • Actively seek productive conflict

  • Are willing to push themselves beyond their comfort zone

  • Always look to improve their effectiveness and productivity

  • Are able to adapt fluidly to unexpected change

  • Take responsibility for their process, tools, and interactions—if something isn’t working, team members take ownership of changing their experience

Which of these characteristics do you recognize in teams you work with now or that you have worked with in the past? How did it feel to be part of these teams?

Summary

Strong, resilient, cross-functional, and self-organizing teams provide the essential foundation for agile success. Shared values and goals bind the team together and provide team members with principles they can all align to and use to guide decision-making. While all teams will develop at their own pace, creating an environment to enable and grow self-organization, cross-functionality, and effective collaboration is essential if teams are to become high performing and to realize the benefits of Scrum.

Teams are not static, however. As their composition and goals change, they need to revisit and adapt their values and goals. As they do, they will reinforce some aspects of their identity, refine others, and develop in new ways.

Call to Action

Consider these questions with your team:

  • How clear is your team’s purpose, and is it understood and embraced by every team member?

  • How do the Scrum values guide your team’s decisions and ways of working?

  • How do the values and principles of the Agile Manifesto show up in daily interactions?

  • What activities can you do to help team members understand their own and their teammates’ personalities better?

  • Which challenges or limitations with self-organization are holding back your team?

  • What assets does you team want to grow to improve collaboration?

  • How much business process, product value, and user knowledge makes sense to have in your Development Team for your product today?

  • What needs to change to capitalize on the benefits of dynamic stability?

  • What challenges are hurting the most right now? Identify one or two experiments to help create a stronger team foundation. For each experiment, be sure to identify the desired impacts and how you will measure them.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.144.170