Compartilhar via

Patterns and Practices for Distributed Teams

  • Artigo

This post is a summary of my lessons learned from leading distributed teams.  I've managed distributed project teams since 2001, spanning the UK, Argentina, India, and other parts of the world.  While I preferred having everybody together on site around a whiteboard to simplify and improve communication,  flexibility with distributed teams gave me access to the right talent, wherever it may be.

Key Challenges
These are some of the most common challenges I faced:

  • Trust
  • Time zone differences
  • Sharing state
  • Changes in direction that have a ripple effect
  • Communication overhead
  • Keeping everybody on the same page
  • Sharing knowledge across the team
  • Partitioning work for enough autonomy but to keep checks and balances
  • Lack of a whiteboard

Distance didn’t matter as much as differences in time zones.  If the time zone differences were too much, it meant  a lot more information, knowledge and state had to be packaged up and handed over.  However, when you leverage time zone differences, the experience can feel like you carry the baton forward, or, it’s like “The Elves and the Shoemaker,” where you make progress around the clock.

Success Patterns for Distributed Teams
The following success patterns helped improve distributed team effectiveness:

  • Forming, storming, norming and performing.   The forming, storming, norming and performing lens helps remind everybody to expect that things smooth out over time.  It’s a simple maturity model for explaining how a team gels.
  • Proxy / On Point.  One of the most helpful patterns for cross-site communication is to have somebody act as the proxy or person on point to funnel key communication.  This is especially important when their are major time zone differences.  The additional patterns, such as the show and tell, and the Monday iterations and daily stand-ups, keep this from being a single point of failure.  Instead, it’s a focal point with some accountability when key information needs to be shared across time zones.
  • Rhythm of results. Daily, Weekly, and Monthly Results.   While the team might ship every two weeks, thinking in terms of daily, weekly, and monthly results helps set the right mindset.  It creates a bias for action, and it helps get the kinks out of execution.
  • Monday Vision, Daily Outcomes, and Friday Reflection.   This is a simple, high-level pattern to drive results each week.   The approach is to identify 3 key outcomes for the week, as well as 3 key outcomes each day, and to use Friday for learning and reflecting. 
  • Stories.  By focusing on stories, it makes it easy for everybody on the team to think in terms of end-to-end stories over, features or discipline-focused activities.  It’s a great way to balance the customer, technical and business perspectives, as well as help the team converge around common goals.
  • Monday Iteration plans.  Doing iteration plans on Mondays helps set the goals for the week, as well as include everybody’s input.  We keep these to 30 minutes or less.  The outcome is the prioritized set of stories for the week.
  • Daily stand-ups.    Everybody calls in and we go around the team asking 3 questions: 1) what did you get done? 2) what are you getting done today? and 3) where do you need help?  We keep these to 10 minutes or less.  It sets the pace and prevents getting side-tracked.
  • Invoke a teammate.  One goal up front is to make it easy for everybody on the team to reach whoever they need in an ad-hoc way.  Everybody identifies their preferred email, phone number, Skype account, and instant message information, as well as their main working hours.
  • Show and Tell.  I use weekly show and tells as a forcing function.  It gives people on the team a chance to show off their work.  More importantly it’s a simple way to dog food results as well as use the team as a sounding board.  It’s one thing to build something, it’s another to show it to other people and get honest feedback.
  • Wiki Knowledge Bases (KBs.)    Using Wikis helps simplify sharing information.  It keeps people from over-engineering and it’s easy to keep updated.
  • Experience Step-Throughs.   These are simply short slide decks that mock up the experience.  Each deck walks through one story or scenario visually.  We test the experience with customers, and then we walk through as a team, from a technical perspective.  We do this for high-risk stories.   See Experience-Driven Development and Experience Step-Throughs.
  • Distributed pairing.   I’ve found the fastest way to hand over information is to pair people up.  Pairing can also help people get unblocked or keep pace.  It’s not always obvious who pairs up well, so we test different combinations to find what works best for people.  Sometimes it helps to compliment skills.  For example, one person might be great technically, while another might be great with customer experience.
  • Mentoring and buddies.   Helping new people on the team ramp up is a priority.  I’ve found the most effective way is to have people pair on things together.  For metaphors, we call it either “co-pilot” or a “student-driver” model.
  • Email Triage.  As simple as it sounds, it’s been helpful to include “triage” in the title of some emails.  This tells the team that this email thread may be a drill-down or discussion on a topic.  It’s also a quick way for anybody on the team to ask for help, since they may not know who on the team has the answer.
  • One mail.   This is a simple burn down list.  Whenever we’re pushing for a key milestone, it’s helpful to summarize the open work that everybody can see and comment on in a shared way.  To do so, we simply send out an email that lists the current open work to the team and everybody chimes in.  It helps everybody see a tangible finish line.
  • Team project site.   It’s important that the team has one place to look for all the shared information.  The most important information here is the schedule, the deliverables, status, and any key information related to either the deliverables or the project.
  • Lessons Learned.   I’m a fan of sharing lessons learned on the team.  To bootstrap these, we usually just start an email thread and dump our lessons learned.  We then port the lessons into the Wiki for easy reference.  We list the lessons as one-liners in the form of “do’s” and “don’ts".”  It’s a tickler list that provides a backdrop for richer conversations, dialogues, and discussions.
  • Checklists.  Checklists for common tasks have been the best and simplest way to share information across the team.   They help reduce mistakes and carry lessons forward.
  • Best Practices Repository.   We store our best practices for each project in a project-level repository.  At the end of the project, we port the best practices to a shared repository across projects.  This way each project is focused on “best practices,” and these are very specific and detailed.  The all up best practices are more generalized to be useful across projects, and as a starting point for new projects.
  • Reduce friction in the process.   This is a shared goal on the team to get the kinks out of any sticking points in any of the processes.  We try to innovate in the process to save cost or time or improve effectiveness.  This helps us avoid death by a 1000 paper cuts.
  • Video nuggets.   We’ve found that sharing short-videos can help share knowledge on the team very quickly.  These are throw-away videos, but they help capture a snapshot whenever somebody does research in a particular area.

