Skip to main content

Distributed Agile: The World is Spherical, and It Isn't Reading Email

In 2004, Thomas Friedman famously argued that in the age of "Globalization 3.0," The World is Flat, by which he seems to have meant that with current technology, big companies can shop all over the world for the cheapest and best laborers, rather than building local teams.  The book brought the issue to the attention of the general public, particularly in the US, and spawned a big discussion, including this entertainingly polemical review from Matt Taibbi
Instructions for making your own flat globe are available here:  http://makingmaps.net/2007/09/19/making-flat-earth-globes/
Whatever you think of Friedman or Tiabbi, software development people can tell you that indeed, the modern "enterprise" team will most certainly include participants from some assortment of Western countries as well as some subset of the BRIC group (Brazil, Russia, India, and China), or maybe new players like Vietnam or the Philippines.  Distributed software development is the norm rather than the exception in the world's biggest companies.

Bulletin from pragmatic people working every day with distributed teams:  the world is most certainly spherical.  And this means that there are some things you need to consider, in order to allow your team to work together smoothly, once you have pieced it together across multiple national lines.  I have been coaching really big teams for most of my life, and I can tell you, in the spherical world there are real logistical considerations that you don't see when the world is flat. To wit:
  • Time zones:  Technology may allow you to have an instant message or a telephone call with anyone on your team at any time, but you should still consider questions like "is the person awake" in their time zone, before you press the green icon on your iPhone, or the "schedule a meeting" button in your shared calendar.
  • Local network speeds:  Technology may theoretically allow you to have a shared online project dashboard, hosted on a server in Hong Kong, so that everyone in the world can see the real-time "traffic light productivity rating" of all your project work streams, but someone needs to make sure you have sufficient network bandwidth to load the dashboard on the CFO's console in Paris in less than ten minutes.
  • Working tools:  Technology may allow you to set up video conferencing from everybody's laptop, theoretically, but somebody needs to figure out how to keep those connections from dropping whenever there is a lag in the action (yes, I'm talking about you, Microsoft Communicator and Adobe Connect).
  • Uniform logistical implementations:  If you want teleconferencing, you need to set up a room big enough to hold more than three people.  On both ends of the line.
Most daunting of all:  Communications Styles.  The modern software project team comes equipped not only with geographic and national diversity, but another significant divider:  the age/communication divide.  This has two parts:  1)  are you attempting to communicate transparently to everyone who needs to know everything?  and 2)  are your attempts working?

Sending the message (are you sending the message?):  as a seasoned executive or manager, you will have learned through the school of hard knocks (your career) that you need to be careful about "who is in the room" for certain discussions.  This is just a fact.  However, after "the room" has made a decision, who needs to know what happened?  In a global team, the answer is going to be "a lot more people than you could afford to keep in the dark if you were all under one roof."  People who don't know what's going on are going to make mistakes.  Overcommunication is needed, not tact, when it comes to keeping a global team aligned.  This said,

Receiving the message (did they hear you?)  Honestly, this is the one I am more concerned about.  As an old person, I can tell you that in general:
  • Some people read email.  Older people.  (Like me).
  • Some people do not read email.  Younger people.  (Anyone younger than me).
There are exceptions, of course.  But do you find yourself on some days to be the Grumpy Old Woman surrounded by people who don't read email?  Young people?  Do they want you to text them, or record a little video and send it to them?  Do you expect about a 10% return on your communications investment when you send an email with more than 140 characters in it?  Hyperbole, yes, but I think there is a genuine issue here, and it hugely impacts how well a distributed team can communicate.  I could certainly be wrong about the age component to the problem, but on a big, multinational, multi-cultural team, communications styles are going to be even more challenging than they were back in the day.

If you have a global team and it cannot be relied upon to read and internalize the impact of email within some agreed-upon time frame, you have a severe problem.  Because if they are not reading email, which, after all, gets sent directly to their own personal email box, and triggers some kind of beep on their smart phone, then you know they are not going to make a regular practice of logging into your sharepoint site to see what the new Program Policies are today.  The person who drops a gilded and engraved invitation is unlikely to negotiate three separate "single sign-on" logins and then navigate to some obscure page with a name that has lots of letters and digits in it, with the goal of "reading and understanding" in mind.

What's the solution?  Experienced global team wranglers will tell you that the old standby, the "Program Communications Strategy," needs to be dusted off and taken seriously in the spherical world, especially the agile sphere.  Who are the players on your program, and what are their communications styles?  Name names.  Make a spreadsheet, and make sure you understand it.  What interconnected web of live meetings during reasonable time zones do you need?  What must be expressed in writing?  What must be tweeted, perhaps with an embedded link?  What must be expressed personally through in-person conversations initiated by an email or tweet to a trusted web of people who are known to be more or less on the same page?  Does something have to be expressed in video?  How will that video be produced?  And so on.

'I Told You So' copyright* Ed Miracle 1976, www.miraclesart.com 
 Maybe there's some cost/benefit analysis that needs to be done about the overhead we take on in the "flat" world, and the hidden costs that come from the "savings" of distributed workers.  Many agilists have strong views on this point.  But if you are a person who can't just wave a wand and collocate everyone in a big barn somewhere, I suggest you just have, say, a meeting to discuss the communications strategy, supported by telepresence, and with someone taking minutes.

Comments

  1. Interesting stuff. "The solution" is particularly challenging.

    Because it's easier and easier to tell everything to everyone it's becoming harder and harder to consume it all. This is especially true when information streams all day long and folks are constantly trying to decide whether to focus on a task or focus on the flow of information.

    ReplyDelete
  2. Agreed. I'm a big fan of comprehensive email sent to to "opt in" email distribution lists. Why not make most program information ubiquitous, so long as people have the ability to choose the part of the stream of information to which they will attend?

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica