7. Symptoms and Causes

Most people don’t believe something can happen until it already has.
That’s not stupidity or weakness, that’s just human nature.

—Max Brooks, World War Z: An Oral History of the Zombie War

In This Chapter

• Discover the symptoms and observations related to not shipping fast enough for your organization’s needs.

• Explore the most common causes of not shipping fast.

• Learn how healthy Scrum Teams balance shipping fast with keeping the focus.

An Experience from the Field

We recently met a team that was infected with Zombie Scrum. They told us about this very cool and innovative (online) platform they’d been working on for the past two years. It all started several years ago when the CEO woke up one night with a great idea for a new product. A Scrum Team of ace developers was formed to take on the challenge and work their way through a long Product Backlog. And so they did. As time passed, a lot of clever code was written, and dozens of incredible features were added. Both the company and the team appreciated the rhythm and structure that Scrum provided. They prided themselves on their strict adherence to the Scrum Framework and its prescribed roles and events.

The one exception was that even though every Sprint resulted in a “potentially releasable Increment,” they never actually released anything. One reason was that the Scrum Team was not sufficiently skilled in testing the delivered functionality. This was the job of the Quality Assurance (QA) department down the hall. New features could only be delivered when QA had thoroughly tested and green-lighted everything. But considering QA’s substantial workload, this usually required several Sprints. Another reason was the amount of manual effort involved in deploying new versions. Because the team experienced past deployments for other products as very stressful and error-prone, they preferred to release only once for the final launch of this product. Although the team proposed to set up an automated deployment pipeline to ease this process, management decided against that approach to keep the focus on adding more features.

Sixteen months later, the first version of the product was finally released to the market. Accompanied by a massive marketing campaign, the product fizzled. As it turned out, customers used the product in vastly different ways than expected. For example, the extensive API that the team had been working on for four months was used by only 2 percent of the customers. Despite initial expectations, the product failed to return on the investment.

Soon after, the symptoms of Zombie Scrum began to appear. The team lost motivation; their excitement left like air rushing out of a punctured balloon. “What went wrong? We finished all the user stories in our Sprints! Wasn’t Scrum supposed to prevent failures like this?” Slowly, the eyes of the developers glazed over. Despite the setback, the CEO remained steadfast and hopeful. It wasn’t like there weren’t any customers, just not a lot. But that would change with the next release—he promised—ten months from now.

This case illustrates how building what stakeholders need (Part II) and shipping fast (Part III) are two sides of the same coin: You can’t do one well without the other. In this case, the Scrum Team built features that weren’t useful to customers, but they didn’t know until the product was finally released. All the money, time, and resources spent fleshing out these supposedly valuable features were wasted in the urge to “get things right the first time.”

In this case, the primary source of waste was not the team slacking off, a lack of detailed specifications, or failed alignment between departments. It was a missed opportunity to launch the platform earlier and get feedback from stakeholders sooner. As it turned out, the company incorrectly believed that their platform was going to solve a problem experienced by their stakeholders. And even though some features probably did, the benefits didn’t justify the price. While shipping fast doesn’t guarantee success, it helps organizations find out faster whether their ideas are actually valuable, and adjust the product strategy based on feedback. This chapter is all about shipping fast, and how it is your best survival strategy when faced with complex work. We also explore the reasons—and excuses—that we encounter for not doing this.

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

• 62% have to perform a significant number of manual steps in order to ship an Increment.

• 61% of the Product Owners don’t or infrequently use the Sprint Review to gather feedback from stakeholders.

• 57% experience significant stress and pressure to get everything done during the final days of a Sprint.

• 52% frequently have to resolve issues in the next Sprint that could’ve been prevented by better testing.

• 43% don’t spend time in the current Sprint to refine work for upcoming Sprints.

• 39% usually don’t have an Increment that can be shipped at the end of a Sprint.

• 31% occasionally or often cancel the Sprint Review.

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

The Benefits of Shipping Fast

Can you afford to burn money on features that have little to no value? Are your stakeholders’ expectations of your product likely to remain the same? Do you have no competitors for your products? Can you predict, with absolute certainty, that your users or customers find value in your ideas?

