Succeeding with Agile: Leading a Self-Organizing Team

One of the earliest models for organizational change was put forth by Kurt Lewin in the 1940s. In Lewin’s model, change is a three-step process: “unfreezing” the current situation so that change may occur, transitioning to a new state, and then “refreezing” the new state so that it persists. Many subsequent organizational change models are similar to Lewin’s in depicting periods of relative stability punctuated by periods of transition. While this may have been Lewin’s world in the early 1900s, current experience runs counter. Change today does not happen in short spurts that interrupt long periods of relative stability.

Rather than moving from one state of equilibrium to another, organizations in the 21st century operate under far-from-equilibrium conditions. Despite the turmoil and frenetic pace this leads to, there are benefits. An organization in equilibrium, and that seeks to return to equilibrium when pushed away from it, is one that resists change. (Goldstein 1994, 15) Organizations that operate far from equilibrium become better suited to continuous change. It is up to an organization’s leaders and change agents to keep the organization in such far-from-equilibrium conditions.

Leaders do this by periodically agitating the organization. By stirring up, exciting or calming, pushing, shaking up, stimulating, and rearranging the organization, leaders are able to keep the organization from achieving an equilibrium from which it will resist moving.This keeps the organization on its toes and better able to respond to or create change.

Agitating the organization becomes a fundamental way leaders and change agents continually move the organization toward becoming more and more agile. As we established in Chapter 1, “Why Transitioning To Agile Is Hard (and Why It’s Worth the Effort),” it is impossible to identify a precise set of steps required to transition to Scrum. Not only is it impossible to predict exactly what Scrum will look like once we get there, but the impact of each change that is introduced is unknowable. In Chapter 2,“Iterating Toward Agility,” we concluded that the solution is therefore to iterate toward agility. In this chapter we look at how leaders and change agents can agitate the organization in various ways to influence the transition and continuous improvement efforts.

So, just who is it I am addressing when writing about leading a self-organizing team? It’s difficult to answer that without knowing the specifics of a given organization, but in addressing leaders, I am addressing anyone with influence or authority over the team. That includes managers who can hire and fire team members. It includes the product owner who determines the scope of the product or system to be developed. It includes the ScrumMaster who can introduce small but significant changes to the process. And it includes organizational change agents working to introduce or spread Scrum.

In the following sections, we’ll look at how these leaders, managers, and change agents can influence the self-organizing path of a team or company. You’ll learn about three conditions that must exist for self-organization to occur and how leaders can alter those conditions. We’ll also learn how organizations evolve and we’ll encounter seven ways that leaders, managers, and change agents can exert influence on the evolution of their organizations.

Influencing Self-Organization

Self-organization is a fundamental concept in agile software development. The Agile Manifesto includes the principle, “The best architectures, requirements, and designs emerge from self-organizing teams.” Yet a common misconception is that because of this reliance on self-organizing teams, there is little or no role for leaders of agile teams. Nothing could be further from the truth. In The Biology of Business, Philip Anderson writes,

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is. (1999, 120)

Self-organization does not mean a team is left free from management control or influence. For example, a team that is told to build a word processor is still self-organizing even if team members would rather build an eCommerce web site. So is a team that is told, "Asa will be moving onto your project next week.” The key here is that “self-organizing” does not mean “free from all management control.”

Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986,Takeuchi and Nonaka wrote, “Subtle control is also consistent with the self-organizing character of project teams.” Then in Wicked Problems, Righteous Solutions in 1990, DeGrace and Stahl wrote,

To be sure, control is still exercised; but, it is subtle and much of it is indirect. It is exercised by selecting the right people, creating an open work environment, encouraging feedback from the field, establishing an evaluation and reward system based on group performance, managing the tendency for going off in many directions early on and the need to integrate information and effort later on, tolerating and even anticipating mistakes, and encouraging suppliers to become involved early without controlling them.

A team’s job is to self-organize around the problem and within the boundaries and constraints put in place by management. When a new challenge is presented to a team, the team members figure out how to organize themselves and their work in response to that challenge. Jeffrey Goldstein, author of The Unshackled Organization, points out that (1994, 38),“Self-organization is the system’s response to a challenge or new condition.” Management’s job is coming up with appropriate challenges and removing impediments to self-organization.

The fewer constraints or controls put on a team, the better. If leadership overly constrains how a team solves the problem given to them, self-organization will not occur. The team will shut down; since they’ve been told so much about the problem and how to solve it, they will wait to hear the rest. With that in mind, it is important for leaders and change agents to carefully select how they will constrain the team. Fortunately, the nature of self-organization itself provides clues in making these decisions.

Containers, Differences, and Exchanges

