Note
Whole Team, Coaches
We communicate rapidly and accurately.
If you’ve tried to conduct a team meeting via speakerphone, you know how much of a difference face-to-face conversations make. Compared to an in-person discussion, teleconferences are slow and stutter-filled, with uncomfortable gaps in the conversation and people talking over each other.
What you may not have realized is how much this affects your work.
Imagine you’re a programmer on a nonagile team and you need to clarify something in your requirements document in order to finish an algorithm. You fire off an email to your domain expert, Mary, then take a break to stretch your legs and get some coffee.
When you get back, Mary still hasn’t responded, so you check out a few technical blogs you’ve been meaning to read. Half an hour later, your inbox chimes. Mary has responded.
Uh-oh... it looks like Mary misunderstood your message and answered the wrong question. You send another query, but you really can’t afford to wait any longer. You take your best guess at the answer—after all, you’ve been working at this company for a long time, and you know most of the answers—and get back to work.
A day later, after exchanging a few more emails, you’ve hashed out the correct answer with Mary. It wasn’t exactly what you thought, but you were pretty close. You go back and fix your code. While you’re in there, you realize there’s an edge case nobody’s handled yet.
You could bug Mary for the answer, but this is a very obscure case. It’s probably never going to happen in the field. Besides, Mary’s very busy, and you promised you’d have this feature done yesterday. (In fact, you were done yesterday, except for all these nitpicky little details.) You put in the most likely answer and move on.
As the distance between people grows, the effectiveness of their communication decreases. Misunderstandings occur and delays creep in. People start guessing to avoid the hassle of waiting for answers. Mistakes appear.
To combat this problem, most development methods attempt to reduce the need for direct communication. It’s a sensible response. If questions lead to delays and errors, reduce the need to ask questions!
The primary tools teams use to reduce reliance on direct communication are development phases and work-in-progress documents. For example, in the requirements phase, business analysts talk to customers and then produce a requirements document. Later, if a programmer has a question, he doesn’t need to talk to an expert; he can simply look up the answer in the document.
It’s a sensible idea, but it has flaws. The authors of the documents need to anticipate which questions will come up and write clearly enough to avoid misinterpretations. This is hard to do well. In practice, it’s impossible to anticipate all possible questions. Also, adding up-front documentation phases stretches out the development process.
In XP, the whole team—including experts in business, design, programming, and testing—sits together in a open workspace. When you have a question, you need only turn your head and ask. You get an instant response, and if something isn’t clear, you can discuss it at the whiteboard.
Consider the previous story from this new perspective. You’re a programmer and you need some information from your domain expert, Mary, in order to code an algorithm.
This time, rather than sending an email, you turn your head. “Mary, can you clarify something for me?”
Mary says, “Sure. What do you need?”
You explain the problem, and Mary gives her answer. “No, no,” you reply. “That’s a different problem. Here, let me show you on the whiteboard.”
A few minutes later, you’ve hashed out the issue and you’re back to coding again. Whoops! There’s an edge case you hadn’t considered. “Wait a second, Mary,” you say. “There’s something we didn’t consider. What about….”
After some more discussion, the answer is clear. You’re a little surprised: Mary’s answer was completely different than you expected. It’s good that you talked it over. Now, back to work! The code is due today, and it took 20 whole minutes to figure out this nitpicky little issue.
Sitting together eliminates the waste caused by waiting for an answer, which dramatically improves productivity. In a field study of six colocated teams, [Teasley et al.] found that sitting together doubled productivity and cut time to market to almost one-third of the company baseline.
Those results are worth repeating: the teams delivered software in one-third their normal time. After the pilot study, 11 more teams achieved the same result. This success led the company to invest heavily in open workspaces, by building a new facility in the U.S. that supports 112 such teams and making plans for similar sites in Europe.
How can sitting together yield such impressive results? Communication.
Although programming is the emblematic activity of software development, communication is the real key to software success. As [Teasley et al.] report, “Past studies have indicated that less than 30 percent of a programmer’s time is spent on traditional programming tasks and less than 20 percent of the time is spent on coding. The rest of the time is spent on meetings, problem resolution with the team, resolving issues with customers, product testing, etc.”
My experience is that programmers on XP teams spend a far greater percentage of their time programming. I attribute that to the increased communication effectiveness of sitting together. Rather than sitting in hour-long meetings, conversations last only as long as needed and involve only the people necessary.
Teams that sit together not only get rapid answers to their questions, they experience what [Cockburn] calls osmotic communication. Have you ever been talking with someone in a crowded room and then heard your name out of the blue? Even though you were focusing on your conversation, your brain was paying attention to all the other conversations in the room. When it heard your name, it replayed the sounds into your conscious mind. You not only hear your name, you hear a bit of the conversation around it, too, in a phenomenon known as the cocktail party effect.[18]
Imagine a team that sits together. Team members are concentrating on their work and talking quietly with their partners. Then somebody mentions something about managing database connections, and another programmer perks up. “Oh, Tom and I refactored the database connection pool last week. You don’t need to manage the connections manually anymore.” When team members are comfortable speaking up like this, it happens often (at least once per day) and saves time and money every time.
Important
When I see an adversarial relationship between separate groups in a team, I suggest that they sit together.
There’s another hidden benefit to sitting together: it helps teams jell and breaks down us-versus-them attitudes between groups. In contrast, distance seems to encourage adversarial relationships and blaming “those people.” Whenever I see this (for example, between programmers and testers), I suggest that they sit together. This helps the groups interact socially and gain respect for each other professionally.
To get the most out of sitting together, be sure you have a complete team (see The XP Team” in Chapter 3). It’s important that people be physically present to answer questions. If someone must be absent often—product managers tend to fall into this category—make sure that someone else on the team can answer the same questions. A domain expert is often a good backup for a traveling product manager.
Similarly, sit close enough to each other that you can have a quick discussion without getting up from your desk or shouting. This will also help encourage osmotic communication, which relies on team members overhearing conversations.
Important
Ask for help when you’re stuck.
Available instant help doesn’t do any good if you don’t ask for it. Many organizations discourage interruptions, but I encourage them on my XP teams. There’s no sense in banging your head against a wall when the person with the answer is right across the room. To support this attitude, many teams have a rule: “We must always help when asked.”
Interruptions disrupt flow and ruin productivity, so this rule may sound foolish. It takes a programmer 15 minutes or more to get back into flow after an interruption [DeMarco & Lister 1999].
Important
Fortunately, with pair programming, flow works differently. The delay doesn’t seem to occur. One programmer answers the question and the other keeps thinking about the problem at hand. When the interruption is over, a quick “Where were we?” gets work moving again.
Pairing helps in a few other ways, too. Osmotic communication depends on a buzz of conversation in the room. If people aren’t pairing, there’s less talking. Pairing also makes it easier for programmers to ignore irrelevant background conversations.
Sitting together is one of those things that’s easy to say and hard to do. It’s not that the act itself is difficult—the real problem is finding space.
Note
Start arranging for a shared workspace now.
A team that sits in adjacent cubicles can convert them into an adequate shared workspace, but even with cubicles, it takes time and money to hire people to rearrange the walls.
When I say “time,” I mean weeks or even months.
In a smaller company, you might be able to take matters (and screwdrivers) into your own hands. In a larger company, you could run afoul of Facilities if you do that. That may be a worthwhile cost, but talk to your project manager first. She should have some insight on the best way to get a shared workspace.
While you’re waiting for construction on your dream workspace to finish, a big conference room is a good alternative. One team I worked with set up shop in the company boardroom for six weeks while they waited for their workspace to be ready.
Your team will produce a buzz of conversation in its workspace. Because they’ll be working together, this buzz won’t be too distracting for team members. For people outside the team, however, it can be very distracting. Make sure there’s good sound insulation between your team and the rest of the organization.
Within the workspace, group people according to the conversations they most need to overhear. Programmers should all sit next to each other because they collaborate moment-to-moment. Testers should be nearby so programmers can overhear them talk about issues. Domain experts and interaction designers don’t need to be quite so close, but should be close enough to answer questions without shouting.
The product manager and project manager are most likely to have conversations that would distract the team. They should sit close enough to be part of the buzz but not so close that their conversations are distracting.
Important
Leave room for individuality in your workspace.
An open workspace doesn’t leave much room for privacy, and pair programming stations aren’t very personal. This loss of individuality can make people uncomfortable. Be sure that everyone has a space they can call their own. You also need an additional enclosed room with a door, or cubes away from the open workspace, so people can have privacy for personal phone calls and individual meetings.
Important
As you design your workspace, be sure to include plenty of whiteboards and wall space for an informative workspace. Try to have at least 24 linear feet of whiteboard space, magnetic if possible. You can never have too many whiteboards.
Some teams include a projector in their workspace. This is a great idea, as it allows the team to collaborate on a problem without moving to a conference room.
Finally, the center of an XP workspace is typically a set of pairing stations. I like to have the stations facing each other so people can see each other easily. A hollow triangle, square, or oval setup works well. Provide a few more pairing stations than there are programming pairs. This allows testers and customers to pair as well (either with each other or with programmers), and it provides programmers with space to work solo when they need to.
Note
For information on building a good pairing station, see Pair Programming” in Chapter 6.
The sample workspace in Figure 6-2 was designed for a team of 13. They had six programmers, six pairing stations, and a series of cubbies for personal effects. Nonprogrammers worked close to the pairing stations so they could be part of the conversation even when they weren’t pairing. Programmers’ cubbies were at the far end because they typically sat at the pairing stations. For privacy, people adjourned to the far end of the workspace or went to one of the small conference rooms down the hall.
In addition to the pairing stations, everybody had a laptop for personal work and email. The pairing stations all used a group login so any team member could work at them.
Before creating this workspace, the team had been sitting in cubicles in the same part of the office. To create the workspace, they reconfigured the inner walls.
This workspace was good, but not perfect. It didn’t have nearly enough wall space for charts and whiteboards and nonprogrammers didn’t have enough desk space. On the plus side, there was plenty of room to accommodate people at the pairing stations, which meant that customers paired with programmers frequently, and there were also extra cubbies for bringing people into the team temporarily.
The small workspace in Figure 6-3 was created by an up-and-coming startup when they moved into new offices. They were still pretty small so they couldn’t create a fancy workspace. They had a team of seven: six programmers and a product manager.
This team arranged its five pairing stations along a long wall. They had a table on the side for meetings, and charts and whiteboards on dividers surrounded them. The programmers had a pod of half-cubicles on the other side for personal effects, and there were small conference rooms close by for privacy.
This was a great workspace with one serious problem: the product manager wasn’t in earshot and didn’t participate in team discussion. The team couldn’t get ready answers to its questions and often struggled with requirements.
Some team members may resist moving to an open workspace. Common concerns include loss of individuality and privacy, implied reduction in status from losing a private office, and managers not recognizing individual contributions. Team members may also mention worries about distractions and noise, but I find that this is usually a cover for one of the other concerns.
As with pair programming, most people come to enjoy the benefits that sitting together provides, but it can take a few months. In [Teasley et al.]’s study, team members initially preferred cubicles to the open workspace, but by the end of the study, they preferred the open workspace.
Important
Don’t force people to sit together against their will.
However, forcing people to sit together in hopes that they’ll come to like it is a bad idea. When I’ve forced team members to do so, they’ve invariably found a way to leave the team, even if it meant quitting the company. Instead, talk with the team about their concerns and the trade-offs of moving to an open workspace. Discuss how team members will be evaluated in the new system and what provisions for privacy you can make. You may be able to address some concerns by providing a shared workspace in addition to existing offices and cubicles.
If a large portion of the team is against the open workspace, sitting together is probably not a good choice. If you only have one or two adamant objectors and the rest of the team wants to sit together, you may wish to sit together anyway and allow the objectors to move to a different team.
How can I concentrate with all that background noise?
A team that’s working together in a shared workspace produces a busy hum of activity. This can be distracting at first, but most people get used to it in time.
Important
For programmers, pair programming is an excellent way to focus your attention away from the background noise. You won’t notice it if you’re pairing. Nonprogrammers can work in pairs, too.
If you work alone and find the background noise distracting, put on headphones, wear earplugs, or sit further away from the team for a time. You’ll miss out on osmotic communication, but at least you’ll be able to concentrate.
Important
Pairing makes background conversations fade away.
Sometimes, the team gets a little noisy and rambunctious. It’s OK to ask for quiet—the sound in the team room should be a hum, not a full-throated chorus. Some teams have a bell for team members to ring when they want the team to be more quiet.
When one person is interrupted, the whole team stops what they’re doing to listen. What can we do to prevent people from being distracted so easily?
Especially in the beginning of the project, it’s possible that the whole team really does need to hear these conversations. As time goes on, team members will learn which conversations they can comfortably ignore.
If this is a continuing problem, try stepping a little further away from the pairing stations when a conversation lasts more than a few minutes. Interested team members can join the conversation, and the rest of the team can continue working.
What if I need privacy for phone calls?
Some people, particularly customers and project managers, need to take a lot of calls as they work. Either situate them further away from the rest of the team or arrange for an enclosed office with a door. Keep the door open as often as possible to allow information to flow smoothly.
When your team sits together, communication is much more effective. You stop guessing at answers and ask more questions. You overhear other people’s conversations and contribute answers you may not expect. Team members spontaneously form cross-functional groups to solve problems. There’s a sense of camaraderie and mutual respect.
The hardest part about sitting together is finding room for the open workspace. Cubicles, even adjacent cubicles, won’t provide the benefits that an open workspace does. Start working on this problem now as it can take months to resolve.
Don’t force the team to sit together against their will. Adamant objectors will find a way to leave the team, and possibly the company.
Be careful about sitting together if programmers don’t pair program. Solitary programming requires a quiet workspace. Pair programming, on the other hand, enables programmers to ignore the noise.
Sitting together is one of the most powerful practices in XP. It’s important for communication and team dynamics. Sitting apart tends to fray fragile relationships, particularly between different functional groups, and puts your team at a disadvantage. If your team is in a single location, you’re better off figuring out how to sit together.
Important
Multisite teams are difficult and expensive.
If you have a multisite team, consider turning each site into its own team. For example, if programmers are in one site and customers are in another, the programmers may engage some business analysts to act as proxy customers. In this scenario, the customers and development team should still work together, face-to-face, for several weeks at the beginning of each release.
If you have multiple teams of programmers, consider separating their responsibilities so that each works on entirely different codebases. [Evans] has an excellent discussion of the options for doing so.
You can practice XP with a single multisite team, but it requires a lot of travel. [Yap] has a good experience report describing how her team made this work 24 hours a day across 3 time zones. She focused on maximizing communication by regularly flying team members to a single location for several weeks at a time. They also conducted daily phone calls between locations.
Important
If you can’t sit together, talk to your mentor about your options.
If your whole team cannot sit together and you still wish to practice XP, talk to your mentor (see Find a Mentor” in Chapter 2) about your options and hire experienced XP coaches for each site.
Agile Software Development [Cockburn] has an excellent chapter on communication. Chapter 3, “Communicating, Cooperating Teams,” discusses information radiators, communication quality, and many other concepts related to sitting together.
If you can’t sit together, “Follow the Sun: Distributed Extreme Programming Development” [Yap] is an interesting experience report describing a single XP team divided into three locations, each eight hours apart.
Similarly, Domain-Driven Design [Evans] has an excellent discussion of coordinating multiple development teams in Chapter 14, “Maintaining Model Integrity.” While the book’s focus is object-oriented domain models, this chapter is applicable to many design paradigms.
[18] The best layman’s description of the cocktail party effect I’ve seen is on Wikipedia: http://en.wikipedia.org/wiki/Cocktail_party_effect.