11. Symptoms and Causes

We’re trying to rebuild society,
not plunge it back into chaos.

—Andrew Cormier, Shamblers: The Zombie Apocalypse

In This Chapter

• Learn what self-organization looks like and how self-managed teams make it possible.

• Explore the most common symptoms and causes of poor self-organization.

• Discover what self-organization and self-management look like in healthy Scrum Teams.

Experience from the Field

“Let’s start our Scrum Journey!” exclaimed Jeff, CEO of Widget Inc., at the start of the annual corporate retreat. It was an important strategic move for the company. In recent years, Widget Inc. experienced an increase in the number of competitors in their field. Jeff had been reading a lot about how Scrum could help the company compete, and it had been recommended to him by several of his peers.

A few weeks later, the agile transition started in earnest. Together with a team of external Scrum consultants, Jeff worked behind the scenes to get everything in order. One of the first challenges was forming Scrum Teams. As it turned out, dismantling the current departments for testing, coding, and design to form cross-functional teams would be too much of a hassle. To complete the transition sooner, Jeff tasked his department heads to create Scrum Teams within their departments: three for development, one for design, and two for testing. The department heads would also act as the Product Owners for their teams. The new role of Scrum Master was assigned to people who weren’t fully planned in yet. Another big challenge was to get everyone trained and certified quickly. Thankfully the external consultants provided certified training. They also offered to train each Scrum Team in common best practices, such as writing User Stories, Planning Poker, using a Definition of Ready, and something with LEGO. With that arranged, Jeff relaxed in the realization that it was now up to the Scrum Teams to take responsibility and control.

A cry for help reached us six months later. We entered an organization in disarray. In contrast to what Jeff had hoped for, there was an atmosphere of cynicism and low morale. The teams complained about management, other teams, and the consultants. It was impossible for them to get anything done within a single Sprint, as they depended on other teams to do work for them. They had proposed reforming the Scrum Teams with cross-functional skills, but the department heads resisted. In turn, the department heads and Jeff each complained about the lack of commitment from teams. They’d made a huge effort to get the teams started, only to see that effort go to waste. Instead of the self-organization they were promised, all they got were complaints, problems, and cynicism. From now on, they’d take control again. The Scrum Framework had failed.

This case vividly illustrates self-organization, or the complete lack thereof. Self-organization is an important characteristic of the Scrum Framework, but it is remarkably difficult to define, and that causes confusion. People who don’t fully understand how challenging it is to create and sustain self-organization can see it as a remedy for all kinds of organizational ailments. Some people see self-organization as a means for people to choose their own role and define how they do their work. Others see it as a means for people to set their salary and conduct performance appraisals with their peers. Some people even use self-organization as a means to elect a new management team every year, or to make teams responsible for their own profit-and-loss performance, or to give teams full authority over their own composition.

In this chapter, we approach self-organization from the perspective of the Scrum Framework. We also share common symptoms of low levels of self-organization as well as what might be causing them. At the end of this chapter, we give examples of what self-organization looks like in healthy Scrum Teams.

How Bad Is It, Really?

We are continuously monitoring the spread of Zombie Scrum around the world with our online Symptoms Checker at survey.zombiescrum.org. Of the Scrum Teams that have participated at the time of writing:¹

• 67% of the teams have members who only or mostly do work in their specialization.

• 65% of the teams have no or limited say in the composition of the team.

• 49% of the teams never or rarely have a clear goal for their current Sprint.

• 48% of the teams work on multiple projects or products at the same time.

• 42% of the teams have no or limited say in their tooling and infrastructure.

• 37% of the teams have no or limited redundancy in skills on their team to buffer against team members who are suddenly unavailable.

• 19% of the teams have very little say in how to do their work during a Sprint.

¹ The percentages represent teams that scored a 6 or lower on a 10-point scale. Each topic was measured with 10 to 30 questions. The results represent 1,764 teams that participated in the self-reported survey at survey.zombiescrum.org between June 2019 and May 2020.

Why Bother Self-Organizing?

Self-organization is a concept that is central to the Scrum Framework. For all its significance, it is remarkably hard to define. It is often confused with “self-management,” or the idea that teams should make their own decisions. This distinction may seem trivial, but it helps to understand two essential truths about Scrum that we explore in more detail in this chapter. The first is how Scrum uses self-organization to act as a lever to make organizations more agile. The second is how Scrum Teams require a high degree of self-management to make this happen.

What Is Self-Organization?

In different scientific domains, from biology to sociology and from computational sciences to physics, self-organization is the process by which order arises spontaneously from something that is initially disorganized.² This order is the result of self-organization only when it emerges from the interactions of the smallest units of the system and isn’t imposed by outside influences. Self-organization happens all around us and on many different levels. It happens when the wind creates beautiful shapes in the sand. It happens when ants work together to build massive colonies, without a clear intelligence guiding them. And it happens when people effortlessly avoid walking into each other when large crowds intersect.

² Camazine, S., et al. 2001. Self-Organization in Biological Systems. Princeton University Press.

A good example of this phenomenon is when you bring a large group of employees together. Initially there will be chaos, because they don’t know how to work together. Managers can create order by giving instructions. But because this order is imposed, it isn’t self-organization. Alternatively, employees can come to a shared understanding of how to perform and coordinate their work without direction from outside. Although this example uses “employees” as its smallest unit, you can replace them with Scrum Teams for the same effect. There too, rules, structures, and collaborations will form spontaneously when you put fifty teams together. Whether they are also effective is another question though.

