Technically Distributed: Tools and Techniques for Distributed Teams

This afternoon at Agile 2010 I ran a session called Technically Distributed: Tips and Techniques for Distributed Teams (slides are at the end of this post). While I gave information about some of the tools I’ve used for teams, I think the key revelations came from two exercises we did.

In the first, the teams had to create a picture. Their “product owner” had the picture, but wasn’t allowed to show it to the teams. This was to simulate that most product owners have a great vision in their head of what they want – the tricky part is communicating that to the team. We ran the session with a 5 minute backlog planning session, followed by two iterations of 2 minutes of planning followed by 10 minutes of working. Half of the team had a collocated product owner, while the others had to send a “Business Analyst” to the front of the room to ask the PO questions when they had them. At the second sprint I swapped so the collocated teams were now distributed, and vice versa.

What was interesting were the insights the teams uncovered. The biggest frustrations from the teams were having to wait for the BA to get more information, and several tried just sending everyone up. On the Product Owner side, the biggest frustration was how to communicate the vision – there was lots of spatial information to communicate, and strange objects. But by the end everyone had finished (and come pretty close to!) the picture. We identified three key areas that attributed to them being able to do that:

1. Prototyping. Words alone were not good enough to communicate the vision. It was only through rapid prototyping and iterations that the teams were able to move towards a solution
2. Framing the vision. On the PO side, they weren’t allowed to just draw the picture, so they had to find creative ways to express their vision. During the retrospective between the two sprints, I recommended to the POs that instead of doing something to the team, that they do something to their vision to communicate it to the team. I then took a sheet of paper and folded it into quadrants – simulating a common language for the teams to talk to the PO
3. Collocation. Even for the distributed teams, the Product Owner was “onsite” during the planning period. The teams took heavy advantage of this to do prototyping to understand the vision.

After the exercise was complete, we played a round of Speed Boat. I asked people to write down the anchors that held them back as distributed teams. As you can see from the picture, we had quite a few anchors. We didn’t have a chance to group them during the session, but I took them back to my room and found out that the spread across categories wasn’t quite what I was expecting. We had five main categories – Trust and Team, Communication, Time Zone, Org Issues and Tech Issues. Maybe it shouldn’t have been so surprising that very few of the issues were technical in nature – reinforcing that tools are not going to solve the distributed team problem. It ended up like this:

Another interesting aspect was that there weren’t a lot of duplicates. Here are the cards, with duplicates removed:

• Organizational Issues
  • Lack of a company wide commitment to agile and education
  • Travel budget
  • Length of iterations
  • Lack of shared space for the team
  • Cost savings in offshoring (using junior developers, no travel budget)
  • Not enough ‘gas’ (vision/agile) to get to the ‘island’ (goal)
• Technology Issues
  • Availability of videoconferencing units
  • Not Visual
  • Lack of tools for efficiency
  • Latency
  • Lack of “remote whiteboard”
  • Low fidelity communications
  • Not enough bandwidth
  • Network Connectivity
  • Frustration with tools
• Time Zone
  • Time Zone Differences
  • Delayed Communications
  • One location bears the burden of timezone differences
  • Difficult to schedule meetings all can attend
  • If someone doesn’t respond, you lose a whole day
  • Delivery team doesn’t have access to stakeholders due to different timezone
• Trust and Team
  • Other people’s problems not my problem – made worse by lack of contact
  • Product Owners uncomfortable working with offshore resources
  • No common language between product owner and the dev team
  • Lack of Trust / No Trust
  • Trust building difficult (don’t know what others are doing)
  • Visa process for various countries
  • Feeling Invisible
  • Lack of knowledge sharing
  • Developers isolated from BAs and testers
  • Lack of dedicated team members
  • Professionalism / Proactivity hindered by “invisibility”
  • Too many chiefs
  • Product Owner Availability
  • Language Barriers
  • Culture Clash
  • Too many unrelated staff at the table
• Communication
  • Communication
  • Unclear expectations
  • Vision, Business Knowledge, how what they’re doing is (or is not) adding business value
  • Unclear / Complex requirements/stories – epic sizes
  • Change in Priority
  • No Priority
  • Weak Information Radiators
  • Poor “bandwidth” of written word
  • Relying primarily on written requirements
  • Lack of business knowledge
  • Team vision not distributed
  • No sense of urgency to get things done / delays are OK
  • Fallback reliance on more extensive written documentation rather than invest effort and money to achieve more direct team communication
  • Conversation takes more energy
  • Email instead of phone
  • Keeping focus during virtual meetings

I had a great time, and most of the feedback seemed to echo that the participants did as well. I promised that I would list out the tools I mentioned or use, so here they are:

• Wacom Bamboo tablet – This awesome device costs about $60 and plugs right into your USB port. I use it when I’m doing remote coaching by just opening Microsoft Paint and sharing it using LiveMeeting or GoToMeeting. It’s not as smooth as a whiteboard, but it is a great help
• Google Docs – Google Docs has a decent Word Processor and Spreadsheet that work well for collaboration, but they’ve recently added a drawing capability. It’s pretty close to a digital whiteboard, and I find it works better that the whiteboards from the meeting services like LiveMeeting.
• PlanningPoker.com – Mike Cohn has a great resource for teams wanting to do Planning Poker online. Within about 5 minutes you can have a game setup for collaborative play with Planning Poker.
• Innovation Games ® Online – Luke Hohmann’s awesome Innovation Games ® have an online piece which can be very helpful for product planning and prioritization. In fact I did a session at XP2010 on using the games for planning if you want more information.
• FitNesse – FitNesse is a open-source framework for acceptance testing using a Wiki. It is very powerful when your Product Owner is not collocated with the team.
• ProjectCards – ProjectCards is a great tool for distributed teams. It’s client/server, but the real time updates are just so addictive.

Thanks to everyone who came out! And if you have any other tools or tricks, please feel free to leave them in the comments below.