When to unleash the Kraken
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 tremendous 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, and 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 the 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 Zeus saying, “Release the Kraken!” Please do not do it unless you are confident. Otherwise, it is like pulling a fire alarm because you do not want to attend class.
The following are the rare reasons why a scrum master ought to terminate a sprint.
Project funding has changed drastically-
Projects get canceled in an uncertain global economy, 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 following steps to pursue.
The Product Owner is fiddling with a sprint while it is in progress-
I worked with a product owner under so much pressure they needed help to prioritize work. Sprints would begin, and stories would be swapped out with others. Things that 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 to 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. A week later, the developer admitted the change affected other systems, and that 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, realizing it is more complicated than first expected. If your development team has 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.
It's a favorite movie from my childhood.
Comments ()