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? Set the rules to balance productivity and responsiveness.

Better yet, practice ensemble programming. This enables the team to continue delivering SmallBitesAlways of user value if a developer needs to leave for a bit to put out a fire. However, if ensemble programming is out of the question due to politics keep reading.

Pain Points

  • Nothing gets done; everyone is too busy fighting fires
  • Project quality is down because people forgot about small things when restarting work
  • 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 get more done
  • Morale improves once you remove the threat of constant interruption

Assessment

  • Teams are happy with their balance of focused work time and collaboration time (Significant boost)
  • Service desk is happy with the team’s responsiveness (Boost)
  • Teams don’t have any established norms around focused work and collaboration (Setback)
  • Teams are inundated with interruptions (Disaster)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this habit:

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 (such as stuck habit in TimeBox)

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 trade-offs. In this case, it’s a trade-off 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 habit.

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 uninterruptible hours 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. Some apps allow a Do Not Disturb status. 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.

This habit is intended as a negotiation between adults. You can’t completely isolate developers, 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 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 (Shrinking Time Box)(Continuous Review) Next→

Find Out More...

Follow @growsmethod in the Fediverse, 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.