InfoQ

News

Co-location Transition, Tips and Concerns

Posted by Mark Levison on Nov 16, 2008

Community
Agile
Topics
Agile Techniques ,
Collaboration
Tags
Co-Located Teams ,
Culture Change

Recently there has been a discussion making about transitioning teams to co-located environments and what it takes to make it a success.

Dave Rooney, of Mayford Technologies, says:

  • Noise is the first problem people notice - he recommends handing Nerf balls or foam bricks to bean people making too much noise. If people put on headphones to avoid the noise, some of the advantage of co-location is lost.
  • Some people will need to take short breaks outside of the team area.
  • Core hours, like: 9:00 - 3:00 (with a break for lunch), help ensure that the team is working together for most of the day, but still have a opportunity to do other things.

Robin Grosset said that when the transition happens, developers mustn't lose floor/desk space when compared to their traditional cubicles, otherwise they will feel it's just a management ploy to squeeze more people into less space.

Sam Edwards noted:

Initially there was very strong resistance from quite a few engineers - they felt they were giving up their privacy and "comfort zone". So we let them organize their desks with the open space, and found they ended up at the periphery, all facing away from each other (corner positions preferred to side positions). ...as pair programming began to creep through the teams, we found the engineers spending more and more time sitting beside each other, which made the actual location of their desks fairly irrelevant. My one strong piece of advice: give the engineers LOTS of time to make this adjustment - it's a big one for many of them, and impossible for some.

Adrian describes a transition he organized for a team of ~45 people:

  1. Make sure everyone is heard. They used Edward De Bono's "Six Thinking Hats" exercise to get the team to consider the change from all different aspects.
  2. Offer the change as six month experiment. People are more open to experimentation than being forced into a permanent change.
  3. Involve team members in designing the new space, there may be limits but the more involved they're in the planning the more ownership they will feel of the change.
  4. Make it fun: get a ping pong table, a couch or something other non traditional office furniture.
  5. Give them some personal space to express themselves and have pictures.
  6. Give them sufficient storage, Adrain's team were all given rolling storage cabinets.

Scott Ambler, Agile Practice Leader at IBM, while acknowledging co-location as likely to improve a team's chances of success, raised some concerns:

  • People who are used to working from home will struggle in this environment.
  • Some people work better in isolation.
  • Noise generated by the team can be a disturbance for the teams around them.
  • Information Radiators (corkboards, whiteboards, ...) are visible to people outside the team. This could be a security problem.

Finally Jay Conne shared the story of a "tech introvert" who told a VP in an elevator that he liked the interaction of team.

 

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

Several of Scott's concerns seem specious by Mark Levison Posted Nov 14, 2008 2:55 PM
Re: Several of Scott's concerns seem specious by Dave Rooney Posted Nov 17, 2008 5:16 AM
Co-location is so valuable - it outweighs the risks by Matthias Bohlen Posted Nov 27, 2008 12:23 PM
  1. Back to top

    Several of Scott's concerns seem specious

    Nov 14, 2008 2:55 PM by Mark Levison

    When I team co-locates I don't expect people who work from home to change their habits. Their role on the team might evolve over time if only because of the isolation.

    In addition he is mentions the security concern with information radiators. Frankly I'm baffled if they're a security concern you would never be allowed to have them in the first place (sad) team room or not.

  2. Back to top

    Re: Several of Scott's concerns seem specious

    Nov 17, 2008 5:16 AM by Dave Rooney

    When I team co-locates I don't expect people who work from home to change their habits. Their role on the team might evolve over time if only because of the isolation.

    I love working from home, mainly because the traffic during the commute consists only of a dog, cat, my wife and kids. They tend to be more predictable than most drivers. ;)

    In addition he is mentions the security concern with information radiators. Frankly I'm baffled if they're a security concern you would never be allowed to have them in the first place (sad) team room or not.

    I don't buy this, at least on it's face. To quote Brian Marick, "an example would be good about now". I worry that for the < 1% of the time that this actually applies, the other > 99% of projects would use it as an excuse not to be open and honest about their progress.

    Dave Rooney
    Mayford Technologies

  3. Back to top

    Co-location is so valuable - it outweighs the risks

    Nov 27, 2008 12:23 PM by Matthias Bohlen

    My customer currently has a co-located Scrum team that has become hyper-productive in only five sprints they did together. They have a team room with lots of noise because some people have a naturally strong voice. I found out that after some time the rest got used to them, sometimes they call "be a little quiet", sometimes just they just have fun.

    My own experience is: The more clear the requirement is that you implement, the less important becomes the noise. Noise is mostly a problem when you try to solve a difficult problem alone, in the privacy of your own mind. Having done this for years, I now simply try to avoid this lonely thinking entirely and have a peer for discussion or pair programming, instead. This has proven to be far less error-prone and much more fun!

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.