BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Agile Team Spaces: Do's and Don'ts

Agile Team Spaces: Do's and Don'ts

Bookmarks

Many of us, who are new to Agile, would believe that putting an Agile team together in a room gets the job done. A few of us would actually pay attention to what makes a room a team room which can enhance productivity and motivation. Many Agile teams have already shared their perspective on what would make an ideal team room. Here are a few recent ones.

Rich compares the war rooms to the lab where Thomas Edison was working. He mentioned that apart from the fact that the entire team got to work together, one of the other big advantage is that of Serendipity. The effect of overhearing the ideas of others and using that as a spur for innovation. He quoted William Pretzer, author of “Working at Inventing

Far from being the sedate intellectual environment characterized by library quiet, Edison’s labs were noisy, crowded places that often seemed on the point of uproar.

William Pietri put together a list of rules for great development spaces. Amongst the well documented suggestions like putting the team together, room for daily standup, enough whiteboards and information radiators other suggestions included,

  • Get collaboration-friendly desks – William suggested this as one of the big pitfalls. He mentioned that many companies would like to foster collaboration but end up having furniture which is hostile to it.
  • Minimize distractions – The recommended rules to minimize distractions for the development stations include no phones, no email or IM, no off-topic conversation, less foot traffic and executives stay on mute.
  • Only direct contributors sit in the room – No chickens and certainly not the receptionist nor the sales people who would mostly be on the phone.
  • Pleasant space – Good lighting, decent air, plants, decorations and snacks.

Robert McGeachy recommended a list of information radiators to be a part of every team room. Apart from the standard Scrum Artifacts, his list included,

  • Team structure with who's on the team
  • Client Organization structure
  • High Level and Mid Level plans
  • Client Phase exit criteria
  • Team performance survey results
  • Risks
  • Recognition awards
  • Ground Rules

Somehow, there is also a strong focus on being connected with nature. Mike Cohn mentions a window as a requirement for the ideal workspace. Likewise Andy Powell, mentioned the benefits of working outside with the nature. He mentioned,

As a developer, I’d like to be able to work outside, so I can enjoy the work more.

William Pietri also took a stab at defining how you could identify a bad team space easily. He listed the following points,

  • People wearing headphones
  • Stale artifacts on the walls
  • Workspace as information desert
  • Minimal interaction
  • Furniture as barrier
  • Sad or ugly spaces
  • Seating by job description
  • Space and furniture as status markers
  • No laughter, no fun

Most of the above points would narrow down to strong lack of communication and uninspiring ambience of the workplace.

Thus, apart from getting the entire team together in one room, there are other subtle differences which distinguishes the room in which a team is sitting from the team room. The key is to work on the factors which foster communication and motivation thus leading to productivity.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Hasn't Agile Seating Been Debunked?

    by Jamie Saucier,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Our large company adopted the Agile workspace from top to bottom. We were told that it would allow for ample "natural light" and the ability to see and "collaborate" with our coworkers.

    This is all fine on paper. Here are some things that *should* have been thought through prior to implementation of an Agile space:

    1. The devastating effect on those with hearing loss (hearing devices amplify *all* sounds, not just the voices you are trying to listen to) or sensory issues has been completely ignored. The constant noise of working with dozens and dozens of people in the same area makes it impossible to concentrate on your work. Employees having conference calls at their desk right next to you, the office gossip talking non-stop, and the office "loud-talker" are devastating for concentration in an employee wearing an amplification device like a hearing aid. To make my workplace bearable, I wear headphones *all day* to tune out the non-stop, never-ending noise.

    Paradoxically, when employees work in an Agile space and want to speak to one another, many employees will want to talk to you in a voice barely louder than a whisper to avoid being conspicuous in a room full of (potentially) dozens, or even hundreds of people. You will struggle to hear your colleages in "huddle" meetings (right in the aisle of the Agile space) in which people will whisper, ironically, to avoid disturbing the team next to you.

    For an employee with hearing loss, an Agile space is a frustrating, embarrassing, and exhausting experience.

    2. The Agile space is supposed to attract all the young people who want to feel like they are working at Google. It has had the opposite effect. When we had cubicles, the young people would excitedly talk to each other in each others cubes. Once the walls came down, they felt "exposed" and felt that they would get into trouble for showing any social behavior at work. These young people stay at their desks and work by themselves. They are miserable.

    3. One more question: does the role your employees are performing even require collaboration?? Or, are employees working on their own work, at their own desks, most of the time. If so, what is the benefit of changing to this open environment?

    Just my two cents!

    Jaime

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT