March 10, 2015

When to press the Emergency Stop Button

Agile and Lean wisdom teaches us that hitting the stop button is something best avoided.

Seymour Cray’s 1964 supercomputer had an Emergency Stop button on the operator’s console. It’s at 5 o’clock to the right-hand ‘bug’s eye’. The CDC 6600 ran silicon transistors rather than the high voltage and high temperature valves of earlier computers, so what would cause anyone to press stop?

Workers at Toyota’s plants are told of the cost per minute, of stopping the production line. Any worker can pull the line-stop cord.

In Agile Scrum, the Product Owner is the only person who can halt work mid-sprint.
Hitting stop initiates a costly cycle of waste: machines and people pause mid-task, often at the most inconvenient moment; people get diverted by the cause of the stoppage; restarting and getting back ‘up to speed’ mentally or physically takes time; and post-incident reviews represent a substantial investment.

Due to the short duration of Sprints, cancellation rarely makes sense

In the Agile case, the cost of stopping is calculated as: the entire team’s time cost from the start of the sprint, including the planning meeting and preparation for that meeting, to the end of the replacement planning meeting.

It’s the job of the Scrum master or Agile coach to explain these costs to the Product Owner, who should be prepared to explain his/her justification for taking the action. It’s not just the budget-holders that are owed an explanation, but the development itself. All are stakeholders.

What event could cause a Product Owner to stop the sprint?

Hopefully, the business is able to remain committed to its plan for the few weeks until the next planning meeting.

If it seems like too long to wait for the next planning meeting, then consider shortening the sprint length. Three to four weeks is ideal, but established teams may prefer two week cycles. Anything less, and the overhead of meetings gets in the way.

Although I’ve never had to stop a sprint (I’ve stopped the stopping a few times), the candidate reasons I think of would be external. If the client cancels their order, or if legislation renders the product non-viable. Either way, it’s not just the sprint that’s cancelled, but the project itself. In the words of the Scrum guide “a sprint would be cancelled if the sprint goal becomes obsolete.”

What about the discovery of a flaw in the architecture, or uncovering an incorrect assumption?

These incidents do happen and the team should be congratulated for having the courage to raise them. They don’t change the business drivers though, and are best seen as really nasty bugs that need fixing. Usually the Product Owner will decide they can be fixed in a later sprint, and will adjust the sprint / release plans accordingly.

The Future of Agile Leadership

Introduction The future of leadership is Agile There are many different types of leadership styles and not all work well in every situation. The most popular method, the "Command and Control" style which has been…

Business Agility Leadership Coaching (BALC) at HSBC

Business Agility Leadership Coaching (BALC) emerged as a consequence of asking leaders and managers across HSBC how they wanted to improve their agile leadership. Our proposed solution hit a sweet spot because we were 100%…

What does focussing on culture mean to XYZ Consulting?

We have some mid-tier consultants in at the moment who are "focussing on culture." Since we don't separate culture from delivering value to customers, I asked what that meant in practice. Apparently: "A generic scheme…

Visualising Progress using the Stand-up Game

We had a (brief) discussion about tracking progress as a team. I reacted against Jira because a) I dislike the user interface as it's a collaboration killer, and b) we aren't a software development or…
1 2 3 20
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram