If a Scrum Team Wants to Respond Fast to Unexpected Tasks, it should take the fast lane

What is the relatively small step we can take to facilitate the addition of changes and surprises to a Sprint?

Each Scrum team must also deal with unexpected tasks. So it goes. In today's reality, it would be illusory to believe that it is possible to plan a one-week, two-week or longer sprint without running into surprises.

In fact, in almost every new team in which I come to implement Scrum, the obvious question arises: "But how can we handle unexpected tasks?" And indeed this is also something that does actually happen, usually when the team already has a backlog: "suddenly" a surprise appears, in the form of a manager or someone else who wants to add a new element which was not discussed in that Sprint’s planning meeting. This in itself creates confusion: how to add it? Who will add it? How will it be managed? How to ensure that the tasks outlined in the planning meeting are not compromised (or perhaps they should be)? And more.

This confusion also has a price, certainly when introducing Agile to an organization which is unfamiliar with it. The price may also be manifested in frustration and anger at the management team, who say one thing (Sprints, Agile, backlog) and do another (continue instilling chaos into the day-to-day work of the delivery teams).

** In my opinion, it is not strictly necessary to switch to Kanban (For those who have heard of it). I personally like working with Scrumban; and anyway, Scrum is currently common in many organizations, so that finding an easy and immediate solution for the Scrum team is preferable over the alternative, which requires completely replacing the entire toolset and switching to Kanban.

One important assumption to ‘calibrate’ before we start: The organization must remain able to introduce surprises, meaning to respond to the needs of the market on the spur of the moment. That is the nature of the current market: fast, quick, complex... surprises and changes are something we must learn to deal with if we are to survive. This is further complicated by the fact that we have to learn to deal with them while still staying productive, maintaining quality and keeping the pace. We, as development units, have to provide this infrastructure, this flexibility, both in the procedural level (as I will demonstrate soon) and of course in the level of the code’s quality and the ability to take a working piece of code at any given stage and change direction (but this is beyond the scope of this article, and is more in the realm of Dev Ops, CL, testing, etc.)

In this state of affairs, what is the relatively small step we can take to facilitate the addition of changes and surprises to a Sprint? Let’s solve this conundrum.

What is a surprise? In effect, a surprise is first and foremost any task which we could not have planned for, which appeared when it did because “we did not know of it in advance”. E.g., customer bugs, urgent customer needs, urgent product changes and more. It is something that cannot wait for the end of the sprint and needs the immediate attention of the team members.

So what do we do?

1. Build a fast lane – or as the team refers to as "a highway".

The concept is simple and similar to a fast lane on the highway – a lane which goes faster than the others. This is it. The fast lane's goal is to allow cars to pass faster than in the other lanes. This is exactly what happens in the Sprint. Most of our tasks often have their own pace, but there are tasks that must go through now, faster, and we must clear a route for them.

A fast lane is meant to allow cars to pass by faster during rush hours and its price often changes according to the level of traffic. The same applies to tasks coming from the outside: their price differs according to their level of organizational urgency. Passing them through the Fast Lane requires discretion, an understanding of the price and a decision regarding whether it is worth paying or not.

http://drivinginstructorblog.com/rant-on-fast-lane-slow-lane-right-lane-wrong-lane)/)

On the task board, indicate your Fast Lane in a clear and separate manner – to enable you to separate between the planned and unplanned elements of the Sprint.

2. Put a price tag on your Fast Lane.

Determining the price of the Fast Lane is important in order to understand our capacity to handle surprises. How many are coming in? What kind? How much do they cost? Comparing between Sprints and proper control of this information can improve the way surprises are handled and the execution of ongoing development processes in the future.

Based on past experience, as early as in the Sprint planning meeting you should ask yourself: how much have we devoted to unexpected factors so far?

Was it 20, 30 or 40 percent of our Sprint?

You do not have to be overly precise. In your first time doing so, act based on your gut instincts and just go ahead and set the price tag.

For example, 30% of the past Sprint’s capacity was invested in dealing with unexpected events and thus we should make room for them accordingly.

This means that the Sprint backlog which will be presented to the entire team will be planned at 70%, and the additional 30% of the work that could potentially be designated (but will not be accounted due to the fact that we take a fast lane budget instead) will be left aside, in order to enable the team to take on additional tasks in case no surprises appear during the Sprint (but between us, there most certainly will be).

Thus, the team does not undertake a mission which it will not be able to accomplish, but responds better to changing circumstances by undertaking a more realistic mission – namely, 70%.

3. Measure your Highway and track its effect.

We must treat the Fast Lane as we would our bank account or budget.

During the project \ version \ Sprint we allocate budgets which we would like to track. Not because we do not want to exceed them if it becomes necessary to do so, but because we want to understand what is happening, to learn and to change our conduct if necessary.

So let's handle our Fast Lane as if it was a bank account.

Each entry into the Fast Lane reduces my remaining budget, which is monitored in the course of the Sprint.

Have we exceeded our budget? This is akin to overdraft. This is the message that should be reflected to the organization.

The team is responsible to reflect everything that has come in and how much it has cost us so far, what it means and which part of our budget has been devoted to the Highway.

For example, one way to reflect the Highway "budget" is via a burn down chart.

Another way, for example, is indicating it in different colors:

Green – good utilization. Meaning, a green fast lane indicates that considering the amount of surprising tasks coming in, we estimate that the allocated budget will not be exceeded and our condition is good.

