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?
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.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
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:
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. 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 practice 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.
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?