How to deal with non-project work requests on developers?

Question

(I'm new to Scrum) At my company we are relatively few developers (1-3 / per team) with very fixed project responsibilities (If you started product X, you'll be responsible for it as long as it exists).

Most devs are approached by POs, support, etc. with varying frequency to help with problems like recovering data, fixing setups, tracking bugs.

This goes directly against the idea of a sprint that a dev team should be able to work undisturbed on their spring goal.

Obviously the ideal solution would be to have dedicated people for these problems but we are simply not there personnel wise.

These are the options I see:

1. Try to shift as much of these capabilities to the support department as possible. There are however reservations among the developers to let support have the necessary power tools. Also I reckon there will remain a good number of issues that support will not ever be able to handle and will have to be dealt with otherwise
2. Add these help requests to the product backlog and prioritize them for the next sprint. This would incur up to 2 weeks waiting time for the affected customer, which won't go over will with sales
3. Add these help requests to the sprint backlog to be tackled as soon as the developer finished his assigned item. I've learned that sprints should have some slack rather than be too ambitious. One such problem probably shouldn't jeopardize the sprint goal. Maybe we could limit this to one interruption per sprint the rest would go to the product backlog.

What's the most Scrum way to do this?

Answer 1

Facing similar things in the past I combined a few solutions:

1. Try to get all the non-urgent work into the backlog, so that it is visible and foretasted for the team.

2. Try to get an idea of how much urgent work is still making it to the team, so you can take this into account in sprint planning. When something comes in, add it to the wall in a different colour, so you can see it's a new item. If you list all those interrupting tasks, you will quickly learn (for example) about 30% of a teams work is non-sprint related each sprint. While you can try to minimise this, at least you can take it into account in the sprint planning meetings, and see if you are making progress in reducing the amount of distracting work. This also has the benefit of being able to accurately explain why sprint goals were missed, so you have transparency of the impact the various product owners unplanned work is having on the planned work.

Answer 2

I've spent the last year and a half working with over twenty teams that have faced very similar issues.

Over that time we've experimented with several techniques and found some that work well.

First off to answer you questions: 1- Yes, absolutely train support. This is the "Bill Gates Penny" problem. The developers are paid to create new functionality, not to fix minor issues. Always have the developers ask themselves "Can someone else do this?" If the answer is yes, then let them. Developers want people to trust them, they need to trust Support. Start slow, have support pair with a developer at first so the dev can review. Then move to Dev review and then move the Dev out of the process completely. 2- Only add something to the product backlog if it directly connects to the goals of the product. If the work is directly related to an existing feature, then add it to the backlog. If it is work required to support near term work, add it to the backlog. Defects found in production get added to the backlog, they impact the shipping product. If something does not contribute to the sprint goals or product goals, don't add it to the backlog. 3- No, don't add things mid-sprint. The one and only exception to this is mission critical. If you have a bug in production that is halting the service, drop everything and fix it. Otherwise, don't interrupt the sprint.

Here is what is working now for me:

1- Only Blocker bugs can interrupt the sprint. Blockers are specifically defined with an SLA from the support organization. Blockers are added into the sprint as work. However they are not estimated. They are not part of the sprint commit so velocity should go down when you work on them. If you're constantly having your sprint interrupted with production issues, then you likely have a bigger problem that needs to be addressed.

2- All requests go through the product owner. When someone comes to the team and says "Can you do X", the team member says "have you asked the product owner?" The product owner owns the business outcome of the team and needs to make these decisions.

3- Only sprint or product contributing go in the backlog. Everything else is an Impediment or Blocker. If a product manager asks you to come up with charts for his next presentation, that isn't part of your sprint goal. While it may need to be done, it is an impediment to your real goal.

4- Have an Impediments List: Very easy if using a physical task board, requires a little imagination if doing it all electronic. Next to the task board have a place for impediments. Anything the team is being asked to do that is not part of the sprint plan goes here. Impediments don't get estimates as they are impacting the actual team goals.

5- Change your Standup Questions: Mike Cohn had some great advice on this. He recommends to add "that contributed to the sprint goal" to the end of the three standup questions.