The success of self-organization, and whether or not it turns into chaos or useful solutions, depends on two major ingredients. The first is the simple rules the teams follow. And the second is the autonomy they actually have.

Self-Organization through Simple Rules

The first ingredient for successful self-organization is the simplicity and quality of the rules that are followed by the smallest units of a system. A common example is the flock of birds that creates elaborate and complex patterns in the sky called murmuration. For all their beauty, these patterns are the result of a few simple rules that all birds adhere to: they maintain the same speed and stay at a similar distance from a handful of birds close to them.³ As each individual bird follows these simple rules, tiny variations in speed, distance, and direction cause big changes as the flock rapidly elongates, turns, and flips. Without these simple rules, chaos would ensue. Self-organization does not reflect the autonomy of individual birds, but rather how group-level patterns spontaneously emerge when individual members of a group follow a few simple rules.

³ Hemelrijk, C. K., and H. Hildenbrandt. 2015. “Diffusion and Topological Neighbours in Flocks of Starlings: Relating a Model to Empirical Data.” PLoS ONE 10(5): e0126913. Retrieved on May 27, 2020, from https://doi.org/10.1371/journal.pone.0126913.

The Scrum Framework purposefully defines one essential rule for Scrum Teams to follow: Deliver a “Done” Increment every Sprint that achieves the Sprint Goal. This Increment is the primary driver of transparency, inspection, and adaptation. It gives purpose to all the structural elements that make up the Scrum Framework: its roles, artifacts, and events. Although following this rule is certainly not as simple as maintaining the same speed and distance from the birds around you, maintaining it will cause systemwide changes.

The people who build the product—the Scrum Teams—will discover things that get in their way of releasing a Done Increment every Sprint. They may discover that they lack skills or depend on people outside the team to do work for them. Or a lack of mandate makes it hard for Product Owners to define a clear Sprint Goal. As Scrum Teams identify and remove impediments, it becomes progressively easier to conform to the single rule. This enables them to improve their way of working more quickly in response to the increasing amount of feedback they are getting on their work, and the speed at which they are obtaining this feedback. In other words, they are becoming increasingly flexible and agile to their environment. The Scrum Framework acts as a lever for system-level change by having Scrum Teams focus on releasing a Done Increment every Sprint.

Unfortunately, teams that suffer from Zombie Scrum are either unwilling or unable to follow this single rule. Here, the lever doesn’t work, and self-organization doesn’t happen, or not in a direction that matters to agility.

Self-Organization through Self-Management

The second ingredient for successful self-organization lies in the autonomy that people and teams have to determine their own rules. One way to think about this is to consider the work that a team does as a river. An impediment or challenge may appear in the form of a rock that is put in its path. The more constrained the river is, the fewer options there are to flow around the rock. Increased autonomy gives teams the ability to allow their work to flow around rocks that get in their way. Organizational scientists often describe this as “self-management.” In this philosophy on management, teams are responsible for a complete product, an isolated part of a product, or a particular service.⁴ Instead of having a manager who decides for them, or having to adhere to strict policies and protocols, teams have a degree of autonomy in areas such as the following:⁵

• How new members of a team are selected and recruited

• How teams and its members are rewarded and evaluated

• How teams create a safe and collaborative environment

• How teams are trained in important skills, and by whom

• How teams spend their time

• How teams synchronize their work with other teams, departments, and units

• How teams set goals

• What facilities and tools teams need to do their work

• How decisions are made on the team

• How teams distribute their work

• Which methods, practices, and techniques teams use

⁴ Hackman, J. R. 1995. “Self-Management/Self-Managed Teams.” In N. Nicholson, Encyclopedic Dictionary of Organizational Behavior. Oxford, UK: Blackwell.

⁵ Cummings, T. G., and C. Worley. 2009. Organization Development and Change, 9th ed. Cengage Learning.

For each of these areas, the autonomy of a team ends up somewhere between “no autonomy at all” and “full autonomy.”

The concept of self-managed teams might seem novel, but it has been around for a long time. Self-management is an important part of the sociotechnical systems (or STS) approach that was developed by the Tavistock Institute of Human Relations during the Second World War.⁶ As a result of this work, self-managed teams started appearing everywhere, including in many car manufacturing plants.⁷ Instead of the traditional assembly-line manufacturing that had previously prevailed, teams took responsibility for the completion of entire subsystems of a car (the brakes, electronics, and so on). Teams were also responsible for their own planning, scheduling, task allocation, recruitment, and training—without involvement from management. The extensive research that has been done on sociotechnical systems over the years shows a huge boost in job satisfaction, motivation, productivity, and quality.⁸ The Toyota Production System (or TPS) that would later inspire the Scrum Framework and Lean methodology is an example of such a sociotechnical system.

⁶ Hackman, J. R., and G. R. Oldham. 1980. Work Redesign. Reading, Mass: Addison-Wesley.

⁷ Rollinson, D., and A. Broadfield. 2002. Organisational Behaviour and Analysis. Harlow, UK: Prentice Hall.

⁸ Bailey, J. 1983. Job Design and Work Organization. London: Prentice Hall.

Although the Scrum Guide defines Scrum Teams as being “self-organizing,” it means them to be “self-managing” in order for the process of “self-organization” to happen. Scrum Teams have all the roles and responsibilities needed to make decisions about their product and how to do their work. In reality most Scrum Teams are severely limited in their ability to self-manage, however. In an attempt to reduce the potential chaos and disorder that they expect will happen when teams self-manage, many organizations tightly control how teams do their work instead. They either don’t understand the mechanisms of self-organization or don’t trust the outcomes—with Zombie Scrum as a result.