Because you’re reading this book, we are willing to let you feed our juicy arms to a hungry zombie if you can do any of those things. Your need to ship fast is strongly tied to the inherent risks of the complexity of developing your product. If you ask us to capture the purpose of the Scrum Framework in one sentence, it is to deliver “Done” Increments to stakeholders with a frequency that is high enough to avoid wasting money and time on something that just doesn’t catch on with them. In other words, it’s all about learning as quickly as possible where the risks are and how to avoid or prevent them (see Figure 7.1). What is “fast enough” depends on your environment, your product, and your organization’s capabilities. But it’s probably closer to one or two weeks, or even a single day, than once every few months. The more complex your work, the faster you need to learn.

Figure 7.1 Why bother shipping fast?

Complexity in Your Environment

Because you cannot plan success in a complex environment, and you are able to understand it only in hindsight, successfully solving complex problems requires the use of feedback loops. You need to know what’s going on so you can make sense of the situation and react accordingly. The Sprint Review is only partially helpful in this regard if it is used to inspect your product and validate assumptions within the boundaries of your organization. Shipping fast allows you to inspect your product within the environment in which it’s actually used. And this is what really counts; you get fast feedback on your product and learn from that feedback as quickly as possible. Was your thinking correct? How does the market react to your ideas? What do you need to adapt?

Shipping fast also allows you to respond to changes in the market more quickly. Imagine seeing an opportunity and actually being able to exploit it within a few weeks. Organizations that are burdened with long release cycles simply miss these opportunities, mired in their own ineffectiveness as competitors snatch them up. When you’re able to ship fast, you can turn ideas into value within a short time frame, depending on what the business needs. That’s what agility means.

Contrast this with virtually all the Zombie Scrum organizations we’ve seen: They shut themselves off from the outside. They become mindless machines, churning out huge piles of features in big-bang releases. The rare feedback they receive from the outside requires a lot of time to be processed and usually doesn’t reach the people building the product in time. These organizations stumble along like stiff zombies, losing a limb here and there but not really noticing a difference.

Complexity in Your Product

One characteristic of complex problems is emergence. Here, seemingly straightforward activities result in a cascade of unexpected work. These are the “uh-oh” moments when developers catch on to the fact that what was assumed to be a small change turns out to be much more challenging than imagined. For example, when a stakeholder casually asks if the feature supports an obviously crucial mobile device, and the whole Scrum Team collectively facepalms because nobody ever considered that. Or when a Scrum Team works deep into the night to resolve an ever-growing list of issues that arise during the deployment of a large and complicated release.

Work on complex problems has the tendency to rapidly snowball into more work than expected. Anyone who has worked on complex problems has learned, often the hard way, that it is better to start with a small, stable system and carefully grow it over time. Instead of integration hell at the end of a long-running project, we make tiny changes and get our system back to equilibrium as quickly as possible. This process constitutes a rapid feedback loop of adding instability (in the form of development work) and returning to a stable state. That way we avoid the sometimes-catastrophic effect of delaying integration work, which makes it much easier to survive in a highly dynamic environment.

Improvements in software development tools have made it easier to simplify and automate integration, testing, and deployment. As a developer, you can check in your code and trigger an automated pipeline in which changes are built, pushed to a test environment, and, if everything goes smoothly, pushed to production. This means that you can have new working software every couple of minutes. Not every business needs to operate at such a rapid pace, but this style of working dramatically shortens the time it takes for developers to obtain feedback. It lets them know immediately when they made a mistake and reduces the complexity of working on a product.

The Bottom Line: Not Shipping Fast Is a Sign of Zombie Scrum

Organizations that suffer from Zombie Scrum struggle to ship fast. Although they work in the rhythm of Sprints, new features are delivered to customers only occasionally (e.g., as part of a yearly release cycle), without a desire to increase the pace. Excuses for not shipping faster are usually that the product is too complex, technology doesn’t support it, or customers aren’t asking for it. They view shipping fast as a “nice to have” but fail to see that they are missing the benefits of obtaining frequent feedback on the quality of their work. The result is a vicious cycle: the zombified use of Scrum raises barriers to shipping faster, and not shipping faster amplifies the Zombie Scrum symptoms.

Why Are We Not Shipping Fast Enough?

If shipping fast is so great, and when everyone sees the potential, then 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 the people caught up in a Zombie Scrum system, and how it often emerges despite everyone’s best intentions.

