Sprint’s silent killer

Scrum Master tip #4

Encourage the team to monitor the number of ASAP tasks

Sprint is in progress, but everyone knows that ASAPs can always appear and take the form of small tasks to be handled on the spot or complex processes requiring research and digging into the code. And usually there is somebody in the team who manage such things, because he has a wide knowledge and experience, which allows him to solve problems as quickly as possible (because he knows where to look for the causes). Unfortunately, this kind of unplanned work suddenly reduces the availability of such a person, and the priorities in a sprint start to fade away. As a consequence, at the end of the sprint it turns out that the goal is endangered....

Does that sound familiar? Every scrum team deals with this type of situation, and the book "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” (authors: G. Kim, K. Behr, G. Spafford) describes it superbly. We meet Bill, who becomes vice-president for IT and immediately gets a million problems, which, in addition, accumulate and are all VERY IMPORTANT and VERY URGENT. There is also Brent, who has "secret" knowledge - he knows what others don't know, knows dark places of the code that nobody wants to touch and solves most of the urgent tasks. There is pressure from up top, there is doing tasks on the side, there is a mess and poor control.

As you can guess, or you know from your own experience, all this makes the implementation of planned work drag on forever, planning is difficult due to repeated unpredictability and constant context switching. That's why Bill, the main character of the book, started asking himself questions:

• What makes work in progress a "silent killer"?
• All the problems that only take a moment to solve, come to Brent - how long does it take him to fix these little things?
• Is there a place we record these additional tasks? Do we know how many of them there are for a sprint?
• How much of a planned work is finished?
• Is there anyone who has a broader view on team dependencies and changes?

Such questions should be asked by each team, identifying their "Brent" and constraints beforehand. It is worth to do everything to gain control over ASAPs i.e. unplanned work. They extend the deadlines for planned work, which results in increased costs. In addition, such urgent tasks often turn out to be unnecessary in the long run, and the time spent on their implementation - wasted.

Therefore, it is worth monitoring the number of ASAP tasks and determining the procedure of their flow (e.g. first they are transferred to the Product Owner, who decides what to do with them). Only in this way we will be able to control the already complex process of software development and make our work effective.

P.S. I highly recommend the book "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” (authors: G. Kim, K. Behr, G. Spafford) to both developers and business people. It opens your eyes and gives you a lot of reflection on the way you work.