9. Symptoms and Causes

Everything’s better with zombies—NOT.

—Lily Herne, Deadlands

In This Chapter

• Learn what continuous improvement means.

• Explore the most common symptoms and causes that make it hard to improve.

• Discover how healthy Scrum Teams have embraced continuous improvement.

An Experience from the Field

The Development Team has gathered, unenthusiastically, for their Sprint Retrospective. They grumble about the time it takes. One developer sums up how the rest feel when he says, “What’s the point, really?” But since they agreed to give this Scrum thing a try, they resolve to make the best of it.

The door flies open and in rushes their Scrum Master, Jessica. “Sorry!” she begins. “The Sprint Retrospective for one of my other teams took longer than expected.” It doesn’t take her long to set up though; they’ve done this many times before. Jessica draws two columns on the whiteboard, marking the left one with “Going Well” and the right one with “To Improve.” This is a format she found online, and she’s been relying on it with all of her six teams ever since their agile transformation started three months ago. When she’s done, she asks people to write down whatever comes to mind on stickies and put them in the associated column.

After a few minutes, the column with possible improvements is overflowing. The Going Well column, on the other hand, is empty except for a sticky mentioning that the cafeteria now has better burgers. Honestly, the same pattern has emerged over the past seven Sprints. Most of the suggestions are attempts to deal with their inability to get anything done. The team’s tester, Pete, has been burned out and at home for the past three Sprints. Despite requests from the team, HR declined to find them a new tester. Instead, they feel that the team should just continue doing Scrum until Pete is back and can work his way through the backlog of items to test. Another improvement has to do with the Product Owner, who keeps pushing items into the Sprint or removing items that the team is already working on. Although the Product Owner never attends the Sprint Retrospectives, the team knows that he doesn’t really have a choice. When the agile transformation started, management decided to assign the requirements analysts to become Product Owners, as they saw them as the most capable of turning needs from stakeholders into clear requirements for the Development Team. In doing so, management did not empower these analysts-turned-Product-Owners to make decisions. So when stakeholders need something immediately, the “Product Owners” feel that they have no option but to add it to the Sprint Backlog straightaway.

The Development Team considers the Sprint Retrospective a mostly pointless affair. All of the improvements they identify have been raised many times before. “Give the Product Owner mandate” and “Get a new tester” are their favorites. When Jessica asks them how to do this, the team points at management and HR as the ones who should be fixing these impediments. But nothing ever changes. As a result, members of the team are losing their interest in working with Scrum.

Sadly, many Scrum Teams struggle to identify tangible improvements, and instead find only superficial or vague opportunities to improve, or find only improvement opportunities that are entirely outside of their control. During their retrospectives, they express beliefs and attitudes that show they are far from being self-managing and cross-functional teams (for more on this topic, see Chapter 11). For example, team members stick to the skills they’ve honed over the years. They are unwilling or unable to try something new, and they may feel uncomfortable sharing their knowledge with other team members.

In this chapter, we explore how Zombie Scrum prevents Scrum Teams from continuously improving, including recognizing the symptoms and potential causes.

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:¹

• 70% of the teams never or infrequently use metrics to identify improvements.

• 64% of the teams don’t actively engage with people outside their team to learn something new or have discussions about their professions.

• 60% of the teams never or very rarely celebrate small or large successes they’ve achieved.

• 46% of the teams never or rarely encourage people to learn new things, read professional books, or join meetups and conferences.

• 44% of the team’s Sprint Retrospectives don’t result in improvements for the next Sprint.

• 37% of the teams find it difficult to take risks by trying something new.

¹ 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 Improving Continuously?

Few teams start from a position where the Scrum Framework works perfectly from the beginning. Like learning to play an instrument, Scrum takes practice and improvement over time. As we’ve seen in earlier chapters, Scrum is radically different from the way that teams have built products and worked with stakeholders in the past. Scrum Teams usually need to improve in many different areas, and overcome many barriers, in order to reach their goals of higher customer satisfaction. Overcoming these barriers challenges teams to find their own solutions. Because every team, every challenge, and every context is unique, it doesn’t suffice to simply copy “best practices” from elsewhere and expect them to work. Instead, teams need to experiment with different approaches to find what works best for them.

When teams work with the Scrum Framework, we’ve noticed that they often start from a position of relatively poor performance. But if they use feedback to continuously learn and improve, they will achieve higher levels of performance over time. The Scrum Guide clarifies that the Sprint Backlog should at least include one high-priority improvement that was identified from the previous Sprint Retrospective. When teams focus on removing at least one barrier every Sprint, either fully or partially, those small incremental improvements accumulate to large change over time.

What Is Continuous Improvement?

Continuous improvement is a form of learning that applies not only to individual teams, but also to entire organizations as a whole. In his book On Organizational Learning, organizational theorist Chris Argyris defines organizational learning as a type of error detection.² Learning happens when a group of people achieves an outcome they were seeking without introducing (new) errors. It also happens when a mismatch is detected and a solution is produced to correct it. For example, a Scrum Team discovers that they frequently exceed the time box for the Daily Scrum because side discussions continue creeping into the conversation. They decide to limit their conversation to only what matters to the Sprint Goal. In other words, learning requires both discovering an error as well as implementing a solution for it.

² Argyris, C. 1993. On Organizational Learning. Blackwell. ISBN: 1557862621.

The Scrum Framework is essentially a mechanism for detecting two types of errors. The first type are errors that the Scrum Team detects in the product they are developing, ranging from bugs to incorrect assumptions about what is needed. The second type are gaps between what would be necessary to detect those errors earlier and what is actually done to detect them. These are the impediments that teams identify towards working (more) empirically. Focusing on these two types of errors allows teams and organizations to learn in two complementary ways, according to Argyris: single-loop learning for errors of the first type, and double-loop learning for errors of the second type.

As shown in Figure 9.1, single-loop learning focuses on solving a problem within an existing system that is defined by sets of beliefs, structures, roles, procedures, and norms. Double-loop learning challenges the system itself. As an example of single-loop learning, a Scrum Team might explore different techniques for estimating their Product Backlog for the purpose of forecasting. The Scrum Team might also use double-loop learning to challenge the purpose of forecasting itself and look for other ways to satisfy the need to forecast. Another example of single-loop learning is when developers try to fix broken unit tests faster, whereas double-loop learning would see them question why their unit tests are so prone to breaking in the first place. A final example of single-loop learning is when a Product Owner tries to better capture requirements on the Product Backlog, whereas double-loop learning might make her question the need for detailed requirements in an empirical process in the first place. Where single-loop learning improves what is possible within the current system, double-loop learning is about challenging and changing the system. Double-loop learning helps people change (sometimes deeply held) assumptions and beliefs.

Figure 9.1 The distinction between single- and double-loop learning³

³ Source: Argyris, On Organization Learning.

Although both types of learning are important for continuous improvement to happen, Argyris emphasizes double-loop learning as particularly important for non-routine, complex work where teams have to constantly challenge not only how they do the work, but also why. The many changes that organizations have to go through to transition from plan-based approaches to empirical ways of working mean that organizations need to employ a high degree of double-loop learning to change underlying beliefs about risk, control, management, and professionalism. Organizations that find themselves unable to change the rules, norms, and beliefs that stand in their way will struggle to stay competitive. Unfortunately, Argyris also notes that highly trained professionals in particular often struggle to practice double-loop learning, as it involves challenging the practices and skills that have made them successful in the past.

Fortunately, using the Scrum Framework purposefully helps teams leverage both types of learning by creating transparency around how work is done, and by creating opportunities for inspection and adaptation. Although all Scrum Events help teams to learn by inspecting and adapting, the Sprint Retrospective is the one that most directly reflects on how work is done. The benefits of this reflection are limited when it focuses only on finding new practices and techniques (single-loop) and doesn’t involve challenging underlying beliefs and rules (double-loop). Teams affected by Zombie Scrum tend to limit themselves to single-loop learning and can’t benefit from double-loop learning because their existing beliefs about management, products, how to manage people, and how to control risk remain unchallenged.

Continuous Improvement or Agile Transformation?

Many organizations begin their journeys into Scrum with an “agile transformation” focused on reducing costs, improving responsiveness, or appeasing stakeholders. Management brings in external consultants and coaches, sends teams to training, and changes roles and structures accordingly. Like a butterfly that emerges from a caterpillar, “transformation” suggests that it is possible to transition from one state (e.g., waterfall-based development) to another (e.g., agile and other value-driven approaches) in a relatively short amount of time through a concerted organizational change program.

These transformations are rarely successful in making teams more responsive. Although high-quality research is hard to find, our Zombie Scrum Survey suggests that over 70 percent of Scrum Teams don’t frequently collaborate with stakeholders, and that 60 percent don’t frequently deliver working software. We don’t know from our data if these teams are (or have been) involved in agile transformations, but the results don’t point to huge shifts in responsiveness. It fits with our own observations from the organizations we’ve visited where agile transformations have taken place. More often than not, little has actually changed in terms of responsiveness and collaboration with stakeholders. And without meaningful results, organizations quickly move to transform to the next promising trend that comes along, only to repeat the process again.

A model that helps us understand why change is so difficult is Kurt Lewin’s Force Field Model⁴ (see Figure 10.2). Lewin, one of the pioneers of group dynamics and action research, argues that social systems—of which organizations are one example—exist in a state of equilibrium where some forces drive for change on an issue while others prevent it. Forces consist of beliefs that people have, social norms about how work is done, things that are happening in the environment, or the actions that people or groups take. In any case, change happens when the forces driving for change exceed those restraining it. This balance fluctuates as forces grow stronger or weaker over time, or change direction altogether.

