Designing the layout
A team workspace layout that is conducive to social interaction facilitates the sharing of knowledge and improves the performance of the team, increasing their productivity. The workspace should be an open space large enough to accommodate the team and their equipment comfortably, and should be organized to satisfy practical, social and personal needs. The team should be encouraged to organize and maintain their own workspace so that it reflects their individual personalities and team character.
A practical area enables team members to sit together so that the physical proximity enhances face-to-face communication and facilitate pair programming. Team members should be able to easily talk to those sitting adjacent and to passers-by. It’s important that conversations can be overheard because they often carry useful information and help provoke knowledge sharing. Team members learn to tune-out background noise when they are concentrating in such an environment.
A public area provides a communal space where team members can work as a group. The area should encourage sociability and stimulate interaction with features such as a round meeting table, white boards, flip charts and other pertinent displays. It’s nice if part of the area is arranged in a ‘chill-out’ fashion with sofas or beanbags. Both of these areas should be located on a route through the team workspace so that people passing through can make casual contact. A number of private, owned spaces provide personal work spaces for concentrated, individual work. Team members should personalize their work spaces to create a home. This improves their attitude towards work.
Extreme feedback devices and information radiators
The public and practical areas of the team workspace should be about work. Kent Beck says:
“An interested observer should be able to walk into the team workspace and get a general idea of how the project is going in 15 seconds. He should be able to get more information about real or potential problems by looking more closely.”
An informative workspace centers on big visible charts that communicate big picture goals, planning information such as the dates and content of releases and sprints/iterations, progress, test results and the domain model. The charts must be immediately understandable and prevent misinterpretation. The information they convey should be easily and quickly absorbed by passers-by without the need to interrupt developers. Charts can assume various guises but can be categorized generally as Information Radiators and Extreme Feedback Devices.
Information radiators typically require manual updating. A story board is an information radiator. The spatial arrangement of the index cards communicates the product backlog, the sprint/iteration status in terms of completed stories, stories being developed and those not yet started. Colored stickers and post-it notes can be used to provide additional information and enhance visibility. Another information radiator is burndown chart, which is a graphical representation showing what had been done and what is still to do. (An alternative burndown chart can be seen at Mountain Goat Software.) Whiteboards provide an effective medium for capturing short-term information such as reminders or design discussions.
Extreme feedback devices are simple, highly visible indicators, which convey simple progress information in terms of passing/failing unit tests and passing/failing acceptance tests automatically derived from the continuous integration/build process. One popular device uses a pair of Lava lamps, one green and one red, connected to the build system such that a successful build with all tests passing turns on the green lava lamp, and a failed build containing failed tests turns on the red lava lamp. (See Pragmatic Programmer for more information). An alternative device uses a plasma screen to display the build results from continuous integration using CruiseControl.
2 Comments
In my experience Agile teams have usually taken open workspaces to the extreme. People sit at an arms length away from each other all the time. People chatter and laugh like monkeys which makes it difficult for them to concentrate on the task at hand.
I would be very concerned if an agile team's workspace is quiet. Being part of an agile team is a social experience. Teams that i have coached have commented that this sociability "makes writing software fun".
Proximity helps facilitate face-to-face communication but it should not be intrusive. The chatter generated within the team and between pair programming partners is an important communication mechanism. It also helps the team hustle, which creates a motivating buzz.
It can take time for a developer to tune into the right frequencies so that he can filter out 'noise' while programming, but still pick-up information he deems relevant to his task. Providing the communication is generally relevant to the programming effort, e.g. conversations between programming pairs, it's not disruptive (but i also think it can be refreshing to chill-out for a few minutes and talk about something not related to work). Each team will find its own balance.
Of course, it's not realistic to expect the agile work environment to suit every developer. During my coaching experiences i have encountered a few developers who have not been able to adjust.