No need to panic, recruit. Breathe in, breathe out. Breathe in, breathe out. What are you mumbling? Did you recognize all the symptoms? Ok . . . let’s panic! Just kidding. Recognizing the symptoms is a good first step. Let’s see what the potential causes are. So tell me, why do you think your organization isn’t shipping fast?”

We Don’t Understand How Shipping Fast Reduces Risk

In environments with Zombie Scrum, people don’t understand why it’s important to ship fast. When you ask them, they respond with a shrug. Or with a dismissive smile, because “that can’t possibly work for a product or organization as complex as ours.” For them, shipping fast is only possible for small products that don’t generate a lot of revenue or for huge tech companies like LinkedIn, Facebook, and Etsy. Even if they’d want to, the investment would simply be too large. It’s more convenient to keep batching many updates into large, infrequent releases. Honestly, this is not very different from seeing the appeal in a healthy lifestyle but refusing to do the frequent workouts to get there.

Signs to look for:

• Regardless of how much work Scrum Teams complete within a Sprint, features are batched into large quarterly or yearly releases.

• Releases are “all-hands” affairs where people clear their schedule for the evening and the next day(s) or even entire weekends to address issues caused by the release.

• “That doesn’t work here” is a common response from people when you explain that every Sprint should result in a new version of the product that can be released.

• People don’t have a clear answer when you ask, “What risks increase when we don’t ship faster?”

• Releases are large operations and include many changes, bug fixes, and improvements. A quick look at the release notes usually tells you enough.

All these responses show that people ultimately don’t understand that shipping fast is necessary to reduce the risk that comes with complex work. Ironically, the more complex the product or its environment is, the more important it is to use empiricism to reduce risks.

Figure 7.2 “Let us take shelter first before you hit ‘Release’ for the yearly deployment.”

For many teams, deploying a new version of their product hurts. Teams are on edge, worried about making a critical mistake. They prefer to deploy during low-traffic hours (in the middle of the night). Schedules for the days after the release are cleared to address the fallout in terms of bugs, issues, and rollbacks. It is no wonder that many teams choose to deploy as infrequently as possible.

But shipping fast is a form of organizational exercising. When Scrum Teams ship fast, they purposefully stress their processes, skills, and technologies. In response, they start to look for ways to optimize their work to deal with those frequent stressors. Scrum Teams are likely to increase their use of automation, create rapid fallback strategies, introduce techniques such as “feature toggles,” and find other ways to reduce the blast radius (that is, the impact) of a new release. Just as our muscles become stronger as they recover after we slightly damage them through exercise, releasing often helps organizations build capabilities where they matter most. Although some pain is unavoidable, and just as sore muscles give rise to increased strength and endurance, each release will be easier, faster, and less risky than the one before.

Obviously, these improvements happen only when it is the Scrum Team itself doing the exercising. When people outside the Scrum Team are responsible for releasing, the Scrum Team has no incentive to improve. The Scrum Team also needs to have control over the deployment process and the tools to automate deployments. The best Scrum Teams we’ve worked with treated automation as part of their work on a product. They made this work transparent on their Product Backlog and refined it into smaller items as needed. Rather than treating automation as an afterthought, they used their first Sprints to create the necessary automation to deploy their product Increment to production. In subsequent Sprints, they built upon this foundation with additional automation and monitoring. All the time they would’ve wasted on making, and recovering from, large deployments was spent on adding more valuable features to their product.

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

• Take the First Steps to Automating Integration and Deployment

• Ship Every Sprint

• Evolve Your Definition of Done

• Make a Business Case for Continuous Delivery

• Increase Cross-Functionality with a Skill Matrix

• Ask Powerful Questions to Get Things Done

We Are Impeded by Plan-Driven Governance

Some organizations clearly suffer from Zombie Scrum even though the Scrum Teams are doing a great job. They create potentially releasable Increments every Sprint. The quality of the product is high. And stakeholders are being involved wherever possible. But although the engines of the Scrum Teams are burning at top speed, the entire organization isn’t moving. Even though Scrum Teams are working in short Scrum cycles, everything else in the organization follows a much slower rhythm. We often see organizations create elaborate long-term project plans and yearly release schedules wrapped around the Sprints of their Scrum Teams. This is what we call plan-driven governance. Organizations using it completely miss the point that the purpose of the Scrum Framework is to enable inspection and adaptation.

Signs to look for:

• Product budgets and product strategy are set once a year or even less frequently.

