How to justify sprints in a largely reactive business?

Question

We are an agile development team working in a larger business. Many of the other teams (the customer support team in particular) are extremely reactive and often have urgent client issues which need developer assistance.

We have a number of strategies for handling this including a rotating SWAT developer role and leaving a certain amount of contingency where each team member is under planned to account for the enevitible incoming queries and meetings.

The result of this is that most members of the development team have a few User Story's each sprint as well as several Support Tickets they are managing. Interruptions are frequent and the team are finding it extremely difficult to commit to completing their assigned work. I feel this is putting our entire scrum structure at risk.

Other members of the business are increasingly asking why we can't jump on tickets and why they must wait for the next Sprint Planning session to have them assigned (assuming the swat dev can't catch them). I feel for them, why should they have to wait up to two weeks before getting time from the most appropriate developer? On the other hand we owe it to the developer in question to protect them so they have a fighting chance to complete their sprint.

How can we explain to the business that we need the protection a scum structure gives us and can't commit our entire team to reactive support?

Answer 1

Context switching is expensive, however Scrum may not be the correct framework for the situation you are describing. You may want to consider transitioning to a Kanban framework.

Kanban is more accepting of interruptions and is focused on getting a few things done continuously rather than batching work into boxes of time (iterations).

But I think you are heading down the correct path of educating stakeholders external to the team that they just can't change priorities on a dime since to do this you are stopping work on 1 thing (that a different stakeholder wants) and starting something new. It sounds like your stakeholders should figure out how to negotiate between themselves before bombarding the team with requests that lead to context switching and ultimately getting things done slower than they could be because of the constant loss of focus.

Answer 2

We have much the same issue here in AOL Platforms. We have Feature Teams that work both on new features and also get dragged into fixing bugs. We did a number of things to fix this, the first starting with education.

1- Secrets of Multi-Tasking Exercise: This is great as it can be done in five minutes with a piece of paper and a pen. I'll detail it at the bottom of this post. The outcome is people understand in real terms the cost of multi-tasking.

2- Leverage Severity/ Priority: In AOL Platforms we have Minor, Major, Critical and Blocker. Looking at our SLAs we knew that Blockers would always be sprint interrupters are they require follow the sun attention. However our Critical defects have an SLA of 10 days and because our functional areas all have at least four teams, there is always a team starting a sprint within a couple of days. So we determined that only Blockers could be sprint interrupts. Everything else had to be scheduled into a sprint.

Tracking Cycle Time: We started tracking cycle time on the work done by the teams. From when something moved to "In Progress" to when it was marked as "Done". By having this data, we could then look at teams whose cycle times spiked. Most often there was a direct correlation to interrupt work, showing that teams that were interrupted ended up going slower on all their work, including the interrupt work.

MULTI-TASKING EXERCISE Have everyone put their paper in landscape position. On the paper divide the paper vertically with a line 1/3 down the page. Then divide the page horizontally into three sections. You will end up with six boxes on the paper, three small squares and three long columns.

In the small squares (column headers), write an "A", a "1" and a "I" (the last being a Roman Numeral one.

Round 1: Explain that the exercise is to create three features, a letter feature, a number feature and a Roman numeral feature. A complete feature is ten characters (A-J, 1-10, I-X) Management is very keen to see work being done on all the features. So when they write down your characters you must start with the letter A, then move to the number 1 and then the Roman Numeral I. Only then can they start on the next row with the letter B.

Ask that when they are done, they raise their hands. Get a stop watch and say begin.

As soon as the first person puts their arm up, hit the lap timer. When the majority of the room has their arm up, stop the timer. Review the times. Generally you'll have a range between about 30 and 45 seconds.

Then ask them, if each column is a feature, when did they see the first value. The answer should be something like "a couple of seconds before the first person got done."

Round 2: In this round tell them they are now to do each column completely before moving on, starting with the Letter column.

Start the timer and pay attention. When you notice someone has finished the Letter column hit your lap timer. When the majority of the room is done, stop the timer. Review the numbers. Generally you're first person will have finished between 15-20 seconds and everyone between 30-35 seconds. The first column done was less than 10 seconds.

When I teach this I generally then ask the room, "So the secret to multi-tasking is what?"

Someone always answers with "Don't do it"

Answer 3

I'm willing to bet your developers take lunch breaks. They probably go home in the evening, too. They may play a pick-up game of ping pong in the afternoon, or go for a walk around the building. You are no doubt already accounting for this in your sprint planning, so just add another thing to take into account: support.

Scrum is all about transparency. If you know that on average, each developer spends 10% of their time on non-sprint tasks, include that in your planning for a sprint. When the team commits (or estimates) that they will finish N stories or story points in a sprint, that estimation needs to be made knowing that the team's attention will be divided.

If the amount of support time is wildly inconsistent, account for the time the best you can. If you end up spending more time and you don't finish a sprint during working hours, let the organization learn from that. Don't put in extra hours to finish a sprint just because you got side-tracked. If you spend less time in support, then you should have plenty of time to finish your work.

Answer 4

It sounds like you have a Product Owner issue. The Development Team should only work from the backlog and not leave buffer in the sprint beyond the variance of the work.

If a production issue arises that is a fix/fail (site down) then the Development Team obviously need to drop everything and go fix it.

However if the issue is not an immediate threat and customers can still use the product then it is up to the Product Owner to determine if he/she is ok with loosing sprint time to fix it.

( ultimately every time you rush a fix you reduce the quality of the product and introduce more issues. Worse you reduce the value of the product which should be reflected on your organisations balance sheet as an asset)

Whichever is true these are not Story Pointed items and don't count to velocity. Every one of the production issues are a quality issue and need to be treated as such. Route cause and eliminate for all time.

Again, your Product Owner, as accountable and responsable for the Product, is the single point of ownership for this. They are the gatekeeper.

Likely they don't really understand the impact of reducing quality and of not meeting Done each sprint. This should be highlighted by the loss of velocity for fixing production issues.

If you do this then I guarantee you will find 90% of your current tickets that interferer with your team will become backlog items instead. They will be priorities by the PO and accepted into the sprint like any other item at Sprint Planning.