Self-Organization Is a Survival Skill in a Complex World

Complex environments are characterized by high degrees of unpredictability and uncertainty. This makes them volatile and rife with risk. Markets shift in the blink of an eye, new technologies achieve widespread popularity seemingly overnight, and as they do they may be found to harbor security vulnerabilities that need to be fixed immediately. New competitors enter the market with a superior product, undermining seemingly unassailable market positions. And then there are global catastrophes, such as the financial crisis of 2008 and COVID-19 in 2020, that upend economies overnight and take companies entirely by surprise. As our world becomes increasingly globalized and interconnected, so does the chance of unpredictable and highly impactful events that demand immediate adaptation. The statistician Nassim Taleb calls these events “Black Swans.”⁹

⁹ Taleb, N. N. 2010. The Black Swan: The Impact of the Highly Improbable, 2nd ed. London: Penguin. ISBN: 978-0141034591.

Taleb goes on to describe how organizations often optimize for what he calls “robustness.”¹⁰ In an effort to reduce volatility, they rely on standardization and centralized coordination to reduce harmful variation both within and outside the organization. For example, all teams have to use the same technologies or follow the same procedures when solving specific problems. Or they create centralized steering committees to guide multiteam product development. By adopting rigid standards and coordination structures, organizations are able to limit the impact of variation when the changes are small. But in a world that is increasingly volatile, this rigidity prevents them from adapting to change, and can even break them entirely.

¹⁰ Taleb, N. N. 2012. Antifragile: Things That Gain from Disorder. Random House. ISBN: 978-1400067824.

Another way is to optimize for “antifragility.” Instead of trying to resist variation and shocks, antifragile systems grow stronger when they are pressured. For example, engineering teams at Netflix created a tool called “Chaos Monkey”¹¹ to randomly terminate services in their infrastructure. Every time a terminated service ends up causing disruptions to end users, engineering teams redesign the architecture to reduce the impact. Over time, responding to these kinds of random shocks helped Netflix make its infrastructure more resilient.

¹¹ Izrailevsky, Y., and A. Tseitlin. 2011. “The Netflix Simian Army.” The Netflix Tech Blog. Retrieved on May 27, 2020, from https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116.

Space Exploration Technologies (or SpaceX) has a launch cadence that is purposefully higher than that of other launch providers.¹² Every time a launch fails, their self-managed teams update technology, protocols, and processes to avoid similar failures in the future. Other organizations, including Procter & Gamble, Facebook, and Toyota, run many small experiments at the same time to explore different alternatives. Although most experiments fail, some strike gold. More important, their self-managed teams learn from failures and grow stronger because of them.

¹² Morrisong, A., and B. Parker. 2013. PWC, Technology Forecast: A Quarterly Journal 2.

Three threads are apparent in antifragile organizations:

1. They rely on self-managed teams to self-organize around problems as they appear (see Figure 11.1).

Figure 11.1 Like an organizational immune system, self-managing teams can quickly self-organize around challenges and opportunities as they emerge.

2. They encourage experimentation to grow stronger through failures.

3. They spend effort to learn from failure through single- and double-loop learning (see Chapter 9).

Taken together, organizations develop the skills, technologies, and practices to not only survive the uncertainty of complexity but actually thrive on it, because they can adapt faster than others. Unfortunately, and as we explore later in this chapter, the variation and redundancy that is necessary for antifragility is often seen as inefficient and wasteful by organizations where Zombie Scrum is flourishing.

The concept of antifragility ties together much of what we’re writing about in this book. The Scrum Framework actively promotes it. It relies on self-managed teams to self-organize around challenges that get in their way. By following the single rule of releasing a Done Increment every Sprint, everything that makes it hard for teams to do so becomes apparent, including many of the factors that optimize for robustness, but not antifragility, such as rigid control structures, lack of mandates, long feedback loops, and highly specialized (but not distributed) skills. By releasing a Done Increment every Sprint, teams effectively introduce more opportunities for success and failure, giving them opportunities to reflect on their results and learn. When enough teams in an organization do this, the whole system becomes increasingly antifragile.

The Bottom Line

In his novel Seveneves, author Neil Stephenson¹³ describes a catastrophic event where a dense field of debris suddenly appears around the Earth and is about to rain down and eradicate all life. In an effort to save humanity, engineers start building a space station for a few thousand souls that can continue to orbit the Earth until it becomes habitable again. Instead of building one giant station, the engineers instead design a massive swarm of smaller and autonomous stations that can connect and disconnect as needed. With all the debris still orbiting the Earth—even a tiny grain of debris would have a catastrophic result—a single station would be too dangerous. Although each unit in the swarm is still susceptible to disaster, their smaller size makes it easier to avoid incoming debris. Furthermore, the loss of individual units doesn’t immediately threaten the survival of the swarm as a whole. The swarm can now self-organize around impending disaster more effectively than a single space station can.

¹³ Stephenson, N. 2015. Seveneves. The Borough Press. ISBN: 0062190377.

This is a great metaphor for what the Scrum Framework tries to achieve. It aims to break down traditional structures where work is standardized and tightly controlled through centralized management in order to avoid risk and variation. Like the large space station in the metaphor, these structures work well in stable environments. But our world is increasingly complex, and increasingly filled with unexpected debris that may cause havoc. Instead, the Scrum Framework enables antifragility by making self-managing Scrum Teams the metaphorical swarm from this story. As a self-managed team, every Scrum Team adds variability and thereby survivability.

Why Are We Not Self-Organizing?