⁴ Lewin, K. 1943. “Defining the ‘Field at a Given Time’” Psychological Review 50(3): 292–310. Republished in Resolving Social Conflicts & Field Theory in Social Science. Washington, D.C.: American Psychological Association, 1997.

Figure 9.2 The status quo is often hard to change, as forces driving for change are not strong enough to counter forces restraining it.⁵

⁵ Source: Lewin, “Defining the ‘Field at a Given Time.’”

This model helps us understand three important realities about organizational change. The first is that a change is never done (or “implemented”), as any change simply regresses back to an earlier state when the forces pushing against it become stronger. The second is that changing the status quo can be very difficult, as there are countless visible and invisible forces pushing for and against it. The third is that underlying beliefs and assumptions about how work is done are some of the most constraining forces we find in organizations.

The Force Field Model shows how important double-loop learning is for challenging those beliefs. If Scrum Masters believe that they are essentially project managers, with a clear responsibility for the outcome, they will continue to act in ways that disempower the ability of the Development Team to self-manage and continuously improve. And when people see mistakes as something to avoid at all cost, it becomes impossible to create an environment where Scrum Teams can learn from their mistakes without fear of punishment.

The Scrum Framework not only helps teams to become more responsive, it also gives them a process by which they can learn and improve over time. Some changes involve single-loop learning, where teams and organizations discover new techniques and practices to do their work. Other changes involve double-loop learning, where the purpose of the work and its governing rules are themselves questioned. Deep learning enables the forces that push towards increased agility to overcome those forces that restrain it, creating the conditions to sustain the change.

Why Are We Not Improving Continuously?

If continuous improvement 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. This awareness also builds empathy with teams and organizations suffering from Zombie Scrum, and helps to better understand how it often emerges, despite everyone’s best intentions.

In Zombie Scrum, We Don’t Value Mistakes

Making mistakes is inevitable when you are dealing with complex work. As we explored in Chapter 4, complex work is inherently uncertain and unpredictable, and the people doing that work have fallible memories, make imperfect decisions, don’t have access to all the facts, and often draw incorrect conclusions when they do. Bugs will be introduced, incorrect assumptions that seem obvious after the fact will be discovered, and people will forget important information. Thankfully, Scrum offers a framework to discover these mistakes early and learn how to prevent them. Trying new things, having them not turn out as planned, learning what went wrong, applying that learning, and trying again: this is continuous improvement in a nutshell.

Organizations that suffer from Zombie Scrum avoid making mistakes at all costs or don’t recognize what they can learn from them. For example, when Scrum Teams can’t deploy their Increment on their own because there is too much risk. Or releases don’t happen every Sprint because it seems too difficult, and new technologies are avoided because they are too daring. When you say that the Scrum Framework is a way to fail fast, people respond with wide-eyed wonder: “Why would you ever want to fail in the first place? Instead, let’s call it ‘succeed fast.’” And “Let’s not talk about ‘experiments’ or ‘minimum viable products’—it makes people uncertain.” Instead of seeing mistakes as opportunities to learn, they see mistakes as things to avoid.

Signs to look for:

• Management wants experiments to be called “initiatives,” because the term “experiments” gives the impression the outcome is uncertain and mistakes might be made.

• The Product Owner tells the Development Team not to release the product until they can guarantee it is 100 percent bug-free.

• During Sprint Planning, only the easy but not-so-valuable Product Backlog items are selected. The more valuable, riskier items are ignored.

• The outcomes of Sprints are batched into large, infrequent releases. Or teams deliver Increments that they consider “Done,” but in reality need a lot more work by others before they can be deployed to production.

When a big-bang rollout results in significant issues, it can permanently damage reputation. Like the disastrous initial launch of HealthCare.gov⁶ or the storm of negative reviews that followed the long-awaited release of the game No Man’s Sky.”⁷ A recurring pattern behind these massive, reputation-threatening mistakes is that all the risk is at the end of development—when the product is finally released. Despite everyone’s best efforts, any mistake—like a breaking bug or poor performance—has a huge blast radius. Mistakes can bankrupt or permanently damage a brand. One knee-jerk reaction is to engage in even more up-front planning and analysis in an attempt to identify potential risks. Unfortunately, this approach provides a false sense of security: due to the nature of complex work, most risks are completely unknown until you actually do the work.

⁶ Cha, A. and L. Sun. 2013. “What Went Wrong with HealthCare.gov.” Washington Post. October 23. Retrieved on May 27, 2020, from https://www.washingtonpost.com/national/health-science/%20what-went-wrong-with-healthcaregov/2013/10/24/400e68de-3d07-11e3-b7ba-503fb5822c3e_graphic.html.

