A friend referred me to an old blog post on how to avoid memory loss from being interrupted while coding. This post is chock-full of good suggestions that any developer can follow to minimize disruption. However, there are also some good patterns teams as a whole should consider if they find themselves unable to gain a foothold on their day.
Regular, predictable meetings can let developers intuitively predict when they need to begin “serializing” their current memory state. Sprint reviews, retrospectives, and planning are perfect examples of this. By holding the same set of meetings every sprint, you’re giving developers a reliable pattern to work around. Even beyond sprint events, scheduling dedicated “team-time” can give your team a chance to collaborate daily, without breaking anyone’s flow.
Hold meetings during non-peak hours. The blog post above briefly touches on this already; developers shouldn’t be pulled out of their desks when their memory load is high. It’s therefore better to have meetings just after lunch, or right at the beginning of the day - whatever time block you can grab before team gets down into it.
Steer your team away from impromptu walk-up meetings. Note that we don’t want to discourage communication - we just want to make sure the communication happens in a way that is productive and useful. For example, if your team is frequently approached with questions from an external UAT team, then your team should look for ways to make UAT more independent. Maybe they require additional training, or need to be included in sprint reviews, or need to be actually included in the team. The only times a developer should be interrupted is if they’re already actively collaborating/coordinating with the other person, or if there is an actual emergency that needs resolution.
Lastly, encourage the use of asynchronous communication. Again, we don’t want to discourage communication, but the use of email or chat clients can help let the developer regulate his own memory state. A small popup on a desktop gives a developer plenty of time to finish his line of good, write a sticky note, and *then* address the discussion. Walking over to their desk and hovering will break their focus immediately. Email and chat clients are not especially good for actually conducting a conversation, but they’re a good, gentle way to prompt a face-to-face talk.