• Product Owners can only release according to an infrequent annual or biannual release schedule.

• Decisions about what goes on the Product Backlog and in what order are tightly controlled by Project Management Offices and Steering Committees.

• The goals or potential content of each individual Sprint are planned months, sometimes even years, ahead.

• Requirements and anticipated work need to be extensively documented and planned, as made apparent in lengthy Product Backlogs with a high degree of detail even for items many Sprints into the future.

Plan-driven governance leads Scrum Teams to work toward a far-distant goal that does not relate to customer satisfaction or tangible business outcomes. Their success is often measured against meeting artificial deadlines that have nothing to do with creating value for stakeholders. When conformance to a plan is rewarded instead of the flexibility to get better results, shipping fast doesn’t make sense and looks like a waste of time. Even when the engines of Scrum Teams are burning at top speed, they are likely to burn out quickly as they get stuck in organizational muck. See Figure 7.3.

Figure 7.3 “After sixty years, we can finally validate those assumptions from our Sprint Planning.”

As we explored in Chapter 4, the Scrum Framework is based on learning from experience (or empiricism). In stark contrast, the processes and structures within organizations that engage in predictive planning are still shaped by the belief that problems can be rationally analyzed in their entirety before any actual work is done to address them (which is called rationalism). This analysis is captured in detailed product plans and associated road maps that don’t allow nor encourage adaptation as insights emerge when the work is actually done. The resulting product is shipped in one large release in an attempt “to get it right the first time.” This approach is not inherently wrong, it just doesn’t work in complex, unpredictable environments.

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

• Make a Business Case for Continuous Delivery

• Measure Lead and Cycle Times

• Measure Stakeholder Satisfaction

• Ship Every Sprint

We Don’t Understand the Competitive Advantage of Shipping Fast

Are stakeholders happy with the speed at which value is being delivered to them in return for their investment? Are new initiatives for internal stakeholders passed over because “the IT department will take years to get it done”? Are technical concerns used to scare those rowdy people from management and sales back into their lairs whenever they come running with new opportunities?

The stakeholders are the best place to start looking for signs that teams may not be shipping fast enough. These people have a real stake in what teams do, and they pay for it with their money or time, or both. But their loyalty will only go so far. When something better comes along—another product or a competitor—they may jump ship.

Signs to look for:

• The churn rate—the percentage of existing stakeholders that stop doing business with you—is high or increases.

• Stakeholders are generally unhappy with your responsiveness to their (changing) needs or use it as a reason to stop doing business with you.

• It takes a long time for Scrum Teams to resolve bugs that block stakeholders from using your product well.

• New initiatives are not being formed because “the IT department” needs to be involved. Everyone knows that this would take so much time that it doesn’t even make sense to talk to them in the first place.

• Prototypes and new products are being developed with external companies because they are able to develop solutions quicker and cheaper.

• Most of the time, new and better tools cannot be integrated into the current infrastructure, because integration would take a very long time and the effort outweighs the benefits.

Organizations that suffer from Zombie Scrum are unable to respond quickly to the business opportunities that flow from the changing needs of stakeholders. Sometimes it’s because everything IT-related is controlled by a small group of people who are unwilling to take risks or take on more work. Other times, the organization lacks the capabilities to ship fast enough. Either way, these business opportunities don’t last forever, so when an organization can’t respond quickly, it misses out entirely.

Experience: The False Promise of the “Castle in the Sky”

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

I recently spent time with a Scrum Team that worked for a web agency. They’d spent the past two years working on and off on a new content management system (CMS) that would replace their existing decade-old platform. Although it had served them well in the past, the old CMS had become a bane for their customers. It worked marvelously in a ten-year-old browser, but it didn’t work well in anything more recent. The performance was so bad that it zombified users on its own. The old platform lacked support for mobile devices, modern media formats, and rich text editing. But with nothing released, customers perceived the new platform as nothing but an empty promise as the team kept postponing its release in order to add more mind-blowing features. Not surprisingly, the company struggled to convince new customers to do business with them. Existing customers jumped ship to competitors as soon as they saw an opportunity. Needless to say, this team had to rethink their entire approach in order to remain in the market.

