Archive for April 2009

10 rules for great development spaces

Sidereel main room

Building a great team development space is tricky. You have to balance a lot of factors: human, social, environmental, economic, and personal. There is no universal solution, but I wanted to share a few lessons I’ve learned over the years.

Note that these only make sense if having a productive team is a high priority. For a lot of organizations, other motivations regrettably win out.

My 10 rules

  1. Put everybody vital to the project in one space. Agile methods are built around communication. Having everybody together means that instead of having to work to communicate, they’d have to work not to.
  2. Isolate the team from off-topic noise. You want to create a space where people are comfortable listening to the conversation around them. Most of what they hear should be related to the work at hand, at moderate volume, and free of drama.
  3. Have plenty of wall and whiteboard space. The workspace should be richly informative, with product plans, task lists, backlogs, charts, and source material obviously present. Make it easy to know what’s going on.
  4. Allow room for a daily stand-up. Every morning, I like to have a team get together and spend a few minutes getting back in sync about what’s going on. That will often involve referring to in-room artifacts like task breakdowns, backlogs, and interface sketches. Give them enough room to huddle up!
  5. Pairing WorkstationGet collaboration-friendly desks. I’m amazed by the number of companies that talk up collaboration and then buy furniture that is actively hostile to it. Whether or not the team officially practices pair programming, every development station should allow two people to sit comfortably side by side and have equal access to the screen and keyboard.
  6. Minimize distractions. For programmers, interruptions are doom, causing lost productivity and decreased product quality. (This doesn’t apply as much to non-programmers, but those folks should still be wary of distractions.) To minimize chaos, I often suggest these rules for development stations:
    • No phones. Some teams avoid individual phones entirely; others just keep them away from development stations.
    • No email or IM. Relegate that to machines out of or at the edge of the main work area. A common solution is shared development stations, with personal laptops for email, IM, and the like.
    • No off-topic conversation. Agree that if even one person is concentrating, off-topic conversation must happen out of the team room.
    • Executives stay muted. Often higher-ups are used to being the center of attention. Some teams have learned to keep working, but that requires the bosses to be quiet and modest in their demeanor. If the execs can’t do that or the team can’t ignore them, keep them out during periods when work is getting done.
    • Control foot traffic. I like to put developers away from the door, with managers, product owners, and designers closer to it. Visitors are very likely to talk to the first person they see; if that’s the person most able to help them, that’s better for everybody.
  7. wall-o-cardsOnly direct contributors sit in the room. The people sitting in the room should be focused mainly on the project at hand. A good solution for part-time contributors is to have guest desks, so that they can be present when participating and return elsewhere when they aren’t. People with unrelated work, especially noisy work like sales, should never sit in the room.
  8. Have necessary spaces nearby. Making software should be the primary focus of development teams, but make sure to allow space nearby for other important activities. These can be formally designated areas, or informal things like spare offices and nearby coffee shops. Often they are shared with other groups. I like to see:
    • Small meeting areas. These should suit one person who has to take a phone call, or two to three people who have to meet.
    • A large meeting area. This need is usually filled by the classic conference room. Whiteboard space is mandatory.
    • A lounge. Office space should encourage focused activity, but people need rest, and good ideas often come out of more casual conversations.
    • Related projects and staff. Communication patterns tend to mirror spatial patterns. Take advantage of that!
  9. Make the space pleasant. I’m not talking about gold-plated faucets here, just about making a space comfortable rather than hostile. Sure, people can work almost anywhere, but you should save their gumption for delivering value. This often includes:
    • NewEdu Team RoomGood lighting. Some natural light, supplemented by good room and/or task lighting. For whatever reason, programmers often hate fluorescents, especially the low-grade ones, so I try to avoid those.
    • Decent air. Team rooms often have a higher person density than normal, so it’s especially important to make sure that there’s good ventilation and temperature control. By 3 pm, too many team rooms smell like a packed dance club on an August night.
    • Comfortable, reliable furniture. I’m not talking about deluxe furniture here; often a mid-range Ikea equivalent is fine, and I generally suggest good tables rather than standard desks. But a shaky desk or an uncomfortable chair costs far more in productivity than it saves in cash.
    • Plants and decorations. It takes very little extra to turn a room from adequate into appealing. A little greenery and a couple of framed posters is a good start. Depending on company culture, a couple of toys can be good, especially ones that encourage interaction or collaboration.
    • Snacks. Food and drink is a central part of hospitality in every culture I’ve heard of. Normally I’ll put out some healthy snacks, like a bowl of fruit and some baby carrots, plus a water cooler or a fridge of bottled water. Typically I put more elaborate or less healthy things, like coffee, soft drinks, crackers, and cereal, in a kitchen or lounge area.
  10. Get good tools. The one area I think it’s worth spending a little extra is on quality tools, including things like whiteboards, IDEs, screens, keyboards, and build servers. Amortized over thousands of hours of use, even the high-end ones are practically free. Don’t waste time and energy with slow builds and dodgy tools.

But that’s too expensive!

Expense is a common complaint, but I don’t think it makes a lot of sense when you look at cost/benefit trade-offs.

If you add up what you’re already spending on a team for the life of a project, it’s going to be quite a lot of dough. And that’s not even the right number for comparison; any software team should generate a return on investment well above obvious costs. If what I recommend above yields even a modest improvement in productivity or reduction in turnover then it’s well worth it. In my experience, the gains are dramatic, not modest.

Startup OfficeBut that’s too hard!

Sometimes these things are hard for legitimate reasons. For example, moving offices or rebuilding part of your space is undeniably a lot of work. But some hard work at the beginning of the project is much easier than years of strain trying to compensate for bad working conditions.

Sometimes, though, this is hard because companies value other things more than productivity. Some teams can’t fix workspace issues because of office politics, too-rigid budgeting, control-obsessed furniture police, nonsensical corporate policies, dysfunctional decision-making processes, or the valuing of appearance over results. If that’s your situation, consider explicitly discussing your company’s cultural problems.

If you’re scared to even bring these issues up, it’s worth asking yourself whether you’re working at the right company. Your employer may not share your desire to get things done, but I promise that there are many who do.

For more info

I know of a few good related resources:

Have more? Please mention them in the comments.

Clicky Web Analytics