⁷ Schreier, J. 2016. “The No Man’s Sky Hype Dilemma.” Kotaku.com. Retrieved on May 27, 2020, from https://kotaku.com/the-no-mans-sky-hype-dilemma-1785416931.

As we explored in Chapter 4, the Scrum Framework offers a better strategy for reducing risks by containing the blast radius to a single Sprint (or less). Instead of trying to avoid the mistakes that inevitably happen, Scrum helps teams reduce the damage by giving them a process to discover mistakes earlier, fix them faster, and reduce their impact. More important, it allows teams to improve their process, collaboration, and technology by delivering a working product Increment and measuring the result. By taking this approach, they will sometimes find that what they built wasn’t the right solution, or it doesn’t work quite as expected. But these mistakes will be small and easier to correct than if the team had gone on for a very long time before delivering something and measuring the result. By making many small corrections, they reduce the impact and likelihood of having to make much bigger ones. Just as our immune systems usually become stronger when we’re exposed to pathogens, teams become more resilient when they make mistakes and recover from them. But organizations that suffer from Zombie Scrum ironically are so involved in removing all pathogens from their surroundings that they end up getting life-threatening illnesses from a common cold.

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

• Ask Powerful Questions during Sprint Retrospectives

• Dig Deeper into Problems and Potential Solutions, Together

• Create a Low-Tech Metrics Dashboard to Track Outcomes

Everyone makes mistakes. You delete the wrong document. Or you buy stickies that don’t stick. Or you use permanent markers on a whiteboard. It happens. We can’t have each other’s backs when we also blame each other for our mistakes.”

In Zombie Scrum, We Don’t Have Tangible Improvements

The Scrum Framework provides a clear criterion for success: deliver a potentially releasable Increment every Sprint. And because that requires addressing many of the hard challenges we talk about in this book, you won’t be able to do it overnight. Improving incrementally, in small steps, is your best strategy to keep change manageable and motivating.

We run into serious problems, however, when the small steps that people come up with are vague and nonspecific, like “improve communication” and “increase collaboration with stakeholders.” Although these are good goals, they don’t tell you where to begin and what success looks like. Teams with improvements like this should ask themselves: “When we communicate better, what will be different?” and “What would it look like if we increased our collaboration with stakeholders?” Specific improvements, with metrics, help people know what they are committing to; vague improvements are easily agreed on, and harder to judge whether they have missed their goal. They make it very difficult to actually succeed in improving and building confidence.

Another example of this dynamic is what we call “Happy-Clappy Scrum” (see Figure 9.3). Here, Scrum Teams focus their energy on making the Scrum Events as fun, lighthearted, and energizing as possible, leveraging the many games and facilitation techniques that can be found online. This phenomenon often happens when teams cannot influence impediments, and their well-intentioned improvements remain superficial. Although there is great value in creating inclusive and engaging environments, this approach doesn’t help when the team is not actually inspecting their results and adapting their product and their approach based on feedback. Rather than use the Scrum Events as opportunities to remove larger impediments to inspecting and adapting, the Scrum Team focuses on reenergizing people to survive another Sprint amidst a wasteland of Zombie Scrum. But no matter how fun the Sprint Retrospective is, teams won’t feel better when they have no feedback about the impact they’re having on real users. No matter how energizing and fast your Sprint Planning is, it won’t make your stakeholders happier when they still have to wait a year for the work to reach them.

Figure 9.3 Although fun and happiness are certainly part of Scrum Teams, they shouldn’t be more important than delivering value to stakeholders.

Signs to look for:

• The Sprint Retrospective doesn’t result in any improvements at all.

• For the actions that come out of a Sprint Retrospective, it is unclear where to start or what success looks like.

• Scrum Teams or Scrum Masters focus their improvements mostly on making the Scrum Events more fun, with more games and more facilitation techniques.

• Scrum Teams don’t inspect metrics during Sprint Retrospectives to identify improvements.

• Team members put the responsibility of performing an action on others, often people outside of the team.

One important skill for Scrum Teams to learn is how to be specific about what to improve, and how to break down improvement into small steps. Just as refining large items on the Product Backlog into smaller items makes it easier to complete them, breaking down large improvements into small steps makes it more likely your improvements will succeed. Teams that suffer from Zombie Scrum tend to either get stuck in huge, demotivating improvements like “Product Owner should have a greater mandate” or they get lost in vague improvements that don’t tell them where to start.

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

• Create 15% Solutions

• Focus on What to Stop Doing

• Create Improvement Recipes

In Zombie Scrum, We Don’t Create Safety to Fail

Teams can’t improve when they experience no room for uncertainty, doubt, or criticism. Teams that suffer from Zombie Scrum operate in environments that signal that doubt and uncertainty are unacceptable. They often develop all kinds of defensive strategies to prevent uncertainty. From subtle strategies, such as changing the topic or casually dismissing opposing views, to very blatant ones, such as ostracizing or criticizing dissenters.

