Emergency Procedure

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 the Sprint Goal cannot be achieved at the current rate of getting things done.

Causes of Sprint dysfunction are legion and this pattern focuses primarily on 1-3 below:

  1. Emergent requirements
  2. Technical problems
  3. Loss of critical people or capabilities
  4. Overestimated capacity (use Yesterday’s Weather)
  5. Unplanned interruptions (use Illegitimus Non Interruptus)
  6. Previous work not done (use Definition of Done)
  7. Product Owner changes backlog (use Product Owner)
  8. Management interference (use Involve the Managers)

Agility requires rapid response to change, yet new teams or 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. [2]

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

Therefore:

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.

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 execute a different strategy to achieve the Sprint Goal. When the Chelsea soccer team could not move the ball across midfield they would pass the ball back to their goalie who could kick the ball way downfield. This was a key to winning the championship. Similarly in software, adopting new practices that remove waste can double performance while cutting effort in half.

Often a team can pass backlog to another team who has slack. PatientKeeper [3] 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. This sends a strong message throughout the organization that something is wrong and increases the capability of removing impediments that cause failure.

This pattern is executed by the team and is particularly useful for high performing teams. For hyperproductive teams, 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 they have fixed 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 [1] 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. (Wikipedia)



Kaizen (改善), Japanese for "improvement", or "change for the better" refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, game development, and business management. Kaizen is a daily process, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work ("muri"), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes. Wikipedia

✥      ✥      ✥

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 when using Emergency Procedure to get back on the right track, out of Product Pride.

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

References:

[1]  M. Rother, Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results: McGraw-Hill, 2009.

[2]  J. Shook, "How to Change a Culture: Lessons from NUMMI," MIT Sloan Management Review, vol. 51, pp. 63-68, Winter 2010.

[3]  J. Sutherland, "Future of Scrum: Parallel Pipelining of Sprints in Complex Projects," presented at the AGILE 2005 Conference, Denver, CO, 2005.