• "I did W yesterday, that contributed to the sprint goal."
• I plan to do X today, that will contribute to the sprint goal."
• However I'm working on Y and Z right now, which do not contribute to the sprint goal, so not sure I'll get Y done today."

With these rules and practices in place, the visibility of the interruptions becomes very clear. When someone wants non-sprint work done, you can start asking "Is it more important that this work?" When people ask "why are you not getting anything done?" you can show them the Impediments list and how it impacted the sprint.

You might also want to do a quick Multi-Tasking Myth Exercise. Here is one, however Google and find many more.

Answer 3

There are several factors which could be problematic:

1. A team of 1-2 developers is not really a team. 3 people can function as a Scrum Team, but less that that is somewhat less than feasible.
2. You're right that adding work to a sprint backlog while the sprint is in progress should be an uncommon occurrence. Note also that when this does happen, something in the sprint also needs to be taken out.
3. The idea of these 'fixed responsibilities' flies in the face of shared code ownership. It also seems like a terrible idea - is your company trying to make massive knowledge silos, so that if one person leaves, no one knows anything about what they were working on?

Now, there are two ways you can go about this.

You can try to change how your company works, to better facilitate Scrum. You can do this by pointing out the negative repercussions these things could cause.

Alternatively, consider the possibility that Scrum does not fit well for you. While it works well for development, because of its fixed-sprint iterative nature, it is ill-suited for environments involving many hotfix support requests. You might want to look at Kanban for an alternative.

Of course, you might also be able to combine the two; do Scrum when starting out developing a product, and then switch to Kanban once the project is done. Or have two teams running in parallel, if you have enough support requests to justify having a dedicated team in addition to the Scrum team.

Answer 4

Well, we had kind of the same issue at SkuVault, and we decided to use an on call approach for some devs.

Note: our team is bigger. And around 3 FrontEnd and 3 Backend devs are there to support the system.

1. We started by asking developers to fill a small questionnaire to find out how often they are distracted from new feature development by urgent client requests or bugfixes requiring immediate attention. It turned out that significant time (up to 80%) had been taken by Urgent Tasks, which distracted devs and made their work less efficient.

2. So management came up with teams of on call devs. These teams (2 devs: Frontend and Backend) would work only on urgent tickets, which allowed the rest of the team to work on regular tasks, ideally, without distraction.

3. On duty team concept has been rethought a couple of times, as client base grew significantly, and so have the requests, tasks and points of attention. Some of developers still get pulled to urgent tasks.

However, the concept itself proved to be extremely helpful, and overall the issue is resolved.

Did we create more unification across the system in order for different devs to be able to more or less work and substitute each other in general development? Yes.

However, since our system relies on integrations heavily, and different partners / retailers may change something and break how our systems interact -> devs that were originally implenenting the integration are required. This is not resolved fully, as any dev practically can be pulled from new feature development.

But the overall unification led us to the point,

• that 1/3rd of integrations are shared across devs;
• 1/3rd are specific to certain devs, but don't break often;
• 1/3rd can often be broken and pulling original dev is necessary.

Answer 5

There are two situations you can be in with this.

1: You are expected to do the work

2: you are expected to push back and not do the work

If you are in 1, then just do it and add a card to the current sprint. at least then you can track why you missed the sprint goal.

If you are in 2, (presumably because you did 1 for a bit and then people told you to stop being helpful and concentrate on the task in hand) then put the work on the backlog for prioritisation (ie never going to happen)

If you are running the company my advice is to resist the temptation of 1. All those admin tasks that seem important tend to be of very low actual value. It's cheaper to deal with them manually than to create a program to deal with them and maintain it and you will find that many of them are just people being lazy.

ie If you get a task that means you have to go through a spreadsheet line by line checking for errors, when you know the dba can do run a query that produces the result in 1 sec. It's very tempting to demand that it be done rather than wasting your time. But in reality that query has to be designed and tested and rechecked, you need meetings to explain the problem and schedule the time etc. And that DBA is probably going to have to do some of the sheet manually anyway just to check their work.