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 organised to satisfy
practical, social and personal needs. The team should be encouraged
to organise 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 proximities enhance 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 workspaces for
concentrated, individual work. Team members should personalise
their workspaces 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 centres 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 categorised generally as Information Radiators and
Extreme Feedback Devices.
Information radiators typically require manual updating. A user
story/task board is an information radiator. The spatial
arrangement of the index cards communicates the product backlog,
the sprint/iteration status in terms of completed user stories,
user stories being developed and those not yet started. Coloured
stickers and post-it notes can be used to provide additional
information and enhance visibility. Another information radiator is
a
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 .
Monday, 15 August 2005
Informative workspace
Posted by Simon Baker - Permalink
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.