Unpacking Interruptions- Why Your Team Struggles to Get Things Done

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

“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, although maybe not commonly discussed over a pint of beer.

I asked a simple question, “Did you have any interruptions before you started Scrum?”. Yes.

“Did Scrum cause those interruptions?” No.

Instead of blaming Scrum, let’s look at the real sources.

Where Interruptions Come From

Self Interruptions

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

Team Interactions

• Requests for help from a teammate
• Friends at work stopping by your desk to socialize
• Scrum Events - Planning, Daily Scrum, Review, Retrospective and Backlog Refinement
• Non Scrum meetings within the team
• Unplanned work introduced as new features mid-Sprint

External Interruptions

• Notifications, like Slack or email
• Meetings outside of the team
• Defects/Production support issues
• External Dependencies - Needing to ask other teams for help, giving other teams your help
• Non Sprint work - Classic example: a manager stops by your desk and says the familiar phrase, “Pssst, could you do me a favour? It will only take an hour.” Famously, no such request has ever taken only an hour.

Interruptions Come at a Cost

The human brain doesn’t handle task switching well (see multitasking to dig deeper for why). 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.

The customer cares most about whether or not the team delivered something of value, not whether any one person on the team was productive, so disrupting flow affects the health and effectiveness of the whole team. Fortunately, not all interruptions are equal in pain or importance. And they’re all fixable.

Solving for Each Type

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 multitasking.

Team Interactions - Most of the time, if it’s a team mate who is 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.

The remaining team interruptions are more complicated. Urgent interruptions (e.g. Production support issues or Bugs) should be taken care of right away. The goal will be to keep the impact to a minimum by reducing the frequency and cost. Scrum by Example – How to Handle Production Support Issues in Scrum covers many strategies.

External Interruptions - When it comes to meetings outside the team, ask “What value does the team gain from this? Does it help the team improve flow?” For example, a regular meeting to review a multi-team Kanban board could be very valuable because it helps the team see the impact of their work and ensures that the team stays unblocked. (See: Kanban Portfolio View and Portfolio Management with Upstream and Downstream Teams)

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. For example, 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?

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. 🙂

---

Footnotes

1. “Deep Work Is a Multiplier for Engineering Organizations” ↩

2. “What is Focus Time and how does it impact productivity?” ↩