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

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: http://agiletv.com/the-agile-response-to-a-p1-incident

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…

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:
http://www.scrumcrazy.com/bugs

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

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.