Orange – towards the end of the fast lane budget, but not at risk of exceeding it or not at a medium or higher risk of compromising the regular Sprint tasks.

Red – increased capacity utilization with a chance to compromise the Sprint's normal track and consequently also the Sprint's regular tasks.

4. Add surprises wisely and plan ahead for how to pause ongoing work in an orderly fashion.

• Take the work currently being done into consideration: It is important to understand that the fact that we have allocated a track and time does not mean we can insert tasks into the fast lane chaotically, without adequate communication or adequate planning... After all, when a surprising task comes in the people are already working on something or another, which they have to finish before undertaking the additional task.
•     Ensure an appropriately sized backlog and proper Sprint pace to enable a quick stop – note that the ability to insert surprises into a Sprint is also related to the organization’s ability to produce an appropriately sized backlog for the team, so that stopping work will have minimal negative impact on the work which is currently underway.
• As with any Kanban, the smaller and better defined the task of each team member, the better their ability to finish it with minimal context switch and as a more complete and functional element.

• The shorter our Sprints, the better our ability to postpone in case of unexpected events without compromising our ongoing tasks (have I mentioned already that this is similar to Kanban?) The shorter and more focused the Sprint tasks themselves are, the better the team’s ability to stop what they are doing at the moment and add something new – with minimal negative impact on what is currently underway.

•          A surprising task enters through the Sprint backlog, coordinated with the PO and after the Scrum master has been informed.
•         At this stage pace ​​estimates are made to determine the price incurred by the surprising addition in terms of the ongoing work.
• When something comes in it becomes the responsibility of the entire team. However, before we take them off of any other task, it is important to understand just how urgent it is. When something enters the Highway, it should be clear that it is a matter which cannot wait until the end of the Sprint, must happen soon and hence it has been entered. This is the foremost consideration. But here too, it is important to understand what is being compromised, what must be finished before we start dealing with it and to what extent.

• An extremely urgent surprise might come in, one that cannot wait at all and must be dealt with immediately; in this case, we start working on it right away and inform the rest of the team later.
•          In all other cases, we find out when is the best opportunity to stop the ongoing tasks, and stop at a time when it is possible to introduce this surprising new element.
•         In any case the task’s entry is orderly, without panic. Panic will not solve the problem. Stop for a moment to understand what we are facing, what is the DOD, how to test it, who will work on it, have a mini-planning session, estimate the size and then insert it .

5. The Fast Lane is discussed as part of the daily scrum meeting.

I hope it is quite clear that in the Daily meetin you will also discuss matters which are in the Fast Lane. After all, they have an impact on the team’s day-to-day and the way in which they fulfill their Sprint obligations.

6. Inspect and adapt.

How do you ensure that this whole Fast Lane thing is not put to waste? That it only contains tasks which genuinely belong there?

In the Retrospective meeting, it is very important to discuss what has gone in there. Was it a real surprise or something we could have expected?

Did something urgent come in, or could it have waited?

What happened to our budget?

Why did it happen, what is the root cause of the events which led up to the surprise’s entry?

And what steps or rules should we adopt to better handle or reduce the size of our Highway in the future?

7. Pay attention to the contents of your Fast Lane.

This lane contains only tasks that come as a surprise – which were not planned for in the Sprint and could not have been there in the first place.

This is not an obscure and empty buffer into which we can throw in all sorts of delays.

It does not contains bugs we discovered in the process of developing, as these are accounted for as part of the Sprint’s work.

It does not contain the whims of some individual or another, or side jobs of some manager or another, which become part of the Sprint in ‘shady’ ways.

Sometimes the “surprises" which come in are actually bugs originating from late QA cycles. In this case, they do not belong here, they belong in the organization's ability to change its conduct and integrate late-stage testing activities into the Sprint process itself.

8. Other important aspects to consider.

Do you have a very large amount of surprises?

I have seen companies whose Highway includes 90% of the work – not because things could not be done otherwise, but because there really was a mess and severe quality issues which created a lot of requests for changes and fixes from customers. A catastrophe that must be addressed quickly. In this state of affairs we stopped everything and underwent a Kanban, according to management’s decision that quality must be addressed first, in terms of both customer response and ongoing manufacturing, and only later should we proceed to develop – a very heavy price for the lack of quality in that project.

But it is also possible that there are a large amount of surprises because they are the reality of the organization or its market, in which case it is recommended that you take an additional step towards Scrumban, upgrade the board and improve the efficiency of the entire process. 

At the same time, you should consider shortening the Sprint duration.

It is possible that a large amount of surprises are concentrated around a particular area of the product, in which case you might want to consider having a certain team focus only on dealing with these types of problems. Is it an ongoing matter? Is it worthwhile to create a dedicated team solely for this area?

A matter which is urgently handled by several teams simultaneously and divided between several fast lanes: Yes, I have seen this as well. Not ideal. After all, the idea is to focus everything in one multi-disciplinary place, right? Right, but sometimes the organization is unable or unready to do so at the current time, due to various constraints. Hence this must also receive some kind of response in the short term. If the Fast Lanes of several different teams contains common issues, one way to handle it, beyond structural discretion, is to create inter-team focus on this urgent issue when new tasks are ‘injected’ – such as creating a specific alert or a dedicated project manager for the matter, etc.

Whatever you do, don’t forget to enjoy the road!