Possibly the best way to cripple the productivity of any development team is to bombard them with distractions. This was best brought home to me by DeMarco and Lister’s seminal book Peopleware: Productive Projects and Teams.
Programmers, the authors proposed, are at their most efficient when they reach a state of ‘flow’ in which they are able to concentrate fully on a single problem. Any developer will tell you how satisfying it is to be in this state, how productive it is… and how easy it is to be pulled out of it by the smallest interruption. What’s worse, since it takes at least fifteen minutes to reach this level of concentration, any interruption no matter how small can cost you a quarter hour’s productivity. A constant stream of small interruptions, say a phone near your desk that rings just twice an hour, can make a developer unproductive (and miserable) for most of the day.^1^
Still, distractions are inevitable, and problems that need a developer to help solve them will come up every day. A production system may run into trouble, another developer may need help with a hairy problem, a member of another team may want to know how your product solves a particular problem, and so on. At Atlassian, we try to manage these interruptions in two ways:
h3. 1. Asynchronous Communication
Atlassian runs a Jabber server for staff, and during the day all developers are logged on to instant messaging. The advantage of instant messaging over other forms of intra-office communication is that it is so easily ignored. A developer who doesn’t mind being interrupted can monitor their messages and respond as they come in. A developer who is busy working on some tricky problem can minimise the window and respond to messages at his or her leisure.
For this reason, developers will often use IM to talk to a colleague, even when the other person is sitting only a few feet away.
The other form of asynchronous communication popular in Atlassian is blogging: writing a blog post on our internal wiki is a great way to get feedback from the rest of the company about an idea without walking around interrupting people to ask them their opinion.
h3. 2. The Disturbed
Asynchronous communication introduces its own inefficiencies. It turns out there are still enough problems that need to be solved _now_, not at the convenience of the developer, to constitute a steady stream of interruptions to the development teams. Our solution, pioneered by the Bamboo team, was to designate a single developer to be “The Disturbed”; taking a two week stint to act as a magnet for all the questions, requests and distractions that would otherwise be distributed across the whole team.
For Confluence, the name of the current Disturbed is prominently displayed on a whiteboard just outside the team’s office space. The Bamboo Disturbed has a flag on his or her monitor.
The downside of this approach, of course, is that for two weeks the Disturbed gets very little work done on whatever feature track they are nominally committed to. On the other hand, because the Disturbed isn’t _expecting_ (or expected) to get much of that work done while being disturbed, it is far less frustrating for the developer and far more predictable in terms of scheduling and estimation for the team as a whole.
To learn more about how we develop software at, visit the Agile at Atlassian site.
^1^ DeMarco and Lister use this to argue that each developer should be given a private office with a door, a practice enthusiastically embraced by Microsoft in the 1980s and more recently by New York software firm Fog Creek. Atlassian remains defiantly open plan: an office layout that encourages collaboration and communication at the expense of pure efficiency.