Teams are social systems. Past behavior of people inside and outside the team shapes the social norms that govern how people interact (and vice versa). When doubts and uncertainty are met with dismissal, it creates and reinforces a social norm that being critical is “not something we do here.” The same goes for when people notice how others never ask for help when they’re stuck, so that everyone muddles through instead of asking for guidance. These signals shape the organizational culture.

Signs to look for:

• The concerns, doubts, and uncertainties that people have about a proposed action are dismissed or ridiculed by others.

• Members complain about each other privately but never voice those complaints to the group, out of fear of being “negative.”

• When members of the team are stuck at a task, they don’t ask for help from others. Or it takes them several days of muddling through before they do so.

• The conversations during Sprint Retrospectives focus on tiny improvements, instead of the important things that are obviously not going as well as they could.

• Concerns and doubts are never expressed when the team is together but are mostly gossiped about.

• During team meetings, body language is protective. Arms are crossed, people lean back (instead of in), and are turned away from each other.

The social scientist Edgar Schein described organizational culture⁸ as an onion of three layers (see Figure 9.4). The outer layer consists of the artifacts and symbols that you observe in an organization, from the titles that people have or the size of their offices to how people are seated or who speaks first at meetings. The core of the onion consists of deeply held, often unconscious, assumptions that people make about each other and their work. For example, “More-experienced people are more worthy of attention than you.” Or that “Colleagues will support you when you get in trouble.” In between the outer layer (the observable elements) and the core (the assumptions) are the beliefs and values that are actively espoused by people when you ask them. These are the things that often end up in culture manifestos or work agreements.

⁸ Schein, E. H. 2004. Organizational Culture and Leadership. 3rd ed. San Francisco: Jossey-Bass.

Figure 9.4 Organizational culture can be understood as an onion, from the very visible artifacts and symbols to deeply held beliefs and basic assumptions.⁹

⁹ Source: Schein, Organizational Culture and Leadership.

Organizations experience problems when the layers don’t align. This is particularly pronounced in how they deal with mistakes and uncertainty. Few organizations and teams actively espouse values that discourage doubts or uncertainty, even when they put rules in their working agreements such as “Raise concerns when you have them.” When the espoused values (the middle layer) don’t match what actually happens (the outer layer), people’s beliefs change accordingly over time (the core).

If the team manifesto says that you should “Ask for help when you need it” but nobody ever offers to help when you ask for it, people will stop asking for help eventually. If an espoused value is “Admit it when you don’t know something” but leaders never admit to not knowing something themselves, people will eventually start presenting false certainty as well. In their desire to belong to the social group—which every team is—people start to self-censor in order to fit in. The resulting artificial harmony gets in the way of continuous improvement, as people stop looking for, or challenging, things that are not going well.

Organizational culture is like the ruts in a well-trodden path. The deeply held beliefs of people about making mistakes, showing uncertainty, and being vulnerable are reinforced over time by behavior and artifacts in their environment, both by themselves and by others. The deeper the rut, the harder it is to change course. And for teams that suffer from Zombie Scrum, the ruts have become particularly deep. That makes it very hard to create environments where people can safely learn.

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

• Share an Impediment Newsletter throughout the Organization

• Focus on What to Stop Doing

In Zombie Scrum, We Don’t Celebrate Success

Sometimes, teams can focus so much on potential improvement that they ignore all the positive things that they are already doing. As we saw from the data presented at the beginning of this chapter, few teams find the opportunity to celebrate small and large successes as they happen. How demotivating is it for people when their contributions to success are never recognized?

Signs to look for:

• People don’t compliment each other when something went well, or was done well.

• Even when something has gone well, people immediately jump to new things to improve.

• When a Sprint goes well, stakeholders don’t make positive comments.

Some people stumble over the word “celebration,” fearing fake compliments or gratuitous high spirits. Or they may feel that they need to solve the whole problem before they can celebrate small steps towards a solution. This puts the bar too high if every problem first needs to be completely solved before you can be happy about the progress you made as a team. A celebration simply recognizes progress towards a goal; it doesn’t have to mean that the work is over, nor that the pressure is off.

Celebrating success can be as simple as saying, “Thank you for doing a good job” or even “Thanks for trying to make an improvement.” Or bringing snacks to the Sprint Review and going for drinks at the end of a Sprint. Many teams that suffer from Zombie Scrum are stuck in the mud to such an extent that all they can see is the mud.

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

• Bake a Release Cake

• Share Success Stories and Build on What Made Them Possible

In Zombie Scrum, We Don’t Recognize the Human Factors of Work

As we explored earlier, Scrum Teams that lack psychological safety find it hard to learn and improve. Both require trying new things and talking openly about mistakes. The organizational psychologist Amy Edmondson describes psychological safety as “a shared belief about the consequences of interpersonal risk-taking.”¹⁰ Her research shows that psychological safety is an important enabler for learning to take place in groups and individuals.