In her doctoral dissertation, Glenda Eoyang (2001) describes three conditions that influence how a team will self-organize. By altering these factors, leaders and change agents can influence how teams self-organize. The three factors Eoyang identified are: a container, significant differences, and transforming exchanges.

A container is some boundary within which self-organization may occur. Imagine you are at a movie theater with a friend. The physical boundaries of the theater form a container within which you and other filmgoers self-organize into seats. Another set of filmgoers are in the adjacent theater, and they have self-organized within their physical container. The two containers (theaters) are distinct so filmgoers in one theater cannot be said to have self-organized with filmgoers in the other theater. Containers do not need to be physical, as the following examples illustrate:

• Everyone working on the San Jose campus.
• Everyone working in Building A-3.
• Everyone working in the software development department.
• Everyone programming in Ruby.
• Everyone who is Norwegian.
• Everyone who belongs to the Agile Alliance.
• Everyone on the Capricorn project team.

Also influencing how a group self-organizes are the differences among individuals. Without differences, it won’t matter who does work and there will be no need for individuals to interact. Since we’re all equivalently skilled in all ways, each member of the group will work in isolation. Fortunately, there always are differences among the individuals on a software development team. These include technical expertise, domain knowledge, power, gender, race, educations, connections to others in the company, problem-solving approach and so on. The types and degrees of differences will influence how a team self-organizes.

Finally, how a team organizes in response to a challenge will be influenced by the transforming exchanges in which team members are involved. A transforming exchange is an interaction between members of a container in which one or more of the individuals is changed or influenced by that interaction. For example, I meet with my project’s product owner who answers some questions about how a feature should work. This is a transforming exchange because I leave with new knowledge. It is not always information that passes between individuals in a transforming exchange; it might be money, power, energy, or any number of other things. A team motivated by a conversation with their product owner has experienced a transforming exchange: energy was created and passed to the team.

Leaders and change agents can adjust containers, amplify or dampen differences, and alter exchanges to exert influence over how a team or teams self-organize. This is one form of the “subtle control” mentioned at the start of this chapter. For example, suppose one team member, Jeff, is very domineering and no one is willing to stand up to him. This team has self-organized—they’ve chosen to let Jeff make all key decisions. As the ScrumMaster for this team, you recognize that this will impede the team’s efforts to improve. You can have a private conversation with Jeff, but that is unlikely to change much. If you step in and overrule some decisions he makes, the team will expect you to continue to do so, which won’t be good.

Alternatively, you can think about the containers, differences and exchanges that are influencing how this team has chosen to self organize. Doing so, you may discover that you can influence the situation by decreasing the differences among team members by adding someone else who will sometimes stand up to Jeff. Or you may decide to alter the exchanges by suggesting to the enterprise architecture team that someone from their group attend key meetings.

In Facilitating Organization Change, Eoyang and coauthor Edwin Olson advocate exactly this type of approach, saying:

The role of the change agent is to use an understanding of the evolving patterns to shift the container, differences, or exchanges to affect the self-organizing path, to observe how the system responds, and to design the next intervention. The objective of this action-oriented experimentation is to anticipate, adapt, and influence, not to predict or control the behavior of the system. (Olson and Eoyang 2001, 16)

Adjusting Containers

Colin, a development director at a medical software company, was frustrated by one team’s inability to produce working software by the end of its sprints. His disappointment wasn’t at the amount of work being done each sprint; the team seemed to be doing a reasonable amount of work each time. He was frustrated because rather than finishing five items by the end of a sprint, the team would instead be “half done” with ten. He knew this wasn’t how a Scrum team should behave.

Colin and I discussed the situation and I presented the CDE (Container, Difference, Exchange) model. Colin felt that the right people were talking and that he didn’t need to change the current exchanges or introduce new ones.We discussed Differences among team members and agreed that one possible remedy was to move an experienced agile developer onto the team. Such a developer would be able to help the team understand the problems with how they were working. Unfortunately there were no experienced agile developers available for this team.

In discussing the Containers that enclosed this team, Colin realized that a possible solution was to expand the team’s responsibilities. Contributing to their challenges in finishing work, he decided, that this team was dependent on low-level functionality being developed by another team. Colin decided to merge the two teams. By merging them, he could make the combined team entirely responsible for work that used to span two teams.This would eliminate one opportunity for excuses about why something wasn’t finished by the end of a sprint. Colin describes it this way,

Only part of their problems were caused by delays waiting for the other team. But they’d become accustomed to leaving product backlog items half finished. By adding responsibilities and new members to the team, it would be a chance for me to re-stress my expectation that having a few things done at the end of a sprint was better than having more things started.

Colin’s approach of expanding the responsibilities to expand the container is just one possible way of adjusting containers to influence the team. It and some others are summarized in Table 12.1.

TABLE 12.1
Ways to use containers to influence how a team self-organizes.

Things to Try Now

• List all of the containers that members of a team work within. Do the containers seem appropriately sized and scoped? Are there too many? too few?
• For each container, decide if it has a positive, negative, or neutral impact on the team’s performance.
• Identify the container that you think currently exerts the most influence on the team. Should changes be made to that container?

Amplifying or Dampening Differences

Carey, a development director who initiated her company’s adoption of Scrum, was troubled by a recent but sustained drop in velocity on one of her teams. The quality of their work remained high but the team was getting less done now than they were a few months ago. During regular, thirty-minute, one-on-one meetings she had with each of her employees, she asked some members of this team why they thought this had happened. She followed that up by attending the team’s next sprint retrospective.

What Carey learned was that the team had made a few ill-considered architectural decisions six to nine months back. She put together what she learned from the retrospective, her monthly team member meetings, and what she already knew of team member personalities. Carey concluded that while some bad decisions are inevitable, some of this team’s bad decisions were the result of team members not adequately questioning one another.

I had previously introduced Carey to thinking about Containers, Differences, and Exchanges as a light-touch way for her to guide her teams. She told me later that she had used the approach in this situation. By thinking through the CDE model, Carey knew that insufficient differences existed between team members. She decided that she could best help this team by amplifying those differences. She did so through one of my favorite techniques: She asked a lot of probing questions.

Carey had always been a hands-on director but she decided this team needed more of her attention. She began to drop by when she saw them holding impromptu meetings. She made a point of attending most of their sprint planning meetings. During these meetings she asked questions intended to pull out dissenting opinions. Carey asked questions like:

• What alternative approaches have you considered and rejected before accepting this one?
• What could go wrong with this approach?
• What has to go right for this approach to work?
• What could make us regret this decision?
• Is there any information we don’t have that would help us be sure of this?

Even when Carey agreed with the prevailing opinion, she asked hard questions, poking for flaws and hoping others might voice even better opinions.

Another good way to amplify differences is to change how the team makes decisions. For example, if a team currently makes decision by a majority vote, ask them to require consensus for the next two sprints. Do the opposite if they currently require consensus. These and other approaches for dampening or amplifying differences are shown in Table 12.2.

TABLE 12.2
Ways to amplify or dampen differences to influence how a team self-organizes.

Things to Try Now

• For each way in which team members differ (such as technical knowledge, domain knowledge, industry experience, tenure with the company, respect, problem-solving style) rate the differences from one to ten. From this, do team members appear too differ-ent? too similar?
• Identify one difference that would improve team performance if it could be amplified. Could someone be added to the team who would amplify that difference?
• Identify one difference that would improve team performance if it could be dampened. Could someone be removed from the team who would dampen that difference?

Altering Exchanges

A leader or change agent in the organization can also influence a team by altering the exchanges in which team members participate. Alejandro, a technical lead at a video game development studio, was attending his third sprint review of the day when he noticed the problem. Each team included an artificial intelligence (AI) programmer. The AI programmers were responsible for the behavior of the bad guys who would attack the player in the game. Alejandro picked up on statements in the sprint reviews that told him each team was programming its AI a bit differently. Not only would this lead to inconsistent game play, it was also a duplication of some of the effort.

I met Alejandro after he had encountered and solved this problem. His solution was to introduce a new exchange. Since the AI programmers were not talking to each other often enough, Alejandro decided the AI programmers should meet once a week with no one else present. Although not one of the AI programmers, Alejandro had enough personal authority in the organization that he was able to convince them this was a good idea. During a two-week sprint, AI programmers met on the day after sprint planning so that each would be aware of what the others had committed to and would be working on. A second meeting was held around the start of the second week, giving them a chance to compare progress and expectations.

Alejandro introduced a community of practice, a group of like-minded or like-skilled individuals. We saw the use of communities of practice in CHAPTER TWO as the basis for the organization’s Enterprise Transition Community and the improvement communities that help the organization adopt Scrum. We will see them in more detail in Chapter 17,“Scaling Scrum.” In addition to introducing a community of practice, additional techniques for altering exchanges are shown in Table 12.3.

TABLE 12.3
Ways to use alter exchanges to influence how a team self-organizes.

Now that we’ve looked at three factors that influence how a team self-organizes around the challenge it is given, let’s look at ways to keep the team or company evolving over time.

Things to Try Now

• Who outside the team do you wish the team would talk to more often? Is there a way to encourage such exchanges?
• Diagram the intensity of interaction among team members. Draw a circle for each person. Then draw lines between pairs of team members who interact. Use color or thickness to indicate intensity or frequency. Do you see any problems?
• Observe the team carefully for a sprint: Are the right people involved in all exchanges? Should some exchanges involve more (or fewer) people?