If self-organization is so important, why doesn’t it happen in Zombie Scrum? Next, we explore common observations and their underlying causes. When you are aware of the causes, it is easier to select the right interventions and experiments. It also builds empathy with Zombie Scrum, and how it often emerges despite everyone’s best intentions.

Well recruit, now you see how important self-organization is. It may sound fluffy, but it’s your best survival strategy.”

In Zombie Scrum, We Are Not Self-Managing Enough

As we explored earlier in this chapter, it is difficult for Scrum Teams to self-organize around shared challenges if their ability to self-manage their work is limited. In organizations that suffer from Zombie Scrum, most or all of the areas tilt towards “no autonomy at all.” Instead of being able to make decisions about their own work, when, and by whom it should be done, Zombie Scrum Teams have others who make those decisions for them, they need to get approval first, or they are required to adhere to existing standards or “the way we do things here.”

Signs to look for:

• Scrum Teams have no role in deciding who is part of their team. Such decisions are made either by external managers or by a human resources department.

• Scrum Teams cannot change their tools or work environment to suit their needs.

• Product Owners have limited mandate over “their” product. Either they are not allowed to make decisions or they frequently have to ask for permission.

• There is a lot of negative gossip about, and blaming of, other teams, departments, or people that a Scrum Team depends on. And vice versa.

• People respond with cynicism to the purpose of their work and the product they are developing together. Team morale is low.¹⁴

¹⁴ A free tool to measure team morale is available at teammetrics.theliberators.com.

Self-management works in environments where the professionals doing the work are trusted for their ability to make the right decisions. Unfortunately, organizations infected by Zombie Scrum often don’t demonstrate that trust. When it comes to self-management, this lack of trust shows in the use of external experts to design how work is to be done, instead of letting the professionals figure that out themselves. And it shows when Product Owners have to go through long approval chains before they can release to production. In subtle and not-so-subtle ways, professionals are not trusted to use their autonomy in a way that is careful, considerate, and in the interest of the organization.

This lack of trust fuels a vicious cycle of finger-pointing, where Scrum Teams complain that management is not giving them enough space to move, while management in turn complains about Scrum Teams not taking responsibility. The low morale and cynicism that management senses in teams are usually a response to a perceived lack of control. When people feel that their ability to do their work well is limited by others, they have different strategies for dealing with the resulting tension. Complaining about or blaming others is a good example of such a strategy. It allows people to relieve tension by offloading their frustrations on others and feeling less responsible themselves. Another strategy is to withdraw from collective commitments, as captured by low team morale, or “the enthusiasm and persistence with which people do work as part of a team.”¹⁵

¹⁵ Manning, F. J. 1991. “Morale, Unit Cohesion, and Esprit de Corps.” In R. Gal and A. D. Mangelsdorff, eds., Handbook of Military Psychology, pp. 453–470. New York: Wiley.

Self-management and trust require and reinforce each other. It’s not an easy transition, and teams will make mistakes, some worse than others. But if people don’t have the freedom to make those mistakes, they will never learn, and they will never commit themselves to achieving their goals. There will always be “bad actors” who actively sabotage the company or pursue self-interests to the detriment of others. But instead of enacting rigid hierarchies and policies to prevent mistakes and sabotage, it is more helpful to limit the blast radius of mistakes. It is better to support a process by which teams feel the consequences of their mistakes and then learn to avoid them in the future.

The point of self-management is not to remove all the rules or to allow teams to do whatever they want. The point is to empower teams in designing and shaping how their work is done, while also becoming accountable for those decisions. A part of this process happens inside teams; another part happens as teams work together to clarify their dynamics. This is when self-organization emerges.

Try these experiments to improve with your team (see Chapter 12):

• Find a Minimum Set of Rules for Self-Organization

• Make the Cost of Low Autonomy Transparent with Permission Tokens

• Break the Rules!

• Observe What Is Happening

• Find Actions That Boost Both Integration and Autonomy

In Zombie Scrum, We Use Off-the-Shelf Solutions

Organizations that suffer from Zombie Scrum like to follow standardized methods, well-defined frameworks, and “industry best practices.” To them, this preference feels more efficient than developing their own approaches. They believe that they are learning from the experiences of others, as in the case when organizations implement the “Spotify Model” in the hope of replicating Spotify’s top-notch engineering culture. But there are three big problems with “copying” from others:

• Copying what works for one organization to another completely ignores the unique circumstances that enabled the solution to work for the original organization. For example, Spotify has a completely different culture and environment from the banks and insurance companies that try to copy its “model.” What works for Spotify may be completely unsuited to other organizations.

• The very nature of complex systems means that there are no “models” or “best practices.” Organizations such as Spotify are in a constant state of flux as double-loop learning and self-organization continuously reshape how people work together. Although you can take a snapshot of what Spotify looks like at a given moment and copy its roles, structure, and rules to your own organization, the actual model at work here is not its structure but its focus on learning and self-organization. In fact, Spotify went out of its way to show that their structure always changes and shouldn’t be copied.¹⁶

¹⁶ Floryan, M. 2016. “There Is No Spotify Model.” Presented at Spark the Change conference. Retrieved on May 27, 2020, from https://www.infoq.com/presentations/spotify-culture-stc/.

• Copying “best practices” from other organizations effectively sidesteps the double-loop learning and self-organization that gave rise to those recipes in the first place. By simply copying the (supposed) result, organizations never develop the ability to learn that is essential to solving complex challenges. Copying actually impedes self-organization and double-loop learning as predefined solutions from elsewhere are rolled out across the organization (see Figure 11.2).

Figure 11.2 But it feels so convenient to have a one-stop shop with precooked solutions.