¹⁰ Edmondson, A. 2009. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly 44(2): 350–383.

Organizations that suffer from Zombie Scrum spend little time on human factors. Either they don’t see the need or they simply assume that employees will behave professionally, and so they implicitly and explicitly signal that spending time on work agreements, talking about tension, getting to know each other, and building a team are not considered “real work.” They fail to appreciate that teams are social systems with important social needs.

Signs to look for:

• The composition of Scrum Teams is frequently changed by people outside the team, without taking time to reestablish interpersonal safety and trust.

• Team composition is entirely based on skills and experience, and not also on personal preferences, diversity of backgrounds, or behavioral styles.

• Teams are not given time or support to learn how to make decisions, to navigate interpersonal conflict, and make work arrangements.

It’s impossible to summarize the decades of work done by social, cognitive, and organizational psychologists into the vast influence of human factors on work, but we have learned that:

• People are likely to self-censor criticisms and doubts in favor of being part of a cohesive group, to the point of unethical or irresponsible decisions (groupthink).¹¹

¹¹ Janis, I. L. 1982. Groupthink: Psychological Studies of Policy Decisions and Fiascoes. Boston: Houghton Mifflin. ISBN: 0-395-31704-5.

• People attribute successes to their own actions, and failures to their environment—even when this is demonstrably not the case (fundamental attribution error).¹²

¹² Ross, L. 1977. “The Intuitive Psychologist and His Shortcomings: Distortions in the Attribution Process.” In L. Berkowitz, ed., Advances in Experimental Social Psychology, pp. 173–220. New York: Academic Press. ISBN: 978-012015210-0.

• Making people work on different complex tasks at the same time negatively impacts their performance for each individual task.¹³

¹³ Rogers, R., and S. Monsell. 1995. “The Costs of a Predictable Switch between Simple Cognitive Tasks.” Journal of Experimental Psychology 124: 207–231.

• People quickly conform to decisions by their group, even when they know the decisions are blatantly wrong (peer pressure).¹⁴

¹⁴ Asch, S. E. 1951. “Effects of Group Pressure on the Modification and Distortion of Judgments.” In H. Guetzkow, ed., Groups, Leadership and Men, pp. 177–190. Pittsburgh: Carnegie Press.

• People reject obvious facts that don’t align with their beliefs (cognitive dissonance).¹⁵

¹⁵ Festinger, L. 1957. A Theory of Cognitive Dissonance. California: Stanford University Press.

• Groups compete with each other, and start forming negative judgments about each other, when their only distinguishing characteristic is as trivial as a name (minimal group membership).¹⁶

¹⁶ Tajfel, H. 1970. “Experiments in Intergroup Discrimination.” Scientific American 223(5): 96–102.

• Our ability to arrive at rational decisions is severely limited by countless biases,¹⁷ such as our limited grasp of probabilities, how we generalize from recent examples, and how our estimations tend to be way too optimistic.

¹⁷ Kahneman, D., P. Slovic, and A. Tversky. 1982. Judgment Under Uncertainty: Heuristics and Biases. New York: Cambridge University Press.

• Conflicts—both latent and overt—have a profound negative influence on group functioning.¹⁸

¹⁸ De Dreu, K. W., and L. R. Weingart. 2003. “Task Versus Relationship Conflict, Team Performance and Team Member Satisfaction: A Meta-analysis.” Journal of Applied Psychology 88: 741–749.

This is just a selection of well-researched and replicated effects that shape our own thinking and work in groups. They help us understand why adding more people or teams often doesn’t help at all. Or that changing team composition has far-stretching social consequences. The point here is that a team can’t continuously improve without recognizing that they are social systems. It is simply not enough to put “the best people” in teams and expect them to work miracles by virtue of their individual professional skills.

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

• Share Success Stories and Build on What Made Them Possible

• Share an Impediment Newsletter throughout the Organization

• Use Formal and Informal Networks to Drive Change

In Zombie Scrum, We Don’t Critique How We Do Our Work

Organizations that suffer from Zombie Scrum don’t leverage the Scrum Framework to critique and change how work is done in the organization. This often begins with what the organization expects of a Scrum Master, and the Scrum Master’s own understanding of what is important about their role.

For many Scrum Masters, this understanding translates exclusively into the facilitation of Scrum Events for one or more Scrum Teams. And although there is value in that, it is also a very narrow definition. The broader purpose of Scrum Masters is to create transparency around the ability of teams to deliver valuable outcomes to their stakeholders, and the impediments that get in the way. One way to do this is by helping teams gather data to assess how they are doing. By shining a light on where it hurts the most, Scrum Masters encourage double-loop learning, when it comes to building what stakeholders need and shipping fast.

Signs to look for:

• Scrum Masters spend most of their time facilitating Scrum Events.

