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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …