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