Team Member Interruptions

We’ve all seen a team that is busy and yet is hardly moving forward. A big issue? Interruptions. Good news, on the difficulty front this is one of the easier one problems to improve. Some reports suggest most people don’t even get two hours daily to do their work.

“It’s all Scrum’s fault…” - I recently had someone tell me this in a pub after a long hike. Interruptions are a huge problem for any team, however perhaps not discussed over a pint of beer. I asked a simple question, “Did you have any interruptions before you started Scrum?”. Yes. “Did Scrum cause the interruptions?”, No.

Let’s look at the real sources of interruptions:

Self Interruptions

• Multitasking and/or Boredom - Multitasking working on several items at the same time, we interrupt ourselves by switching between tasks. As someone with ADHD, boredom often leads me to multitasking, I don’t even need teammates to interrupt me.
• Long running tasks finishes - Working with Generative AI or a slow build, many tools we used a long time to do their, so we interrupt ourselves by switching to another task.

Team Interactions

• Asking for help - A teammate asks for help
• Scrum Events - Planning, Daily Scrum, Review, Retrospective and Backlog Refinement
• Non Scrum Meetings within the Team
• Friends at work stopping by your desk
• New Features mid-Sprint

External Interruptions

• Notifications - Like Slack or Email
• Meetings outside of the Team
• Defects/Production support issues
• External Dependencies - need to ask other teams for help; giving other teams help
• Non Sprint work - perhaps a manager stops by someone’s desk and says the magic word: “Pssst, could you do me a favour? It will only take an hour.” Famously, no such request has ever taken only an hour.

All of these interruptions come at a cost. The human brain doesn’t handle task switching well (see: Multitasking), It takes 25-30 minutes to recover from an interruption. Worse, when we restart the task, we sometimes forget where we were and end up making mistakes. With scheduled interruptions like a meeting, we know it is coming up and can take time to make notes to get back on track faster. Unscheduled interruptions just derail us.

Not all interruptions are equal in pain or importance. When we’re part of a team, the customer cares most about whether or not the team delivered something of value. Not whether any one person on the team was productive.

Self Interruptions - I’m not going to repeat all of the popular productivity advice (e.g. Time Blocking, Pomodoro Technique, etc.), I will just point out that when you’re pair programming, it’s harder to get lost in the land of multi-tasking.

Team Interactions - Most of the time, if it’s a team mate asking for help, it’s a valuable interruption. Even then, Scrum has Daily Scrum to reduce the number of times someone needs to ask for help. The Scrum meetings (properly called Scrum Events) are designed to improve the team’s ability to collaborate and so be productive.

Daily Scrum is especially important as it is expected to replace all other meetings within the team during the day. This should mean that the team doesn’t other regularly scheduled meetings during the day

The remaining interruptions are more complicated. Urgent interruptions i.e. Production Support Issues or Bugs should to be taken care of right away. The question will be how we keep the cost to a minimum. Our strategies here will be focused on reducing the frequency and cost. Scrum by Example – How to Handle Production Support Issues in Scrum covers many of these strategies.

Meetings Outside the Team - Ask what value does the team gain from this meeting? Does it help the team improve flow? For example, a regular meeting to review a multi team Kanban board (see: Kanban Portfolio View and Portfolio Management with Upstream and Downstream Teams), could be very valuable because it helps the team see the impact of their work and ensures that the team stays unblocked. On the other hand, there are many meetings that provide almost no value to the team. In these cases, either don’t attend or send only one person, minimizing the cost of the interruption.

Most other interruptions are harmful, and we want to reduce/eliminate them. Ex: New Features mid Sprint? It suggests that the Product Owner and Team need to do: better Product Backlog Refinement, Product Strategy Work or Stakeholder Management.

Instead of accepting interruptions as normal, study the sources and help your team. Ask who it helps? What is the cost? Could it be avoided or at least scheduled in advance?

What sources of interruption did I miss?

At the end of long hike, let’s not talk about Scrum. It’s far more fun to talk about the hike we just had.