• Scrum Teams are measured and compared based on how much work they complete (e.g., velocity and the number of items completed) instead of how much value that work actually generates for stakeholders and organizations.

• Scrum Teams don’t spend time together, and with their stakeholders, to make sense of the outcome-oriented metrics they track and what improvements seem sensible.

• Scrum Teams don’t dissect product or process data, such as stakeholder happiness or cycle time, to identify improvements.

One way to start critiquing is by tracking relevant metrics. Unfortunately, Zombie Scrum Teams usually don’t measure improvements at all. When they do, they focus on areas that don’t support, or even hinder, empiricism, such as when Scrum Teams measure the amount of work they deliver every Sprint, as expressed by the velocity or the number of items completed, rather than the value that they delivered. Organizations may also track the number of people and teams working on a product, and the number of hours they put in, looking at reductions in the number of people or hours as an indicator of improvement. We’ve explored the reasons behind this approach in more detail in Chapter 5.

The problem with metrics like these is that they are concerned only with how much work is done in a given amount of time—the output—but not with how valuable that work actually is for stakeholders and the organization—the outcome. And while the former may be easier to track, it’s largely irrelevant in terms of the value that the organization delivers. After all, it is entirely possible to see huge improvements in velocity over time and still go bankrupt when the product doesn’t deliver enough value to stakeholders. It’s also entirely possible to work on a product with a dozen teams yet deliver a product of such low quality that teams are essentially only fixing bugs and drowning in technical debt. While you can achieve stellar scores on output and horrendous scores on outcomes, the reverse is unlikely.

Fortunately, the Scrum Framework provides both a process for discovering and implementing improvements as well as areas to focus on:

• Responsiveness. The time it takes between the discovery and the fulfillment of an important stakeholder need, as expressed by cycle time and (low) work in progress, decreases over time (or remains low).

• Quality. The quality of the work delivered, as expressed by the number of defects, code quality, customer satisfaction, and other quality metrics, increases over time (or remains high).

• Improving. The way work is done and experienced, as expressed by team morale, innovation rate, lower dependencies, and other metrics, improves over time.

• Value. The amount of value, as expressed in revenue, return on investment, and other business metrics, increases (or remains high over time).

In order to leverage the Scrum Framework to drive change throughout organizations, Scrum Teams and Scrum Masters do well to create transparency around outcome-oriented metrics. By periodically inspecting them with stakeholders, they can identify where it hurts, what to improve, and what happens because of these improvements. This is what empiricism is all about.

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

• Focus on What to Stop Doing

• Share an Impediment Newsletter throughout the Organization

• Create a Low-Tech Metrics Dashboard to Track Outcomes

In Zombie Scrum, We Consider Learning and Work As Different Things

In organizations suffering from Zombie Scrum, people are implicitly taught that learning and work are separate things. Work generates value, while learning only costs time and money that could’ve been spent doing more “real” work. For example, management expects people to participate in training on evenings or on weekends. The implicit message is that people get paid for work, and since learning isn’t real work, they have to do it on their own time.

Signs to look for:

• People don’t visit external meetups or trainings, or read professional books or blogs, and they certainly are not encouraged to do so.

• Scrum Teams don’t stay up to date with developments in their professions. For example, developers don’t know about continuous delivery, virtualization, and microservices, or Scrum Masters are unaware of Kanban and Liberating Structures.

• Product Owners keep pushing items focused on innovation further down the Product Backlog in favor of adding more features, without actually measuring how effective that is.

• Scrum Teams make their Sprint Retrospectives as short as possible.

• Management discourages people from going outside and learning from others by requiring detailed business cases about what value this would generate.

The point here is not to spend more time on learning, but to remove the artificial separation between learning and work. Long gone are the days when you could learn a skill at school and then put learning behind you. This has never been more true than in software development, where new technologies, languages, and practices emerge ever faster. Though not all are equally helpful, some offer new paradigms, such as continuous delivery and containers, that make it easier to ship faster and improve quality. The uncertainty of complex work, and the challenges it throws at teams, requires them to constantly learn how to navigate that complexity better. Organizations that suffer from Zombie Scrum push learning to the fringes of work. Therefore, they never benefit from what happens when teams have time and space to try new things and see what becomes possible because of that.

It’s hard to improve when you’re rarely exposed to new ideas and different perspectives, yet for many teams that suffer from Zombie Scrum, this is exactly what happens. With so much work to do, they have little time for learning. Although organizations frequently describe themselves as “learning organizations,” few actually exhibit the characteristics of a true learning organization. When “getting work done” is always valued more than participating in training and meetups, or when organizations don’t invest in knowledge-sharing workshops because they see more value in keeping teams busy, or when reading professional blog posts during work is frowned upon, the organization clearly sends a message that it doesn’t value learning.

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

• Use Formal and Informal Networks to Drive Change

• Share Success Stories and Build on What Made Them Possible (especially with multiple teams present)