This dynamic also applies to Scrum Teams that work on internal products. One of the authors of this book worked for a company that built software for payrolling. When the company was acquired by one of the largest payrollers in the market, many of their business units started moving their product development from the shared IT department to the acquired company—much to the disappointment of the IT department. As it turned out, the acquired company used more modern technologies and was able to release biweekly, creating more opportunities for customers to inject new ideas and capitalize on market changes.

In a marketplace where technologies, practices, and needs change rapidly, shipping fast is essential to remaining competitive. As the example shows, shipping fast becomes an asset by enabling organizations to adapt to changing needs more quickly than competitors. It can be leveraged to experiment and learn faster.

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

• Make a Business Case for Continuous Delivery

• Measure Lead and Cycle Times

• Measure Stakeholder Satisfaction

• Ship Every Sprint

We Don’t Remove Impediments to Shipping Fast

Even when organizations and Scrum Teams see the benefit of shipping fast, they still end up with Zombie Scrum if that knowledge does not translate into a sustained effort to remove the impediments that are getting in the way of doing so. Potential impediments are the following:

• A lot of work happens after a Scrum Team “completes” the work as part of a Sprint. For example, a QA department has to perform quality assurance in another Sprint. Or the marketing department has to write text and add pictures.

• Scrum Teams encounter delays when they depend on people outside the team to do work for them and those people are too busy.

• Completed work is batched up into large, infrequent releases.

• The skills in a Scrum Team are distributed in such a way that it causes bottlenecks.

• Scrum Teams struggle to break down their work sufficiently (for more on this, see the next section).

• Scrum Teams do not have access to the tools or technologies they need to ship faster.

• The quality of work done by the Scrum Team is too low, which causes significant rework on items in their current or next Sprint(s).

In organizations with Zombie Scrum, there is no attention to cycle time, the time that transpires between when work is picked up and when it is delivered to stakeholders. Cycle time tells you a lot about how comprehensive a team’s Definition of Done is, how they collaborate, and what other impediments are getting in the way of shipping fast.

Signs to look for:

• Scrum Teams don’t track their cycle time at all.

• The cycle time of Scrum Teams remains high or increases over time.

• Scrum Teams don’t explore what is impacting their ability to ship fast.

When the cycle time is equal to or less than a Sprint, teams are demonstrably capable of starting work on an item and deploying it within the same Sprint (or immediately after). Low cycle time helps reduce the risks that are inherent to complex problems.

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

• Evolve Your Definition of Done

• Measure Lead and Cycle Times

• Limit Your Work in Progress

• Slice Your Product Backlog Items

• Increase Cross-Functionality with a Skill Matrix

We Work on Very Large Items during a Sprint

Shipping fast is an awesome way to reduce the risk of complex work, but it works only when what is shipped conforms to the team’s Definition of Done. Releasing untested work is a great way to damage your brand, alienate customers, and take unnecessary risks.

Although releasing partially done work is a bad idea, what happens when the items on a Sprint Backlog are so large the Scrum Team can’t complete them within a single Sprint? This usually means that remaining work on that item has to be carried over into the next Sprint, where the team now has even less time to work on new items. As the team keeps rolling items forward from Sprint to Sprint, their problems compound and they increasingly feel that their Sprints are artificial time boxes in which nothing ever really gets done, let alone shipped.

Signs to look for:

• Frequently, items on the Sprint Backlog are so large that a Scrum Team can’t complete them within a single Sprint.

• Scrum Teams have only a few large items on their Sprint Backlog instead of many smaller ones.

• Scrum Teams don’t spend time refining work for upcoming Sprints.

The best way for the Scrum Team to overcome this challenge is not for them to work harder, to add more people to the team, to relax their Definition of Done, or to buy larger sticky notes (see Figure 7.4), but to break down items that can’t be finished in a single Sprint into smaller items that can be. It’s important that teams break work down in such a way that the smaller items are still releasable in their own right. Otherwise, they won’t be able to learn and receive feedback on them.

Figure 7.4 The size of your sticky notes is also a good sign that your items are too large.

Developing the skills and creativity to break down large items of work into smaller ones is one of the most important skills for Development Teams to learn. Instead of starting work on any item by writing code, a Development Team should learn to continuously challenge itself by asking: “What is the smallest possible thing we can build and deploy to learn more or increase the value of what we are delivering?”

