Context Switching Its That Important?
There are quite a fair amount of article talk about Scrum team shouldn't do context switching whereby the team should have full focus on whats on the project / sprint goal once the sprint has been lock down
My questions is , imagine in a work environment whereby need to assist company client and there always an ad-hoc task coming in , what will be the best approach here? In an ideal world no matter how well plan there always a impromptu situation.
What does the Product Owner think about these ad-hoc tasks? Does he or she believe they help to maximize product value?
If the tasks are to assist the company client then I would suggest a support team that works based on a ticket queue and let the Scrum Team focus their attention on a Product Backlog that creates additional value for the company client. They do not have to be the same set of tickets.
Reality is that organizations will often have groups that do work that are not organized around Scrum. In this case the support team would be a source of information for the Product Owner's efforts in determining changes needed to the product.
First of all, is this a product development team or a service delivery team? In the latter case, e.g. a Service Desk, I'm not convinced the Sprint mechanism of Scrum is most suited for them.
If it is a product development team, the Scrum Guide is quite clear on this: "Dring the Sprint: No changes are made that would endanger the Sprint Goal;" It doesn't state that teams are not allowed to do anything outside of their Sprint Goal, it just stresses the importance of prioritising the Sprint Goal over other activities.
A bit of ad-hoc work during Sprints is actually a good thing. It shows that the team has the confidence to start sprinting without having sorted out all petty details during refinement or Sprint Planning. Even the purest of Scrum teams regularly take up unplanned work during their Sprints, if only to support the production environment of their previous Sprints' Product Increments. As long as the Sprint Goal remains valid, the Sprint goes on. There are simple, elegant techniques for that, usually combining a Kanban Method-light approach with the Sprint Backlog.
Having said that, if your team is spending large amounts of time during their Sprints on ad-hoc work, it could be a sign that:
- the Product Backlog lacks stability or clarity: Can these ad-hoc tasks be avoided before the sprint starts with more refinement work?
- the Product Owner lacks the mandate to fix the team's focus for the duration of the Sprint and to postpone ad-hoc requests to later Sprints: are the ad-hoc tasks prioritised by the Product Owner based on a product vision?
- functional/technical debt is causing unexpected 'urgent' problems to occur regularly. Lowering the team's velocity may be a good idea, so they can clean up historic debt.
Final note: I wouldn't link this situation with multitasking as such. As long as ongoing tasks do not need to be interrupted on the spot and the team is able to re-plan their work with the new tasks (e.g. during their Daily Scrum) in a way that works for them, no problem.