Enabling Distributed Agile Teams

Recently, I was invited to talk about enabling distributed agile teams for the Atlanta Scrum Users Group.  It’s a fantastic group… about 70-80 people made it to the show.

Before getting into the details, I have to admit that I do have a point of view on distributed teams.  I’m biased.  I had to put myself into a certain “middle of the road” point of view where I was neither for nor against distributed teams.  I am so glad I can do that (it’s a talent), because I was able to let this session change my own viewpoint.  I attempted to drive toward a shared understanding among the group as to how we could better understand the challenges of distributed teams and how to accept them — not working for or against them. Here’s the entire presentation:

I began the session with a brief definition of distributed teams.  I defined them as: Distributed teams are teams that have something preventing them from collaborating in person and face to face.

After the definition, I discussed common complications of distributed teams with the audience.  I drove toward macro level complications like language, trust, and working in different timezones. Then we discussed additional complications that the group came up with.  The interesting part is that I had to drive the group back to the macro level.  It’s easy to jump to solutions.  “I used this structure and it worked.”  It’s also easy to jump too far down the rabbit hole.  I wasn’t interested in that.  I wanted to know the high level complications.  We came up with a few more examples of pain points, like corporate enablement (do they have the access to files that they need), culture, etc.

Next, I facilitated a 20 minute game session where two games were played.  Before playing, we split up the crowd into teams that equally represented people who work in distributed teams every time, those who never work in distributed teams, and everyone in between. Each team contained a sampling that represented the whole spectrum.

The first game we played is called the Negation Game.  The idea is to have four different scenarios to represent common distributed team structures.

• Team augmented with an offshore resource
• We are the augmented team members in the US for a resources-based team in a London project
• Each team member is a distributed resource
• The individual has a paired twin resource that is distributed

During the game, I gave a scenario to each of the teams.  They were charged with asking the question, “How can we make the resource’s life miserable and less productive?”  After a brief session of answering that question, the team members prioritized their results.  I then visited each scenario and negated the top two prioritized items.  This led to what could be potential “working agreements” like “The team will not schedule meetings when the distributed team is asleep.” I am paraphrasing because I didn’t take a picture of the output of the teams… boo… next time.  Click here for the complete list of game images.  Here’s one for context.

In the second game, King for a Day, I had two teams imagine they were CIO’s considering outsourcing.  One team took why they would like to outsource and the other took why they wouldn’t.  They discussed for about 5-10 minutes.  They prioritized their results.  When I traveled to these two boards I had a realization and ran with it.

The team that had the “Wouldn’t consider outsourcing” scenario had come up with the traditional “complications” that we had partially discussed.  They came up with a few more in the game and some common issues with distributed teams like “they need more documentation up front.”

The other team came up with Business Needs like “Global workforce for hiring”, “lowering costs”, etc.

The place we ended up was fascinating.  I could relate the complications back to a business driver.  Basically, if our complications were worth less than the business driver, we should rightly be distributed.  It was powerful.  It also quickly disarmed the “business is outsourcing all of our jobs because it’s cheaper” notion.  That’s often not the case, anyway.  However, the business intent became apparent even in our fake business scenario.  Good stuff!  Maybe this would be a good way to have teams with outsourcing needs accept it more readily.  Again, I’m not an advocate — just pragmatic for the business.

Here are the game pics for King for a Day:

After the games we discussed several enablers we could implement like the communication kata.  I went over a few tools that I know that are collaborative whiteboards, mindmaps, etc.  That seemed to hold the attention of the crowd.

This talk focused on enabling distributed teams, and I am of the opinion that although structure is important, most structures can be successful in certain contexts.  It’s a tool in your toolbox — you don’t always use them — but it’s nice to know that you have them if you need them.