Refinement both requires Scrums Teams to apply those skills and provides them with an opportunity to develop them. When Scrum Teams don’t refine their work, or when they focus solely on writing specifications, they inevitably struggle with large items on their Sprint Backlog. Some of this refinement takes place within the Sprint, where other refinement happens before a Sprint. Either way, work flows much more smoothly through a Sprint when sufficient refinement has taken place. When we work with Scrum Teams, we try to get them to anticipate their work two or three Sprints ahead by breaking down large items. Techniques such as T-shirt sizing can help discover those XL or XXL items with relative ease, breaking them down first, then moving on to the L- and M-size items.

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

• Increase Cross-Functionality with a Skill Matrix

• Limit Your Work in Progress

• Slice Your Product Backlog Items

• Ask Powerful Questions to Get Things Done

Healthy Scrum

In Healthy Scrum, Scrum Teams work in a Sprint-based rhythm where every iteration results in a new version of the product, the Increment, that can be potentially released. At the end of a Sprint, the Increment should be in such a state that it can be deployed with the proverbial press of a button: all testing has been done and quality is assured, installation packages are ready, and support documentation has been updated. Whether or not to release it is up to the Product Owner, but if they decide to release, it can be initiated right after the Sprint Review. If the Product Owner decides not to release, the work the team has done will be released as part of a subsequent Sprint. Either way, the work the team put into getting everything release-ready wasn’t wasted.

Okay, Recruit! Still with us? Now that you know the symptoms and causes of not shipping fast, let’s explore healthy Scrum. Yes, I know, the situation was bad, but it doesn’t have to be like that. Let us share what shipping fast looks like. Just relax, take a seat, perhaps do five minutes of meditation and continue reading . . .”

Deciding to Release (or Not)

The Product Owner makes the final decision to release the Increment, informed by his or her interactions with the Development Team and stakeholders. Even when the Increment is fully ready to release (that is, it meets the Definition of Done), the Product Owner may decide to postpone it when a release:

• Would bring the product into a state where it is more likely that users will run into issues, problems, or bad performance. For instance, a critical business rule may not be working well or feedback from stakeholders during the Sprint Review wasn’t positive.

• May require work from stakeholders that is unacceptable at this time. This is particularly evident in products that also (or entirely) involve hardware. Stakeholders would probably run away in droves if they had to replace the hardware every Sprint.

• Would bring the product into a state where it doesn’t comply with legal or fiscal requirements.

• Would bring an avoidable risk for the brand, organization, or product based on current market conditions. For example, releasing new cash register software during the peak of the Christmas shopping season could be postponed by one Sprint if nothing is broken.

In organizations that suffer from Zombie Scrum, each reason could easily turn into an excuse to release once a year or only when the product is “entirely done.” But in environments of healthy Scrum, Product Owners understand that frequent releases are the best way to mitigate the risk of complex work. They also understand that the reasons not to release indicate deeper, hidden impediments that need to be resolved. For example, if releases frequently don’t take place because it is difficult to continuously retrain users, it begs the question why small incremental changes necessitate continuous retraining in the first place; perhaps the Scrum Team needs to work on improving the usability of the product so that users don’t need to be retrained.

Releasing Is No Longer a Binary Action

Product Owners are continuously making trade-offs; they understand that there is a whole field of options between “release nothing at all” and “release everything.” Organizations that suffer from Zombie Scrum often see a “release” as something that either happens or it doesn’t. But when organizations practice healthy Scrum, they understand that there are many different release strategies. For example, a Scrum Team can do the following:

• Deploy Increments to production while keeping new features disabled with so-called “feature toggles” that are “turned on” once a coordinated marketing campaign gets underway.

• Deploy new increments in a staged manner, starting with users who are eager to experiment and accept the risks of new features, then moving on to more risk-averse users. The practice of deploying new releases in a series of alpha, beta, and final releases is a good example of this option. Another example: the “Labs” feature that many products offer to allow users to turn on experimental new features.

• Deploy new Increments as alternatives. For example, LinkedIn frequently deploys new features where users can choose between a new and an old version of a screen.

• Deploy new Increments to a small group of users first and monitor closely what happens. When this “canary in the coal mine” doesn’t show problems, expand the release to ever-larger groups.

• Deploy a new Increment as a version that users can opt in to. This is particularly common among hardware-based products, where users can decide to stay with their current (and supported) version or switch to a newer one.