The example of Spotify is an obvious one, but the same argument applies to other attempts to copy best practices from elsewhere. It also applies to scaling frameworks that emphasize a particular structural solution for scaling over double-loop learning and self-organization.

Signs to look for:

• People say things such as “Let’s not reinvent the wheel.”

• External experts are hired to implement their best practices or “roll out” change initiatives that were planned without concerted involvement of employees.

• Approaches that worked for other organizations are copied onto the entire organization without trying them in one small area first.

• You don’t get a clear answer when you ask people what problem they are trying to solve with an external framework or solution (e.g., SAFe, LeSS, or the Spotify model).

You can certainly find inspiration in solutions from other organizations. But instead of jumping straight to replicating their recipes, it’s more helpful to create environments where people can learn and fail. Don’t copy the plant, copy the soil it grew from. Create environments where people are encouraged to explore why a problem exists, where they have autonomy over their work, and where they can experiment with different approaches. This is where double-loop learning starts and when all sorts of wildly creative solutions start emerging from self-organization.

Try these experiments to improve with your team (see Chapter 12):

• Find a Minimum Set of Rules for Self-Organization

• Develop Local Solutions with Open Spaces

• Find Actions That Boost Both Integration and Autonomy

In Zombie Scrum, Scrum Masters Keep Resolving All Impediments

The Scrum Master is responsible for helping Development Teams resolve impediments. When they are sufficiently self-managing, Development Teams should increasingly be able to resolve impediments on their own as they become more experienced. In Zombie Scrum, this doesn’t happen, and Scrum Masters remain busy with the same kinds of impediments. These teams have become dependent on their Scrum Masters to fix all the problems that get in their way. And their Scrum Masters have contributed to the problem, either by actively offering to solve impediments or by accepting all requests from the Development Team to do so. Although they have done this with the best intentions, Scrum Masters are not helping their teams to build the skills to do so on their own.

Signs to look for:

• During Sprint Retrospectives, the Scrum Team looks to the Scrum Master to resolve most of the challenges identified.

• Scrum Masters routinely perform tasks such as renewing certain software licenses, updating Jira, getting office supplies for the team, or booking meeting rooms.

• Scrum Masters are always facilitating the Scrum Events.

• When the Development Team runs into dependencies on others—including the Product Owner—the Scrum Master usually resolves them.

Scrum Masters who believe that resolving problems is their responsibility are causing more problems than they are solving. Not all problems are automatically impediments. We like to define impediments as those challenges that (1) block Development Teams from (2) achieving the Sprint Goal and (3) exceed their capability to resolve on their own. Typically, the kind of impediments where help from Scrum Masters is needed should evolve over time (see Figure 11.3). Initially, their efforts focus on helping Scrum Teams and the organization understand the purpose of the Scrum Framework: Why is it important to release a Done Increment every Sprint? How do Sprint Goals help teams become more effective in complex environments? And how do the various events, roles, and artifacts of Scrum allow teams to work empirically?

Figure 11.3 The Impediment Pyramid by Dominik Maximini¹⁷

¹⁷ Source: Maximini, D. 2018. “The Pyramid of Impediments.” Scrum.org.

As their understanding of Scrum grows, teams may need help changing their composition—they may need different skills or people—to be able to work more empirically. They may also discover that bringing these skills together in one team requires a different way of working and different engineering practices to benefit from them (e.g., automated testing, Lean UX, emergent architecture, continuous deployment).

As Scrum Teams become more capable of working empirically within their team, they may run into broader impediments that involve other departments and teams. For example, HR practices may reward individual contributions over working together as a team. Or Scrum Teams may struggle to synchronize their work with other Scrum Teams. Or the sales department continues to sell fixed-price/fixed-scope projects. Finally, impediments may involve the way work is organized in the organization as a whole, such as when yearly product strategy definitions no longer remain relevant as market conditions change, or when management struggles with how best to support self-managing Scrum Teams.

Although Scrum Masters likely face impediments of all kinds from the start, a first priority is to get the Scrum Teams—and the empirical process—started. Once these “engines of empiricism” are running, they create transparency around other kinds of impediments that need to be resolved. Over time, the pyramid should flip as Scrum Masters shift most of their efforts to broader, organization-level impediments. But in Zombie Scrum, Scrum Teams remain stuck in the lower parts of the pyramid.

Try these experiments to improve with your team (see Chapter 12):

• Observe What Is Happening

• Express Clear Requests for Help

• Find a Minimum Set of Rules for Self-Organization

In Zombie Scrum, Scrum Masters Focus Only on Scrum Team(s)

When Scrum Teams follow the single rule of releasing a Done Increment every Sprint, they are bound to run into many impediments that get in the way of working empirically. Although some of these obstacles are constrained to individual Scrum Teams, most of them involve other teams, departments, and suppliers.

Because of this reality, Scrum Masters are in a perfect position to help their organization work more empirically. They see on a daily basis what impedes Scrum Teams and where they need to improve. Working together with other Scrum Masters, Product Owners, Development Teams, and stakeholders, they guide the organization towards increased empiricism and agility by influencing it from the inside out.

Unfortunately, organizations with Zombie Scrum don’t leverage this potential of Scrum Masters to change their organization. Sometimes Scrum Masters misunderstand their role and focus only on their teams. Other times, Scrum Masters are expected to be team-focused and leave larger impediments to other people or external experts.

Signs to look for:

• Scrum Masters don’t spend time with other Scrum Masters to overcome impediments shared by their teams.

• The job description of Scrum Masters specifically emphasizes their responsibility for their teams, and nothing beyond that.