No single pattern is a silver bullet.  Instead, it’s the composition of these patterns and practices that help improve distributed team communication and overall effectiveness.

Tools of the Trade
The following are some common tools of the trade:

  • Email.  This is helpful for sharing technical details, state, and general asynchronous communication.
  • Conference calls.  This is important for Monday iterations, daily stand-ups, Show and Tells, and any other team meetings.
  • Microsoft Shared view.  This is helpful for distributed pairing as well as Show and Tells, so that everybody can see a shared desktop.
  • Slides.  Slideware is a great way to share visuals and consolidate key information or to demo ideas and concepts.
  • Mind Maps.   Mind maps are a great way to pair and map out what the team knows about a given topic.  We’ve also found them useful for creating Work Breakdown Structures, as a team.  This way everybody gets to see the big picture  as a simple map.
  • Instant Messenger.  This is especially helpful for simply knowing when people on the team are around and for ad-hoc synch ups.
  • Skype.   This has gradually replaced setting up conference calls.  In fact, we’ve started having better luck with Skype than conference calls in terms of clarity in some cases.
  • Groove.  This has been our simplest way to share files instead of email.  There are some tricks to learn, but we’ve successfully shared projects of with thousands of files and hundreds of MBs.

What about you?  … What have been your best lessons learned when it comes to distributed teamwork?

Comments

  • Anonymous
    November 22, 2009
    The comment has been removed

  • Anonymous
    November 23, 2009
    It perfectly suits our own team - MCS - as are distributed one we do hit exactly the same challenges. Thanks for sharing. I shared it with our team and it already made ripple effect :) LOL!

  • Anonymous
    November 24, 2009
    Nice post. I am just curios about how you are actually making sure everybody around the distributed teams get access to the user stories? Are you using any web based tool? Also, as a matter of fact, can you share one of your example user stories? I would like to see at what level of detail you actually capture the stories when you plan for the sprint. Thanks.

  • Anonymous
    November 24, 2009
    @ Hasan Thank you. @ Alik You definitely feel the pain. @ Sohan The simplest way is a tickler list of the stories.  We track the stories in a Wiki (but any shared item will do.) We originally tried pointing a camera at our wall of stories, but it just wasn't as helpful in the long run. We use the tickler list (simple one-liners) of the stories as a backdrop for conversations and elaboration.  The one-liner tickler list helps for tracking and sharing.