Daily Team Interaction

One of the Agile principles that is high on my list is that the best team communication happens face-to-face on a daily basis. Two of the principles outlined in the Agile Manifesto address this:

Business people and developers must work together daily throughout the project.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Co-Location is the key to making this happen. When I talk with people about the importance of project team co-location, I am surprised at how many people believe that their teams are co-located when they really aren’t. For many, if the team is under one roof then they are golden. If you are in this camp, ask yourself: do your project teams sit right together, or are there project discipline islands around the office, e.g. QA in a huddle room, Dev in the “pit,” DBA on another floor, BA’s & UI designers here there and everywhere? Also, how many people regularly work from home, out of another office, or at the customer site?

Definition of Co-Location

Here are the distinguishing features of what I would consider true co-location:

1. Project team members sit together in the same office most of the time.
2. Project teams are integrated, i.e. testers, business analysts, DBA, UI designers, etc. sit amongst the developers.

Advantages of Co-Location

Let’s state the obvious: co-located teams that talk face-to-face on a daily basis are the ideal. I always do whatever I can at the outset of a project to get the project team together in the same room, working side-by-side with the various disciplines. I do this because I have experienced the upsides of co-located teams (as well as the downsides of distributed teams):

• 
  Improved communication –According to a well-known UCLA study on human communication, the actual words represent only 7% of communication. The rest is tone of voice and non-verbal cues such as facial expressions, body language, etc. Of course, there are many means for communicating beyond face-to-face, such as by phone, email, and instant message (IM). However, face-to-face communication wins hands down. It doesn’t mean there won’t be disagreements and sometimes heated discussions, but in general people are more professional and can communicate at 100% instead of 7%. The rapid fire exchange of ideas that face-to-face enables results in better and more decisive actions, and in a much more pleasant manner. By contrast, I have seen any number of IM and Email back-and-forths spiral out of control, beginning with misunderstandings and escalating to unprofessional jabs and tirades. Emails and IM are simply not comparable to face-to-face communication, although I readily admit that a well-placed smiley face can go a long way :)
  
• Reduced tribal behavior – It is the nature of people to congregate around their leads, e.g. you end up with a QA area, developer area, UI designer area, etc. However, this can be destructive to team cohesion. At one point I managed a team where everyone sat together with the exception of the QA team, which was in another building a few miles away. Within a few weeks, guess which team was the exclusive owner of all of the idiots? Of course, the QA group had their own gripes with the rest of the team. Separating teams by discipline is definitely not the answer. I realize that there will always be natural tension between “Check and Balance” relationships, such as business analyst and developer, developer and QA, etc. However, when sitting side by side, I don’t hear as many sweeping statements like, “Those developers have no pride!” or “Why don’t the testers get a clue!” In general, people are more respectful and professional when working closely together. They hang out, go to lunch, get to know each other, and, as a result, cut out a lot of the negative behavior that slows a team down. The result is team cohesion, better solutions, and quicker delivery.
• More knowledge sharing – When a team sits together, they all benefit from knowledge sharing, and are more likely to stay on the same page. By contrast, working in silos is a recipe for disaster, leading to redundant work (“I didn’t realize you already did that”), backtracking (“We changed the architecture last week, you’ll have to refactor”), and in general, all of the negatives associated with communication breakdowns. When the team sits together, everyone hears the same announcements and takes part in the impromptu training and planned brown bags. If you get stuck, there is bound to be someone that can help. Teams that sit together maximize how much they learn from each other.
• Teamwork – Being part of the team has a positive impact that can inspire otherwise less-disciplined team members to step it up to support the team effort. Something about battling side-by-side in the trenches as part of a team results in loyalty, a better work ethic, more fun and higher job satisfaction.

Addressing the Arguments Against Co-Location

So you are sold: co-location is the way to go. Now, how do you do it? In most cases, it is harder than it looks and often requires some compromise. Here are some of the key arguments you might get, and how you can work around them:

• 
  I am more effective when I work from home – The typical argument here is that they won't be getting interrupted all of the time and are therefore more able to maintain focus on their deliverables. Yes, silos have some benefits, but as previously discussed, there are major downsides. This is not to say that working from home should be strictly verboten; team members who prove their discipline while working at home, who are consistently accessible during work hours, and most importantly, who reliably deliver, should be able to work from home from time to time. However, if this is more than a day per week you start noticing the downsides. There is really no substitute for having the team together.
• I don’t want to be separated from my department – Some people are loathe to leave their own enclave of DBAs or UI designers, etc. They like to hang out with their buddies, share jokes and stories, and swap ideas for improvement in their discipline. They may also fear that they could be deemed expendable if away for too long. The fact is, most of these points are valid. I recommend that the team stick together, but that people attend their discipline group’s weekly and monthly meetings, brown bags, etc. If their group has a blog or a wiki for keeping in touch, they should remain active in this activity. If absolutely necessary, perhaps they could spend a day per week sitting with their group to keep their foot in the door. However, the bulk of their time should be spent with the project team.
• This isn’t my only project – This comes up all of the time, and there are 2 flavors. The first scenario is where you have budgeted for full resources, but get split resources. For example, you have budget for 2 QA FTEs, but get 2-4 split resources who will work your project and at least one other project. I had a situation where I shared a resource with 2 other projects. By the time they finished their stand-up meetings, other meetings, and related travel, half of their day was gone before they could do any real work. I might get an hour or two out of them a day. Serving two masters, and so forth, is frustrating for everyone involved. If you are good at picking your battles, this is one worth fighting. Even if you have to settle for less resources than ideal, you are already better off if they are dedicated to your project. The second scenario is where you only have budget for a partial resource, for example, 25% of a DBA’s time. The rule here simply needs to be that, while they are working on and billing to the project, they should be sitting amongst the team.
  
• If I’m with the team I’m not doing my job – Some roles, such as business analyst and UI designer, need to spend time with the customer to extract requirements. The point isn’t to force everyone to spend 100% of their time with the team. However, don’t gather requirements, then sequester yourself somewhere else to write them up. Sit with the team and do your work there, making time for questions from the team that will almost always save you time and hassle down the road.
• My boss won’t let me – Bosses sometimes feel like their fiefdom is diminished when seats in their area are left empty for the duration of your project. Yours may be a diabolical plot to steal their people away forever. They may also have gotten in the habit of having their people wear many hats; sure their people are 100% dedicated to your project in principle, but they also need to be kept close just in case, e.g. production issues, system upgrades, all-hands-on-deck for projects that have reached DEFCON 1 levels of crisis, and even for fixing the boss's computer issues. Of course, some of these distractions are exactly the types of things from which you are trying to extricate your team members. Focused team members will help the team avoid missing deadlines and becoming yet another "DEFCON 1" project. The best way to convince a team member’s boss is to discuss the benefits of co-location as outlined above. Most can catch this vision enough to work with you. You may have to make some compromises, such as a day per week back at their office and maintaining availability for serious production issues, etc. At the end of the day, your team will be together most of the time and will benefit from the close communication. Since the team member is a bit more out of site, the boss will usually only rope them in for the most critical issues.
  

Do not underestimate the importance of these discussions prior to the start of the project. Once a project gets going and the team is together, you will be very glad about any efforts you made to get the team co-located. Again, some compromise may be necessary, but having the whole team together most of the time may be one of the most important things you do to raise the odds of a successful and enjoyable project experience.