• Agile Coaches and Enterprise Coaches are responsible for supporting the environment around the Scrum Teams.

• Scrum Masters don’t coordinate their work on impediments with management.

But how can Scrum Masters change entire organizations? They probably can’t on their own, and that is why they work with other Scrum Masters, as well as with natural allies such as Product Owners, Development Teams, and stakeholders. They distribute time between working with their team and working with others to encourage self-organization across teams. And since no two Scrum Masters are the same, some will spend more time working across teams or with management, while others are more content working with their own team. Like a cross-functional team, the community of Scrum Masters within an organization needs to have the skills to drive change both on the level of individual teams as well as on an organizational level. And more-experienced Scrum Masters can train and help less-experienced ones.

How Scrum Masters drive change across the organization depends on the situation. It can take the shape of sense-making workshops where (representatives of) teams make sense of important metrics and devise strategies to improve. It can take the shape of visits to other companies to see how they use Scrum there. Scrum Masters can also purposefully create transparency around a critical issue (such as low cycle time or low code quality) and invite teams to inspect and adapt.

Whatever the case, when organizations invest more in hiring experienced Scrum Masters and growing the skills of their internal Scrum Master community, their need for external experts and other coaches will diminish.

Try these experiments to improve with your team (see Chapter 12):

• Observe What Is Happening

• Organize Scrum Master Impediment Gatherings

• Find Actions That Boost Both Integration and Autonomy

• Develop Local Solutions with Open Spaces

In Zombie Scrum, We Have No Goals or They Are Imposed

Provided they have sufficient autonomy, teams and people go in many different directions when there are no clear goals to direct self-organization. This is what often happens in Zombie Scrum, and it can be a huge source of frustration to everyone involved.

Signs to look for:

• There is no clear goal during a Sprint that helps teams align their work, both within the teams and between teams.

• If there is a Sprint Goal, the team is unable to explain in certain terms how stakeholders benefit from achieving this goal.

• People mostly work on their own items from the Sprint Backlog. When problems arise in that work, they resolve them mostly without help from others.

• Scrum Teams are not aware of what other Scrum Teams are doing, even when their work is for the same product.

One of the primary challenges that all organizations face is that of alignment. In traditional management, a core task of managers is to ensure that work done by their teams, departments, and employees aligns with plans, objectives, and strategies set out for the organization. For example, when multiple teams work on one product, managers can use weekly status-update reports or meetings to know what is happening and to decide what to start and stop. Or a manager asks a team to work on something else that has become more important. This appears to be efficient, but it also turns managers into bottlenecks. A manager may not have up-to-date information about what is happening in the field, or problems that are experienced by users, or potential business opportunities that teams are seeing. This makes it harder for them, and the organization as a whole, to respond to sudden changes in their environment. Also, making managers responsible for alignment means that their creativity, intelligence, and experience determine how successful that alignment is.

Self-managed teams use a different mechanism to align work and drive self-organization within and across teams. Instead of dedicated roles (managers) or standardized structures (hierarchies and policies), they self-align through compelling goals and an inspiring purpose.

Shared goals act as guide rails to self-organization. To facilitate rapid decision-making and making use of the knowledge of the people doing the work, product-related goals should be set by the Scrum Teams themselves. Sprint Goals are a good example of this. When Scrum Teams set a clear and valuable goal for their current Sprint, it helps them make decisions about what on their Sprint Backlog matters the most to achieving that goal. When a member discovers that something is impeding the goal, this gives the team a good opportunity to step back and reflect on how best to move forward and how to adapt their Sprint Backlog. Aside from Sprint Goals, Scrum Teams should be able to set technical goals together. Or improvement goals. Product strategy, and intermediate product goals, should be set by the Product Owner in coordination with stakeholders. Together, this maximizes the ability of Scrum Teams to respond quickly to changes that impact their product and to maximize the value of their work.

High-level goals, such as business objectives and strategic goals, are probably set by others (e.g., management). But even there, involving everyone in creating those goals builds support for them and allows the inclusion of more perspectives. It also makes it easier for people to self-organize in the desired direction when they understand why the goals are there.

Try these experiments to improve with your team (see Chapter 12):

• Create Better Sprint Goals with Powerful Questions

• Find a Minimum Set of Rules for Self-Organization

• Find Actions That Boost Both Integration and Autonomy

In Zombie Scrum, We Don’t Use the Environment As External Memory

Self-organization becomes progressively easier when teams use their environment as external memory. Scrum Teams that work in environments with Zombie Scrum often can’t do this well. This prevents an important type of self-organization, “stigmergy.”

Signs to look for:

• Scrum Teams don’t have a physical Scrum Board. Instead, organizational guidelines require all teams to use the same digital tool.

• Teams are not allowed to put informative posters on the walls. The “clean-desk policy” also applies to the walls.

• Communication between team members occurs primarily digitally via Slack, email, and so on. There are no physical information radiators to gather around and start a conversation about.

Stigmergy was first discovered by the biologist Pierre-Paul Grassé in termite colonies.¹⁸ Although termites don’t possess individual intelligence, they construct huge and complex nests together. This happens as termites create balls of mud infused with pheromones and initially leave them in random locations. Other termites deposit similar mud balls where they smell the pheromones, causing mud balls to cluster in the same location over time. As the piles grow, they become increasingly attractive to other termites in a form of positive feedback.

¹⁸ Bonabeau, E. 1999. “Editor’s Introduction: Stigmergy.” Artificial Life 5(2): 95–96. doi:10.1162/106454699568692. ISSN: 1064-5462.