• Deploy new Increments through a “soft launch” where new features are made available to users, but the marketing campaign to draw more attention to it starts later.

What these strategies have in common is that they enable teams to release their Increments in many small releases over time, instead of a few large ones. By doing so, they reduce the risk of each release by limiting the blast radius in complementary ways. Scrum Teams can also test new ideas faster, as each strategy gives them rapid feedback on what is happening and how people are using the product. For example, tracking the number of users that revert back to an older version of a feature is a great indicator that the new version needs work.

Obviously, these strategies require a well-tuned process and technical infrastructure to make this approach possible. Not all products are initially capable of being released in this manner.

Experience: Frequently Releasing a Mission-Critical and Rigid Product

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

One of our Scrum Teams was responsible for a comprehensive and mission-critical product for managing workers on flexible schedules. It included features to match workers to jobs, to submit and approve hour sheets, to track vacation days, and generate detailed management reporting. The product also communicated with a variety of external systems. Any disruptions would immediately cause ringing phones in our office, as thousands of people depended on it to do their day-to-day jobs.

The first version of the product evolved over a two-year period, where the bulk of the work was done by a single developer. When that developer left, a Scrum Team took ownership of it. This confronted them with a challenge. The poorly structured, monolithic code base meant that it was impossible to release parts of the product; it was really all or nothing. And the risk of failure was high. Wanting to stick to frequent releases, the team initially did its releases during off-hours—usually at night or during weekends. To make this approach easier, the Scrum Team strategically started rebuilding parts of the product in parallel with technologies that allowed isolated deployments and automated testing. The team made clever use of technology to keep the experience for users integrated. In many cases, they would lift out entire parts of a commonly used dashboard and move it into a separate web application, while keeping it visually part of the same dashboard. In other cases, new versions of a screen were transitioned by initially offering them as a suggestion, then making them the default (with the option to go back) and finally as the only option. At the same time, the team worked hard to automate their deployment pipeline.

This concerted effort to keep releasing frequently, and to build the muscles and skills needed to do so, allowed this team to move to a state where they can now release during work hours, with almost no risk, and as often as they want.

Shipping during a Sprint

The biggest benefit of improving shipping speed, even when it involves big changes to process and infrastructure, is that it helps organizations build the muscle to respond ever more quickly to what matters to stakeholders. This is not just reactive, in which Scrum Teams respond to stakeholders’ requests, but also proactive, in which Scrum Teams monitor how users interact with the product to gain insights into ways to improve user experiences before the users ask for them.

To respond to these new opportunities, Scrum Teams need not wait for the end of the Sprint to release some new improvement. The Scrum Framework encourages teams to be able to release at least at the end of a Sprint. If they can release more often, even better! So it’s only natural that Scrum Teams eventually move into a process where tiny releases happen continuously throughout the Sprint. This has the added benefit of making the various Scrum Events even more focused on inspection and adaptation based on realistic, live data.

No More “Big-Bang” Releases

Scrum Teams that have developed the capability to ship fast sometimes confide in us that there’s one thing they miss: the big yearly release party. In the old days, a release was a nerve-racking activity where teams would clear their schedule (and their evenings) to deploy huge Increments to production. With such a huge number of changes, the potential for disaster was equally huge, meaning that teams often scrambled to find fixes for a host of unexpected issues. For such a high-stress, high-pressure activity, it makes sense that the release party was that one moment to collectively sigh with relief for having survived another one. Yes, it’s true that teams that ship fast don’t “live on the edge” anymore.

Thankfully, release parties can still be had. Even in environments where the product is in a constant state of flux, Scrum Teams still have important milestones to meet, targets to achieve, and stakeholders to satisfy. Instead of celebrating the admittedly awkward achievement of having “survived a release,” they have more valuable things to celebrate.

Now What?

In this chapter, we explored common symptoms and causes for why Zombie Scrum Teams are not shipping fast enough. Instead of a luxury or a nice-to-have, shipping fast is one of the most effective ways to mitigate the uncertainty and risk of complex work. It is at the heart of Empirical Process Control. By shipping fast, there are many opportunities to validate assumptions about your product and make adjustments as needed. In the world of complex work, shipping fast really is both a survival strategy and an asset.

Is your Scrum Team or organization struggling to ship fast? Don’t worry. The next chapter contains a slew of experiments, strategies, and interventions you can use to start your recovery.