Emergency Procedure

(Stop the Line)

Jeff Sutherland’s colleague Ed Atterbury getting shot down over Hanoi by a SAM Missile. You can see him bailing out!

... companies, teams, and individuals often find their efforts failing to deliver on time and the Sprint Burndown Chart shows failure is virtually certain. Rapid identification of problems and quick response is fundamental to the spirit of agility.

✥      ✥      ✥

Problems arise in the middle of a Sprint due to emergent requirements or unanticipated changes. By mid-Sprint it may be obvious that the Sprint Backlog cannot be completed successfully. The team is high on the Sprint Burndown Chart and sees that they cannot achieve the Sprint Goal at the current rate of getting things done.

Causes of Sprint dysfunction are legion and this pattern focuses primarily on the top three of these common problems:

Agility requires rapid response to change, and that means making problems visible as early as possible. Unfortunately, new teams and average teams often do not want problems to become visible. In particular, they do not want to stop work, fix problems, and risk criticism. At the first NUMMI Toyota plant in America, Japanese management visited the plant after six months and saw that employees had not stopped the line enough to fix their impediments. The management pulled the andon cord to stop the production line in order to communicate to the workers that their biggest impediment was their reluctance to stop the line and things were not getting fixed properly. “No problem is a problem” is the Japanese management mantra. [1]

The Product Owner needs to be consulted when things are not going well. Not only that, it is necessary that the Development Team agree with the Product Owner on how to quickly address major problems that affect reaching the Sprint Goal.


When high on the burndown try a technique used routinely by pilots. When bad things happen, execute the emergency procedure designed specifically for the problem.

Do not delay execution while trying to figure out what is wrong or what to do. In a fighter aircraft you could be dead in less time than it takes to figure out what is going on. It is the responsibility of the ScrumMaster to make sure the team immediately executes the Scrum Emergency Procedure, preferably by mid-Sprint, when things are going off track. This will require careful coordination with the Product Owner, yet kaizen mind requires execution of this pattern even when the Product Owner is not available. Great teams act without permission and ask for forgiveness later (see Community of Trust).

Scrum Emergency Procedure: (do only as much as necessary)

  1. Change the way the work is done. Do something different.
  2. Get help, usually by offloading backlog to someone else.
  3. Reduce scope.
  4. Abort the Sprint and replan.
  5. Inform management how release dates will be affected.

Teams often want to reduce scope when they encounter difficulty. Great teams find a way to instead execute a different strategy to achieve the Sprint Goal. In the 2005-6 football season John Terry, Chelsea’s captain and center back, had to take over as goalkeeper in a game against Reading after Petr Cech suffered a fractured skull, and then the substitute goalkeeper who replaced him, Carlo Cuddicini, was carried off unconscious before half-time. Terry made two fine saves and Chelsea won the game 2-0. Similarly in software, adopting new practices that remove waste can multiply performance while drastically cutting effort.

When multiple teams are working on the same products, one team can often pass backlog to another team who has slack. PatientKeeper [2] automated this strategy. If a team was behind it could assign Sprint Backlog Items to another team. If the second team could not take it they passed it to a third team. If the third team could not take it they had a meeting of all three to decide what to do. This automatically leveled the loading of backlog across teams so they could all finish together.

Reducing scope early so the team can finish planned work is better than coasting into failure. The organization can inspect and adapt to problems rather than be surprised. See Teams that Finish Early Accelerate Faster.

Aborting the Sprint (stop the line) may be the best option, particularly if the team consistently fails to deliver. Only the Product Owner may decide whether to abort the Sprint: as bad as things may be, the Product Owner may judge that the business payoff may not be worth it, or that aborting the Sprint may otherwise have long-term negative consequences in the market or the business.

After terminating the Sprint the team typically convenes a brief Sprint Planning for an abbreviated Sprint (to stay on cadence; see Follow the Moon) to achieve the Sprint Goal if possible and to deliver as much value as possible. Alternatively, the team may convene a more protracted Retrospective to explore and rectify problems in the environment and the team’s Scrum implementation, and then re-plan and move on to the next Sprint. But, again, much of the value in Sprint termination comes in making it publicly visible that there are fundamental impediments that keep the team from doing their job. A visible problem is one that can be fixed.

Sprint termination sends a strong message throughout the organization that something is wrong and increases the capability of removing impediments that cause failure.

The Scrum Team executes this pattern, and it is particularly useful for high performing teams. For teams that are serious about Kaizen and Kaikaku, Scrum is an extreme sport and they enter into a Sprint with some risk in order to go faster. Their primary risk is emergent requirements or unexpected technical problems as the team has addressed most other causes of failure. This pattern may be required every third or fourth Sprint, particularly with teams implementing new technologies and pushing the state of the art. However, for most emergencies, great teams will recover and meet Sprint Goals. And if they stop the line (abort the Sprint) they will poka-yoke [3] their process so the same problem does not happen repeatedly.

Poka-yoke (ポカヨケ) [poka joke] is a Japanese term that means “fail-safing” or “mistake-proofing.” A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur. [4]

Making problems visible is part of kaizen mind; see Kaizen and Kaikaku.

✥      ✥      ✥

The team will learn to rapidly respond to change in a disciplined way and overcome challenges. In many organizations when things are not going well, teams are not thinking clearly, are frustrated and demotivated. They fail to understand the cause of their problems and the way to fix them. Executing the Emergency Procedure will train the team to focus on success and systematically remove impediments. Great teams will surprise themselves on their ability to overcome adversity and move from strength to strength. It increases chances for successfully delivering a Potentially Shippable Product Increment both in the short term and long term. The team will feel it is doing all it can when using Emergency Procedure to get back on the right track, out of both Team Pride and Product Pride.

You can use Emergency Procedure in a more disciplined way to raise transparency into unmanaged requirements with the pattern Illegitimus Non Interruptus.

See also Take No Small Slips.

This pattern anticipates use by highly disciplined teams. If a team is using this too often (e.g., more often than once every four Sprints) and is not improving their value, quality and rate of delivery, then the team might reflect about whether something is fundamentally wrong in their environment or in their use of Scrum. It is usually better for young teams to do their best to deliver, to take the Sprint to the end, and to fail the Sprint. Then, away from the heat of battle in the Sprint Retrospective the team can explore the drivers for failure and plan kaizen.

[1] John Shook. “How to Change a Culture: Lessons from NUMMI.ˮ In MIT Sloan Management Review 51, Winter 2010, pp. 63-68.

[2] Jeff Sutherland. “Future of Scrum: Parallel Pipelining of Sprints in Complex Projects.” In Proceedings of Agile Conference, Denver, CO: IEEE Press, 2005.

[3] Mike Rother. Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results. New York: McGraw-Hill, 2009.

[4] —. “Poke-yoke.ˮ Wikipedia. (accessed 13 September 2017).

Picture from: National Museum of the U.S. Air Force photo 090605-F-1234P-021, http://www.nationalmuseum.af.mil/Upcoming/Photos.aspx?igphoto=2000558698 (in public domain).