Stigmergy happens when one agent (e.g., a person, an ant, a robot) leaves a trace in the environment that is so clear about what needs to happen next that another agent that comes along can do so without direct communication or control.

Examples of stigmergy in human organizations include Wikipedia and open-source projects:¹⁹ Individuals perform small tasks and leave traces (commits, ideas, bug reports) that are picked up by other volunteers. Together, they are capable of building a free encyclopedia, sophisticated software, and complex frameworks without anyone telling them what to do. Constant direct communication isn’t necessary to coordinate complex work. The quality of traces left in the environment and how accessible they are determine the quality of the actions that follow, and the degree to which self-organization happens. A trace must be so specific that it basically necessitates the next action (or stigmergic action).²⁰

¹⁹ Heylighen, F. 2007. “Why Is Open Access Development So Successful? Stigmergic Organization and the Economics of Information.” In B. Lutterbeck, M. Bärwolff, and R. A. Gehring, eds., Open Source Jahrbuch. Lehmanns Media.

²⁰ Heylighen, F., and C. Vidal. 2007. Getting Things Done: The Science behind Stress-Free Productivity. Retrieved on May 27, 2020, from http://cogprints.org/6289.

Stigmergic action is an important mechanism by which Scrum Teams coordinate work (see Figure 11.4). The Product Backlog, the Sprint Backlog, and the Increment are traces of the work that has been done or will be done. During a Sprint, the clearer and better refined the next items on a Sprint Backlog are, the easier it is for teams to coordinate work without direct communication. It also happens when Scrum Teams synchronize their work through continuous integration, since a broken build or failed deployment indicates work that needs to be completed. Automated testing also encourages stigmergic action, as failing tests indicate specific problems that need to be fixed. Having a clear Sprint Goal on the wall helps Scrum Teams to distinguish between what is important and what isn’t, and it gives directions to stigmergic actions.

Figure 11.4 Literally surrounding ourselves with the traces of our work together makes it much easier to collaborate and build on each other’s work.

Unfortunately, Zombie Scrum often blocks stigmergy; the physical environment does not reinforce external memory. Instead of putting a Sprint Backlog on a wall in their team room, teams have to use a company-mandated digital tool. Or the action items from a Sprint Retrospective end up in an email or in someone’s drawer, and not clearly visible on the wall. Instead of drawing architectural diagrams on a movable whiteboard, the team stores them in a digital folder. Important metrics are in a digital dashboard that is only accessible to the Product Owner. This doesn’t mean that digital tools are bad, but they can easily block stigmergy by hiding traces behind a login or in a virtual folder, making them less visible. You have to actively look for them in order to find them. That architectural diagram is stored in a specific folder on the network, the Sprint Backlog is under a certain tab in your browser, and the improvements from the previous Sprint are in an email sent two days ago. This makes these traces less active. Physically surrounding the team with the work that is happening or needs to happen helps to encourage self-organization within and across teams.

Try these experiments to improve with your team (see Chapter 12):

• Use a Physical Scrum Board

• Observe What Is Happening

• Create Better Sprint Goals with Powerful Questions

In Zombie Scrum, We Are Impeded by Standardization

Because self-managed teams have a greater degree of autonomy to decide how to do their work, the efficiency mindset (see also Chapter 4) can lead to strong statements such as “It’ll be a mess when every team works in a different way!”, “It’s really inefficient to reinvent the wheel multiple times!” or “It’ll be chaos.” An underlying belief here is that multiple solutions for the same problem are less efficient than a single, standardized one. But two questions are important here:

1. Why is it a problem when teams make different choices? Every team is different, and they face at least a slightly different environment; one team’s solution to a problem may be different from the next, but if each team is effective, what difference does that make?

2. Why does the desire for standardized, centralized, and harmonized solutions override the desire to maximize the results that each team produces?

Signs to look for:

• Scrum Teams are unable to change their tooling or processes without approval from someone outside the team.

• Every Sprint, the Scrum Board shows a large number of items in a “Waiting” column, where someone other than a direct stakeholder of the product—such as another team, department, or supplier—needs to perform an action or give approval for this item to move to “Done” because standard procedure demands it.

• Scrum Teams are unable to change their physical or digital workspace because they need to adhere to default policies set by the organization.

• Scrum Teams are required to follow standardized practices, such as writing User Stories or estimating in Story Points, and standardized tools and technologies.

• Job descriptions for Scrum Masters, developers, and Product Owners are standardized and don’t take their context into account.

In environments with high degrees of standardization, Scrum Teams are constrained in their ability to develop local solutions in response to what is happening in their immediate environment. When the standardized solution, tool, structure, or practice doesn’t work well in response to changes in their environment, it impacts the team or even the entire organization. Such standardization makes the whole system decidedly more fragile against sudden change. Suppose that the one technology stack that is used by all teams is suddenly discovered to have a serious unpatchable security hole. What if requiring all teams to write User Stories makes it very frustrating for teams that work in areas where they don’t make sense? What if that one person with highly specialized skills suddenly went to work for a competitor?

Not standardization, but variability in solutions, functions, practices, and structures makes organizations more antifragile against sudden change (see Chapter 10). Variability lessens the possibility that a problem will disrupt everything in the organization. It also allows for double-loop learning as each variation is essentially an experiment with different potential outcomes. This kind of redundancy can appear inefficient, like waste. But as Nassim Taleb puts it: “Redundancy is [ . . . ] like waste if nothing unusual happens. Except that something unusual happens—usually.”²¹ In complex environments, redundancy is a competitive advantage.

²¹ Taleb, Antifragile.

Variability in solutions emerges on its own when self-organization is given space. When self-managed teams have the autonomy to come up with local solutions, antifragility follows. At the same time, practices can be put into place that let teams share successful approaches that other teams can take inspiration from. Code libraries, an overview of ongoing change initiatives, internal blogs, and regular marketplaces for innovative solutions are only a few examples that help teams share knowledge actively.

Try these experiments to improve with your team (see Chapter 12):

• Find Actions That Boost Both Integration and Autonomy

• Break the Rules!

• Express Clear Requests for Help

• Organize Scrum Master Impediment Gatherings

• Make the Cost of Low Autonomy Transparent with Permission Tokens

Healthy Scrum: What Self-Organization Looks Like

Zombie Scrum often starts when the ability of Scrum Teams to self-manage their work, and the impediments that are getting in the way of that work, are limited. From there flow many of the other problems we’ve addressed in this book. Scrum Teams are often acutely aware of the impediments that are making it hard to ship fast, to build what stakeholders need, and to improve continuously. But without a sense of control over removing those impediments and no support in doing so, it is understandable that teams withdraw into Zombie Scrum.

In this part of the chapter, we explore what healthy Scrum Teams look like. What does self-organization look like? How do they self-manage their work? How do Scrum Teams work together to drive change across the organization? And what is the role of Scrum Masters and management?

Scrum Teams Have Product Autonomy

Healthy Scrum Teams have full autonomy to make decisions over the product and how, when, and by whom work for that product is done. Within the Scrum Team, the Product Owner has autonomy over decisions regarding the “what” of the product and the Development Team regarding the “how.” Product Owners have the final say in what goes on the Product Backlog and in what order, guided by a product vision or strategy of their devising. The Development Team has the final say in how the work is done and how much work is done in the scope of a single Sprint.

When Scrum Teams have full autonomy, it doesn’t mean that they can ignore others and do whatever they want. The concept of “locus of control” is helpful here.²² The locus of control is internal when teams make the decisions about the product, but it is external when decisions are made for them. Although the locus of control remains with the Scrum Team, they coordinate their work closely with stakeholders, other Scrum Teams, relevant departments, and management. With an internal locus of control also comes the responsibility for the outcomes of decisions—successful and unsuccessful.

²² Rotter, J. B. 1966. “Generalized Expectancies for Internal versus External Control of Reinforcement.” Psychological Monographs: General and Applied 80: 1–28. doi:10.1037/h0092976.

A more complete overview is shown in Table 11.1. Other areas of self-management—such as setting your own salary, having a profit/loss balance as a team, and doing performance reviews within the team—may be a natural extension of this control, but they are certainly not required. In the same vein, some Product Owners may have the autonomy to set the product budget. Though very helpful, this budgetary power is not required. At a minimum, Product Owners should have autonomy over how to spend their allocated budget.

Table 11.1 Locus of Control and Accountability for Some Key Areas of the Scrum Framework

In many organizations, more than one Scrum Team works on a single product. When this is the case, the decision on whether or not to scale work (and how) is up to the Scrum Teams. Adding more teams invariably increases complexity. The Product Owner has to find ways to scale his or her work across multiple Scrum Teams. Scrum Teams have more dependencies on other teams as they try to create a Done Increment every Sprint that integrates their collective work.

Healthy Scrum Teams work together to find the best way to scale their work. Instead of shortcutting their learning process by jumping straight to off-the-shelf scaling frameworks, they engage in double-loop learning by identifying where impediments are happening and why. In some cases, technology stacks may be getting in the way of releasing every Sprint. In other cases, teams may benefit from colocation to facilitate smoother coordination. Creative solutions emerge from double-loop learning. For example, Scrum Teams can discover that a product can be broken down into smaller products or services, thereby reducing the complexity of having many teams working on a single product. Or they decide to invest in a continuous deployment pipeline to make it easier to integrate and release their collective work.

This is where self-management and double-loop learning enable self-organization. Autonomous Scrum Teams create their own rules, structure, and solutions for the problems they run into, instead of being told what to do by management or external consultants.

Management Supports Scrum Teams

In addition to Scrum Masters, managers play a pivotal role in supporting self-management and the resulting self-organization. Managers can be supportive or destructive. In healthy Scrum environments, managers don’t force alignment through top-down control, off-the-shelf frameworks, or standardized solutions. Instead, they focus on setting larger strategic goals from which Scrum Teams can distill product-specific goals for their work. Instead of mandating that unit test coverage should be 100 percent, they set a goal to increase customer satisfaction with product quality by 25 percent. Instead of determining what should go on the Product Backlog for a new group of stakeholders, they set a goal to enter a new market within six months. Instead of requiring teams to adhere to an off-the-shelf framework or practice, they encourage teams to ask for what they need to become more effective instead, and then they support those needs.

Like Scrum Masters, managers are there to support self-management and self-organization. They don’t lead by making decisions, but by creating an environment where Scrum Teams can decide things themselves.

“Recruit, self-organization is like a river. The more constrained it is by walls, floodgates, and detritus, the less capable it is of flowing around the obstacles that inevitably get in its way.”

Now What?

In this chapter we explored what self-organization is and how it is made possible through self-managed teams. Instead of the abstract concept that it tends to be, we explained how self-organization is a critical survival strategy in complex, uncertain environments, where sudden change can disrupt everything. We also explored common symptoms that help you identify when self-organization is (too) low. Although there are many potential causes, we covered the most important ones.

But what can you do when you’re faced with low levels of self-organization? Many of the causes in this chapter may lie outside of your control. In the next chapter, we offer practical experiments that help you create change nonetheless.