Where waterfall projects went wrong is where agile principles were born. The war room – gathering the team in one location for a short burst of effort – is a perfect example of this concept.

[featured-image single_newwindow=”false” alt=”camknows | War Room | Flickr” title=”camknows | War Room | Flickr”]camknows | War Room | Flickr[/featured-image]

I remember early in my career working on a distributed team. My team was on the east coast while a fellow developer led a team on the west coast. We were struggling with getting both teams in sync on how to use the latest internal API’s.

Code was changing rapidly and the written word didn’t have the bandwidth to keep up. Instant messenger worked ok, and emails got some of the points across. But there was still a major gap in communication.

Finally, after way too many late nights of spinning our wheels, I stormed in to the CEO’s office and asked, “Can we just fly out to the west coast for a few weeks and get this figured out?”

Surprisingly he said, “Go.”

Once the teams were together, we immediately setup a “war room” and got to work. It took a few weeks, but having the team together in the same room made a significant impact on our progress. I think 3 key things changed once we were together that helped us past our issues:

  1. Feedback was immediate:  The teams were pair programming and peer reviewing features as they were written. Anyone on the team could see or hear what was going on and could interject as needed. No lost emails or missed chat messages to hold us up.
  2. Conversations gained context:  Instead of suffering through the limits of 300 word emails, people could collaborate. The combined team organized in to groups based on the current user story and got to work. Questions were answered and whiteboards were used to clear up any misunderstandings. No mass email could possibly compete with these results.
  3. Face time made a difference: Non-verbal communication IS communication. Your face often says more than your words. So can your body language. These cues enrich the dialogue and help foster stronger relationships and trust between team members. An emoticon in an email just doesn’t cut it compared to a real smile. 🙂

Clearly, the co-location of the team for a short time made a major impact on the project. While we were able to carry some of the momentum of that trip in to future releases, we were never as effective apart as we were together.

Back to the question that this post posed:  Do scrum teams need to be collocated? I don’t think it’s the end of the world if you are on a distributed team. Being aware of the moments where face to face meetings are necessary is critical to success. Other tools like webcams can also help. But you are leaving team capacity and trust on the table when you have distributed teams.

My preference is a scrum team in one location.

[reminder]That is one of my more intense experiences about what happens when a team is not co-located and the project goes bad. What have you seen on your teams? How have you made distributed teams more efficient and effective?[/reminder]