You think that learning and working are different things, recruit? As Henry Ford said: ‘Anyone who stops learning is old, whether at twenty or eighty.’ You’re never done learning when it comes to Scrum. And tie your shoelaces: we’re going for a run!”

Healthy Scrum

Experience: Not Scrum by the Book

Here’s a tale of firsthand experience from one of this book’s authors:

When one of the authors started with Scrum, all he did was host a Daily Scrum every other day. For him and his team, that seemed like the most useful part of the Scrum Framework. Coming from a situation where detailed specification documents—written by the author—guided the work, the Development Team initially didn’t see much value in Sprint Planning and Sprint Review. The team believed that all the work was already known, and they wouldn’t be releasing the product for months anyways.

As the team started working with Sprints, they learned how useful it was to show intermediate results to their customers. They also learned that while many ideas from the specification document seemed good at the time of writing, they were often interpreted differently by customers and developers. Or better ideas emerged when the customers got to interact with the results. The benefit was mutual. In fact, one of their corporate customers—normally dressed in a crisply tailored suit—would visit every other week wearing shorts and flip-flops to see what the Development Team had come up with.

Where the relationship was initially very much framed as customer and vendor, it became more informal and collaborative over time. Increasingly, key users would tag along to benefit from the opportunity to offer ideas that would make their work in the resulting product easier (and join in after-work drinks). Developers started making parts of the product available before its scheduled “launch date” to address users’ natural need to benefit immediately from the work done. This situation paved the way for continuous delivery and ever closer collaboration. Only in hindsight we realized that this team was increasingly learning to work empirically. They learned from experience and changed existing beliefs about specifications, about collaboration, and about the need to ship fast.

In the story, we see double-loop learning when stakeholders change their belief that the Development Team is merely a supplier of their product. We also see double-loop learning when the team learns that releasing Increments actually allows them to build a better product.

Although this story is only one example, there is a clear commonality with other successful Scrum Teams we’ve worked with. Few of them start with Scrum by the book. Instead, their desire to deliver valuable outcomes to their customers, users, and stakeholders drives their learning. In turn, stakeholders respond by being more available as they learn how this approach benefits them too. And management actively encourages both movements by removing impediments that get in the way and giving teams autonomy to improve where they deem necessary. The process of continuously inspecting and adapting the work, along with how and why that work is done, attributes to their success.

Self-Critical Teams

From the story, it might seem that the growth over time was smooth and free of conflict. It wasn’t. And that is another commonality we’ve found with other successful Scrum Teams. They have spirited disagreements on how to move forward. Where some passionately argue to deploy faster, others argue to take it slower to guarantee quality and stability. Where some want to spend more time writing code, others want to spend more time thinking about what to write. But although preferences and strategies diverge, the focus remains on delivering high-quality outcomes to stakeholders.

Healthy Scrum Teams are critical of themselves. They use their Sprint Retrospectives to reflect on their ability to create a high-quality, releasable version of their product to stakeholders. They use objective data to support this reflection, ranging from cycle time to bug count. Although their Sprint Retrospectives can use creative formats to achieve this goal, a good conversation with powerful questions is often better. Scrum Masters support this reflection by keeping the focus on delivering valuable outcomes and helping teams to navigate the inevitable conflicts that surface while doing so.

See the Forest and the Trees, Together

In their drive to deliver value to stakeholders, healthy Scrum Teams are acutely aware that impediments often transcend individual teams. Shared tooling may not support continuous delivery, for example. The sales department continues to sell work against fixed prices and deadlines. Or teams find that the way their office spaces are organized is making collaboration difficult.

Healthy Scrum emerges where people take time to see both the forest and the trees. While making improvements in their own teams (the trees), they also take time to reflect and improve how the system as a whole (the forest) is making it possible for them to deliver value. Instead of leaving this task up to Scrum Masters or dedicated agile transformation teams, this is done with whoever wants to be involved. After all, impediments in one area are often linked to others elsewhere in the organization. That makes it beneficial to bring in as many minds as possible, so as to maximize the resolution of the reflection and the creativity of possible solutions. This can take the shape of multiteam Retrospectives to workshops attended by everyone who wants to help. For example, the authors of this book are frequently involved in workshops where fifty or more participants—ranging from management to developers—use a day to reflect on, and resolve, impediments to empiricism that are surfacing across their organization.

Now What?

In this chapter we explored the most common observations that help you conclude that continuous improvement isn’t taking place. We also covered the important underlying causes that we often find in our work with teams that suffer from Zombie Scrum. Although everyone agrees that continuous improvement is a good idea, the problems start when you are dealing with impediments that seem to be outside the control of your team. Instead of focusing on where you don’t have control, we find it more useful to focus on where you do and start from there. No matter how small, where do you have responsibility and control? And who can you draw in to help you remove what you can’t control yourself? In the next chapter, we explore experiments that help you do just that.