Challenges of real-time collaboration among distributed team members
How does a distributed team perform the basic Scrum techniques of all day real-time collaboration, planning poker, and task boards? I ran into a great example this week that demonstrated why the consultant advising my currently company during our transition from waterfall to scrum warned us that it’s much easier to implement Scrum and to quickly achieve good velocity by having 100% collocated teams. We’re fresh out of formal training and looking at starting our first formal sprint just two weeks later on May 4. The training week was a whirlwind affair of teaching us the basic techniques (which work fabulously when you’re all together in the same room. However, there was no time to really think about how we were going to do this effectively once two of us went back to their remote offices in other states.
So Monday rolls around and an email thread gets rolling regarding some ideas for how to resolve some of these basic communication issues before our first day of sprint planning on May 4. By 10:59am, two questions had been posed for the entire team to weigh in on. 2 hours later, just over half the team had weighed in on one question, and only 2 people had weighed in the other question. Long story short, follow up emails and IM pings were needed to finally get all members to weigh in by more than 5 hours later.
If we had posed those same questions during an ad hoc discussion when we were all in the same physical bullpen during training week, a 5-minute discussion or less would have achieved consensus on both questions.
As this example shows, email and other forms of non-realtime collaboration such as discussion forums are anything but agile, and seem like the wrong tools to enable Scrum among a distributed team. So the first basic technique of Scrum–all day real-time collaboration, which I like to call “the virtual bullpen”–requires some special tools to enable. Doing this through phone systems and all day conference calls is cumbersome and eats up valuable ports that are expensive to maintain. A capable tool that might surprise some readers is Ventrilo, which if you know about it at all you probably associate it with online gaming guilds and not serious business endeavors. Ventrilo is very inexpensive and can scale cleanly up to 200 concurrent voice users. It stays on all day in a simple client window like a typical IM client. When you want to talk to the group, you just push a button while talking. No need for cumbersome headsets: it works just fine with a desktop or laptop mic and cheap speakers.
But even if you find a capable all-day voice collaboration tool like Ventrilo, that doesn’t help your teams that are spread across timezones and can only communicate via voice during a short window each day. Voice collaboration is useful only to the people who are available when the conversation is happening, after which it is lost and you’re reliant on your teammates filling you in later with summary information, which defeats one of the main techniques of Scrum–close collaboration all day long.
The most promising tool we’ve found so far that avoids the downsides of a real-time voice system seems to be text-based realtime collaboration tool called Campfire, which makes it easy to catch up on the discussion that happened while you weren’t with the team, and which keeps an easy to use historical archive of every day’s conversation for later reference if need be. Of course, if you’re not actively keeping tabs on the Campfire conversation stream, we’re back to the same time-efficiency problems of email or forums. And more importantly, using a tool like Campfire requires self-discipline to have *all* of your conversations in Campfire and not in your own physical bullpen with the few team members at hand, which can be very tempting.
More about task boards and planning poker coming in the next few days.
