Skip to main content

Task switching destroys efficiency and quality, so what to do?

Last post 12:18 pm June 19, 2013 by Ian Mitchell
4 replies
06:56 pm June 17, 2013

Task switching destroys efficiency and quality, so what to do?

Let’s say you have a small development team consisting of 6 developers divided in 2 Scrum teams each doing their own project. The projects are going well and the teams are continuously improving themselves. Because perfect software does not exist, bugs, issues and/or new features requests will eventually come up.

Seeing you have limited resources, how would you set up your teams while keeping in mind that context switching destroys efficiency and quality.

1. Every day buy time x hour time to work on maintenance.
2. Set up a team that works full-time on maintenance. (although I’m pretty sure, this will not be supported by management)
3. Reserve x days in each Sprint to work on maintenance.

I understand that the best way is to consult the teams, but I was wondering which options or creative solutions you guys/ ladies have.

Cheers, Chee-Hong

06:40 am June 18, 2013

If the maintenance is for the same system that a team is working on, then I'd continue as-is. The Product Owner should be in a position to prioritise the work accordingly and negotiate it into Sprints.

If the maintenance includes different systems than the one being worked on by a team for their project, then I'd be looking at setting up a dedicated team for maintenance. I'd set it up as a Kanban for handling small and repeatable changes spanning multiple systems.

If management won't accept the creation of a dedicated team, then I'd be looking to reserve time as you suggest. The PO would therefore still avoid being exposed to maintenance requirements that are outside of product scope. However, reserving time is a second best option because there are invariably "maintenance" requirements that end up being fast-tracked (emergency work) and which can potentially compromise the Sprint Goal. I wrote an article on this subject last week:

07:45 am June 19, 2013

Hi Ian,
Thanks for your quick reply.

I’m wondering what would be more efficient and effective.
1. Regularly reserving some Sprint time to work on maintenance. As team we have agreed to work on maintenance every day from 15:00 till 17:00. But in reality I noticed that it’s very difficult to maintain this discipline. Also the context switching needs to be done on day basis.

2. Reserve x days in the Sprint to work dedicated on Maintenance. This way context switching still occurs but this time it’s limited to a days instead of suddenly stopping with what you were doing.

Dedicated Maintenance Team didn’t work for us due to all the complex legacy issues. The total amount of issues got stacked up while the team wasn’t preforming, demotivated team members and angry customers. It’s not because the junior developers can’t do it, but the department has worked in silo’s for many years and all the knowledge are almost always at certain people. (our seniors)
Of course the junior developers can learn, but the learning curve is too high and issues are almost always operational issues, in other words, it can’t wait…

11:51 am June 19, 2013

There is a right context to do everything, but I generally don't believe in "maintenance teams" or "reserving capacity for maintenance".

This is generally how I coach teams to handle what you describe in Scrum:

Let me know if you have any questions about the chart -- I'm happy to expound upon certain steps/items.

12:18 pm June 19, 2013

Reserving x days in the Sprint could minimise context switching as you suggest, but I suspect it would also stretch the rules of Scrum beyond breaking point. Scrum says that a Sprint starts immediately after the end of the previous one. Since the most practical way to accommodate "maintenance days" is at a Sprint boundary, it would therefore be difficult to say you're really doing Scrum.

Reserving time during the day would avoid this issue. Moreover, I wouldn't be too concerned about context switching in this case. If it can be done 3pm to 5pm, and people generally leave at 5pm, then they are at a context switching boundary anyhow. They won't be switching back to development until the next morning. There's still a problem, but it isn't "context switching" per se. Rather, the problem is simply that each team member won't be able to deliver a full 8 hours of continuous development work, which isn't the same thing.

There is a third option, and I have used it successfully. This is to reserve team members on a rotational basis for maintenance work. The team introduce one or more cards into each Sprint Backlog for maintenance activities, and self-organise during planning to determine which members will action them. Points to note are:
- The Sprint is allowed to continue uninterrupted, since at least some team members will be doing project work at any given time.
- Each developer doing project work gets a full run at an 8 hour day
- It doesn't matter which systems are being maintained, because the card is never introduced into the Product Backlog.
- The Sprint budget (for project work) will need to be reduced to accommodate these maintenance activities.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.