by Michael S. Kaplan, published on 2007/10/23 09:46 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/10/23/5613124.aspx
I was asked the other day whether I though global development projects (by which I mean projects whose creation and maintenance span multiple points on the globe) could work.
This is probably a good time to point out these are my opinions and mine alone, in case you had any doubts about the issue!
They say a picture is worth 1,000 words, so here is one. :-)
Every day when I scoot over to my office, I pass the clocks.
Here is a picture of them:
You'll see the problem right away if you spend much time around analog clocks. :-)
It's funny, but sometimes it seems like the reputation of Windows and its wandering clocks is embedded in the culture -- it is no accident that products will have configuration checkboxes like this one:
So having three clocks in the Windows International building for three of the major development areas of the group that are all a little out of sync with each other. Hmmmm.
Kind of raises the symbolic question of development projects whose work spans the globe to a new low, doesn't it? :-)
I haven't done a whole lot of work with the folks in Japan in recent years, though I do know that the IME development effort was made easier by having one of its members in Redmond (and then just rotating who that person was every few months).
This has nothing to do with either side of the communication was at fault, but just that across the Pacific, between different time zones and development styles and bug counts and thoughts on customer requirements, too much seemed to be falling into the ocean, if you know what I mean.
Maybe that is cultural issues, or just communication via phone and email, but somehow things seemed much better with a local agent in Redmond who could be there for questions, setup changes, build breaks, and the myriad of issues that a huge product can bring to the table.
Not that we fared much better across the Atlantic. I have often praised the team in Ireland in this blog, but I tend to think of their successes (e.g. Locale Builder, Keyboard Convert Service, the updates to Clock and Calendar, the Program Management side of MSKLC 1.4, and more), as due to their own initiative rather than the work on the Redmond side to support their efforts the way I think we should.
It was my principal negative feedback contribution in the Vista post-mortem, because I think we failed them as a team in some important ways, and the fact that Dublin succeeded is nothing short of proof that they can do excellent work, and can pick up the slack when we are slackers who do not communicate well....
My principal positive item was the amazing work they did in Dublin, but that's another story.
At the same time, it is hard to forget the number of times they'd spend a week tracking down a behavior bug which they'd narrow down the CultureAndRegionInfoBuilder class, only to have someone in Redmond admit it was a by design change in the class. One that nobody though to mention, even though people in Redmond were playing with the Locale Builder beta.
As the nominal liaison to the LB team I'll even take responsibility for the problem here, though the fact that no one was communicating the changes to me either would (if I were still on the team) cause me to try and fix up the communication problem with the people who were changing the platform upon which the tool was being built rather than dwelling on this as a personal failure. As it is, I just have to make sure I communicate that this has been a problem and somebody has to work to make sure it is not still one.
So, after having seen some global development projects, I'd have to say that they can work. But there are only two factors that can lead to success:
If one falls short, the other can pick up the slack, and has. But it shouldn't have to, and if everybody does their part, then everybody can do their work more effectively.
This post brought to you by ㊣ (U+32a3, a.k.a. CIRCLED IDEOGRAPH CORRECT)
# Andrew on 23 Oct 2007 5:40 PM:
I would have thought the bigger problem with the clocks is that they're only 12 hour...
# Rosyna on 23 Oct 2007 6:57 PM:
Hmm, they can use the clock slew as an input value for a seed of a cryptographic API. Or something.
# Richard on 25 Oct 2007 2:51 AM:
Working on a distributed team really does take some getting use to. Much more focus on clear and effective communications is needed... those "corridor conversations" that make up so much of a single site team are lost.
You end up needing to travel (get to know the whole team), and make this early in the team's history (not when problems come up), and spending a lot of time on IM and conference calls.
Richard
(In a team spread across Bracknell UK, Limerick IE, Moscow RU, and Hyderabad IN... within an extended team across even more locations.)