Using Agile to Avoid Excessive Multitasking
Teams new to agile struggle with how to fit "bug fixing" into an agile method like Scrum, which advocates fixed iterations with a fixed-product backlog. Since a selling point of agile methods is responsiveness, "putting off" issues until the next sprint seems unresponsive and antithetical to delivering business value.
A fixed-product backlog during a sprint is meant to increase productivity by enabling a team to focus, maintain flow, and provide a framework that enables frequent delivery of product increments or features that the customer needs, with as little waste as possible. Agile processes give teams more control over their time, and this control can lead to the teams being happier and more productive.
By keeping priorities clear, you provide the teams the space to work with attention to quality and adaptability. You need safety and stability in the present to start thinking about the future.
By introducing critical bug fixes thoughtlessly, you open yourself to the same sorts of risks that multitasking introduces. An article in The New Atlantis asserts that when we "sort of force ourselves to multitask, we're driving ourselves to perhaps be less efficient in the long run even though it sometimes feels like we're being more efficient." Agile planning helps teams be more efficient but allows for focus.
Changing what's in an iteration mid-sprint is risky, so if you really can't limit requests for changes within a sprint, consider shorter more focused iterations. If you have sprints of a week or less and still have a hard time prioritizing bug-fixes within the context of a sprint, consider whether the product owner has either a lack of trust that the team can deliver reliably or a lack of understanding that adding work slows down the team.
On one team I worked, we added the effect of "priority bugs" to our burndown chart. Once the product owner saw the increase in the burndown line that resulted—and thus the energy taken away from new features—he started thinking harder about whether issues which were to be fixed by the next sprint could be placed on the backlog for later. The result? Only a few were considered truly "interrupt priority."
If you find that, even with strict evaluation of priorities, you still have truly important work that needs to be introduced mid-sprint, Scrum provides the ability to stop and re-plan a new sprint with the new work. This is a drastic, costly move, but changing priorities outside of the planning window is also costly.
An agile team can address issues in a timely manner. Bug fixing need not cause a team to multitask.
