When to Unleash the Kracken

Make sure you mean it!

I have called being a Scrum Master many things.  It is a coaching role.  Being a scrum master can resemble being a therapist.  I have even compared being a scrum master to a parish priest.  The job is not easy.  A scrum master has plenty of late nights and early mornings.  One of the things they discuss in training for Scrum Masters is an important responsibility.  A scrum master can terminate a sprint.  Trainers don’t often consider this awesome responsibility but this week I will.

When things go badly in spaceflight mission control can terminate the mission.  When that happens, the astronauts turn the ship around and head back to earth via the shortest route.  When things go wrong on a scrum team, we have what is called an abnormal termination.  The sprint ends immediately, the team does a retrospective and plans a new one.

There is a contentious debate in the Agile community about who has the right to terminate a sprint.  I belong to the ideological camp that a scrum master should have this terrible duty.  I feel this way because the scrum master is the protector of process and improvement of the team.  When the Product Owner or the development team is in a hopeless situation, it is up to the Scrum Master to recognize it and take draconian measures.

Terminating a sprint is a huge deal.  Do not do this lightly.  It should be the plan “C” or “D” for any sprint.  Terminating a sprint creates all sorts of attention in an organization and is profoundly disruptive.  When a Scrum Master kills a sprint, it is the equivalent of Zuse saying, “Release the Kracken!”  Do not do it unless you are certain.  Otherwise, it is like pulling a fire alarm because you do not want to go to class.

The following are the rare reasons why a scrum master ought to terminate a sprint.

Project funding has changed drastically-

In an uncertain global economy, projects get canceled, and new ones are spun up.  These events impact your plans.  If this happens, the scrum master may want to terminate the sprint.  The termination will give the Product Owner, development team, and Scrum Master a chance to take stock and decide what the next steps to pursue.

The Product Owner is fiddling with a sprint while it is in progress-

I working with a product owner who was under so much pressure they could not prioritize work.  Sprints would begin, and stories would be swapped out with others.  Things which were a priority during sprint planning would be dropped days before the end of the sprint and replaced with stories of equal size.  The development team was forced to try and do the same amount of work in half the time.  Confronted with this bad faith behavior, I hit the self-destruct button and brought it to the attention of my Vice President. Leadership replaced the Product Owner in the aftermath.  The development team resumed sprinting.

The team grossly underestimated the work they could do in the sprint-

We have all had the “ten-minute change,” conversation. A product owner or someone from the business asks for a change to the system.  The developer listens to the request absentmindedly and says the change takes approximately ten minutes to perform.  A week later the developer admits the change affected other systems and it would take longer than expected.  Soon the rest of the development team is sucked into correcting the situation.

As my mentor, Angela Duggan would say, “developers are afraid of looking incompetent or unskilled.” This fear pushes software developers to underestimate work.  The team commits to something and then realizes it is more complicated than first expected.  If your development team has with six weeks of work in a three-week sprint, it is acceptable to hit the reset button.

These are three of the rare situations where you might terminate a sprint.  If you have other suggestions, I would love to hear them.

Until next time.