On Joel's Multitasking in the Workplace
Multitasking in the Workplace:
Joel Spolsky, a known writer on software development related topics is a long standing advocate of private offices for every developer, perfect working conditions and managers whose main role is to Ã¢â‚¬Å“move furniture out of the way, so people can concentrate on their workÃ¢â‚¬Â. Lately he found the support in the published in the NY Times research report claiming that in the cubicle space people loose hell a lot of time on interruptions. I believe that there is a proven way to unite the advantages of the open-space communication and private office focus.
Switching between tasks can take too much time
Joel's point is in that software development is a type of task that requires very high concentration. It takes too much time to switch between different tasks. Open office space might mean the increased level of inter-communication, but at the same moment it means too high rate of interruptions by the colleagues. Gloria Mark's study shows that in the open space based software development company
"Each employee spent only 11 minutes on any given project before being interrupted and whisked off to do something else. What's more, each 11-minute project was itself fragmented into even shorter three-minute tasks, like answering e-mail messages, reading a Web page or working on a spreadsheet. And each time a worker was distracted from a task, it would take, on average, 25 minutes to return to that task"
Overcommunication and undercommunication
The lack of communication is a known problem in the software industry. Lack of developer's focus and continuous interruptions is another one. It is the communication problem, that open space offices aim to resolve, and it is the concentration problem, Joel considers being the most worth solving.
There is a set of Agile development methods that put special emphasis on both enhancing the inter-developer communication and study of the consequences of the rate of communication. It is of no surprise, that having both "Individuals and interactions over processes and tools" and "Responding to change over following a plan" as the main values, Agile methods pay attention to the respect to the individual's work (i.e. to its concentration) while trying not to harm the level of communication.
Here is how Scrum, one of the most popular methods, addresses the open space issue.
The grand Scrum's idea of finding a concentration-communication balance is in protecting the developers from the potentially irrelevant discussion topics, in encouraging irrelevant topic discussions to happen at the dedicated moments. This idea is not unique to Scrum, but here it is used to the full extent.
1. Time-boxed iterations with a fixed set of goals
As most of iterative development methods Scrum utilizes time-boxed iterations strictly limited in time and, what's more important, with very limited set of concrete goals. Scrum does encourage frequent and early requirements and design changes, but all the changes are permitted only at the edges of the iterations. During the 30 days of the iteration, goals and main focus are frozen. In the world of chaos, there is a need for some stability. To emphasize this feature, Ken Schwaber, one of the Scrum creators, even named his web-site www.controlchaos.com.
2. Daily meetings
Scrum overview from www.controlchaos.com
To filter out the interruptions even more, Scrum features the daily meeting practice. They are sometimes referred to as Ã¢â‚¬Å“stand-up meetingsÃ¢â‚¬Â to emphasize the short length of the meeting. During it every person answers only three concrete questions: 1) What did you do yesterday? 2) What are you going to do today? 3) What got in your way of doing work? The daily meeting is a very short moment (usually 5-15 minutes) when everybody updates the understanding of the project state. At this moment potential problems (usual source of interruptions) are discovered, team has an opportunity to relocate resources and Scrum master is able to schedule actions for removing the obstacles as soon as possible.
3. Whole team together
The last Scrum practice I am going to mention is Ã¢â‚¬Å“Whole team togetherÃ¢â‚¬Â. Ã¢â‚¬Å“Whole team togetherÃ¢â‚¬Â, taken from XP means exactly the whole team sitting together in a single common room without cubicle borders and working on a closely related set of tasks. After all the irrelevant stuff has been filtered out by the fixed-goals iterations or scheduled to happen at specific time-place by the daily stand-up meetings, there is very little what can irrelevantly interrupt the programmer. If Mutt asks Jeff about the advanced usage of the ProvideReports function, it is quite probable, that he is working on something related to either ProvideReports itself or to some services that it uses. Voila, interruptions have been transformed into a useful channel of communication.
There is no silver bullet in the software development. Private offices do attract people, but harm inter-developer communication. Neither Scrum, nor XP, nor any other method can guarantee the success. Nevertheless the right balance between the developer's communication and concentration seems to be one of the keys to the successful software development. Scrum proposes a thoroughly elaborated set of practices aimed at finding this balance. At least, these practices are worth consideration.