Agile principles emphasize face-to-face communication wherever possible. The benefits of this are demonstrated best at the team level. When teams sit apart from one another, the overhead of communication and the problems that arise from a lack of easy communication are seen daily. Studies have shown that when teams reduce their physical distance between themselves, their performance increases in many ways(*).
Eventually teams realize this and rearrange their seating arrangements to improve communication.
Teams that co-locate are often limited in their options for team rooms. Often the office is arranged in small cubicles that cannot easily be removed due to power and data wiring limitations. Fortunately team rooms or “bullpens” are less expensive to create than cubicle farms or separate office spaces, so if you are lucky enough to influence the initial office space build out, you can create an ideal space for a team. Otherwise you’ll need to slowly adapt your current space. Some studios set aside a modest budget to slowly convert their spaces.
What makes an ideal team space? There is no ideal space for all teams. Sometimes teams can’t even agree among themselves what makes the best space. If you have a cross-discipline team, perhaps the programmers might want some windows while the artists don’t want the light from the outside. It’s up to the team to work out what is best. Here are some things to consider when deciding about your team room:
- Is there enough wall space for your task board, information radiators and white boards? You can never have enough space for white-boards!
- Is there enough “slack” in the space so that people can occasionally pair up at a computer? For example, can a programmer sit with an artist to discuss a problem?
- Is there space for meetings, such as the daily stand-up or a play-through? Is there a dev station available to conduct a team play-through on?
- Is the room “off the beaten path”? A lot of traffic from outside the team in the area can be disruptive.
- Are there local private areas? More about these below.
There are typical concerns that are raised about team areas. These are:
“Programmers (artists, designers, etc) need to work in quiet isolation in order to focus and be effective. We can’t do this in a noisy team room with constant interruptions”.
This is a common concern about working in close quarters with other developers. For certain, there are more interruptions in a team room. Most of them are the point of the team room. When individual developers are trying to achieve individual goals, then interruptions often impede them from that goal. However agile emphasizes the delivery of value integrated into the game, not the value of finishing “parts” that should join seamlessly because a document says they will.
When a team is focused on achieving a common goal that requires everyone’s participation, fast access to other team members who can help progress is not only necessary but essential. It doesn’t make sense to have an animation programmer on the other side of the building implementing a system that may or may not be of any use to the animators someday. They should be solving the problem together.
Team rooms for people working on separate goals don't makes sense.
As far as noise level, if it starts getting in the way of progress, the team must solve it. Every team that I have seen transition to a team room doesn’t want to go back to isolation. If they felt isolation would benefit their performance, they would have permission to do that too.
This doesn’t mean that the people never need privacy. Having a few small offices around the team area where people can go to work on a tricky problem or have a private conversation is important.
“If I am not sitting in a group of people of the same discipline, then I won’t learn as much and be able to help them out as much.”
This argument is a more difficult barrier for teams who wish to co-locate. It has some validity. One example of this was in a studio where half a dozen AI programmers spread out across three teams. Following this, three incompatible AI solutions emerged that duplicated effort. However the best solution wasn’t to let them sit together in a single team. The reason was that they didn’t create the best AI system for the team. In fact they produced an AI system that was state of the art. It was rapidly developed and did amazing things in their test environment. Unfortunately this system didn’t meet the needs of the game. When matched up with motion captured animation in a representative level (rather than the test environment with ideal test shapes) the AI was incapable of even simple navigation.
What is the reason for this? Did the animators and level artists create the wrong assets for the AI or did the AI programmers create behaviors that were incorrect for the animation and level layout? It was really both. They should have developed everything together. They would have learned along the way to alter the behaviors and assets to accommodate reality. They would have collaboratively built knowledge of the best solution.
This drives cross-discipline teams and raises the value of instant face-to-face communication. What about the original problem of collaboration between members of the same discipline? How do we avoid the AI programmers going off in separate directions? One solution is orthogonal teams. Nothing prevents the AI programmers from gathering once a week or once a Sprint to discuss their work. It just doesn’t need to be as frequent as communication within a cross-discipline team.
* The effects of R&D team co-location on communication patterns among R&D, marketing, and manufacturing, Christophe Van Den Bulte, Rudy K. Moenaert, 1998