Team Room

The Designer Corner
Many of the most interesting and valuable design discussions take place spontaneously in front of the taskboard. For this reason, we try to arrange this area as an explicit "design corner".

There is no better way to get an overview of the system than to stand in the design corner and glance at both walls, then glance at the computer and try the latest build of the system (if you're lucky enough to have continuous build).

The design wall is just a big whiteboard containing the most important design scrawls and printouts of the most important design documentation (sequence charts, GUI prototypes, domain models, etc.)

When it comes to seating and desk layout there's one thing that can't be stressed strongly enough. Seat the team together! To build effective Scrum teams it is really important to get the team together. If there's no space for the team, make space. Somewhere. Even if you have to place the team in the basement.

Once you have the team together the payoff will be immediate. After just one sprint the team will agree that it was a good idea to move together. Together means:
 * **Audibility:** Anybody in the team can talk to anybody else without shouting or leaving his desk.
 * **Visibility:** Everybody in the team can see everybody else. Everyone can see the taskboard. Not necessarily close enough to be able to read it, but at least see it.
 * **Isolation:** If your whole team were to suddenly stand up and engage in a spontaneous and lively design discussion, there is nobody outside the team close enough to be disturbed. And vice versa.

Isolation doesn't mean that the team ahs to be completely isolated. In a cubicle environment it may be enough that your team has its own cubicle and big enough cubicle walls to filter out most of the noise from non-team elements.

And what if you have a distributed team? Well then you are out of luck. Use as many technical aids as you can to minimize the damage - video conferencing, webcams, desktop sharing tools, etc.

Keep the Product Owner/Manager at Bay
The product owner should be near enough so that the team can wander over and ask him something, and so that he can wander over to the taskboard.

Managers should get involved as closely as possible. But only for a limited period, then get out and let the team self-manage. Check up on the team once in a while (not too often) by attending sprint demos and looking at the taskboard and listening in on morning scrums. If you see an improvement area, take the Scrum master aside and coach him. Not in front of the team. Another good idea is to attend sprint retrospectives, but only if your team trusts you enough not to let your presence clam them up.