GROWS logo

Set Team-wide Interruption Protocols

Software development requires long stretches of intense concentration. Interrupting someone in the middle of a concentrated task can cost them around an extra hour of work just to resume where they left off. So when can people be interrupted? When not?

Pain Points

  • Nothing gets done; everyone is too busy fighting fires
  • Project quality is down because of small things people forgot about
  • Morale is low because nothing ever feels finished

Benefits

With defined stretches of uninterrupted work time, programmers can hold more in short-term memory and work more effectively and efficiently: they’ll get more done.

Morale improves once you remove the “water torture” threat of constant interruption.

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this practice:

Setup

  1. Specify how and when the team can be interrupted
  2. Specify how individuals can indicate when they are interruptible, and when not
  3. Specify any exceptions

Trial

  1. Let everyone know the agreed-on interruption protocols, and work that way for a few weeks.

Evaluate Feedback

  1. You could keep lists of what everyone accomplishes during their focused, uninterruptible hours, and also keep track of folks who wanted to interrupt the team but had to wait. But perhaps a better approach is just to ask the team members how they liked it: did it feel more productive and easier working conditions?

What Does it Look like?

As with many aspects of management and engineering, there are tradeoffs. In this case, it’s a tradeoff between responsiveness vs. productivity. You can’t go 100% in either direction, but have to find a reasonable middle ground that suits the needs of the developers and the needs of the rest of the organization.

Which means that you have a lot of leeway in choosing what protocols to follow with this practice.

For team-wide uninterruptible hours, for example, you might chose whole days. Say, three days a week, the team can:

  • Quit out of any email client
  • Turn off the phones
  • Lock the door to outsiders

Or perhaps you might prefer to make that every day between certain hours.

For individuals, you need a way to indicate that you’re in the middle of something, and that an interruption would be expensive. You could signify this by placing an action figure on your desk, turning the light on (or off), opening or closing the door if you have one, and so on. You can choose anything you want as long as everyone understands the signals.

When are exceptions allowed? For example, if a team member is stuck on a bug and needs help, can they interrupt someone else? What if they need a code review or pair partner? These might be allowed exceptions.

The actual specifics are up to the team, but the important part is to end up with several large blocks of uninterrupted time each week, and a clear understanding among everyone as to who can be interrupted when, and for what reasons.

Please bear in mind that this practice is intended as a negotiation between adults. You can’t isolate developers completely, but you also can’t allow frequent random interruptions: the literature is very clear on the cognitive disruption caused by interruptions to skilled cognitive work. So it is in the best interests of the team and the organization to work out a good compromise such that the team has some guaranteed islands of quiet cognitive time in order to be productive, and some agreed-upon responsiveness to maintenance and operational issues.

Warning Signs

  • The team goes dark and never responds to emails or phone calls
  • The team keeps getting interrupted because there’s always an “emergency”
  • No one understands when it’s okay to interrupt the team and when not

Growth Path

Other than interrupting people who are trying to concentrate, what other artificial emergencies or crises are distracting people from getting work done? What can you do to throttle or limit those?

How To Fail Spectacularly

  • Forbidding user interaction with developers because it “causes too many changes.”
  • Using open space/open office plan exclusively, with no opportunity for quiet reflection or concentration.
  • Using closed offices exclusively, with no opportunity for collaboration or brain storming.

←Prev (Timebox)(Checklist for the Team (Stage 1)) Next→

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use The GROWS Method™. We will not use your email for any other purpose.