ProgrammersTwelveHoursApart

When a project has developers in different time zones... USA west coast and India in my case.

Project with this kind of time-zone difference have "elves working in the night", a potential speed enhancer, but also they also lack any real-time communication (unless I call India at 9 PM my time.)

KeithRay 2003.04.02

Question here is what?

JimBullock, 2003.04.03

Here is California. I had a team in India assigned to my project two jobs back. We had a lot of late-night, early morning conference calls. Coordination was difficult: without being able to wander past them, it was hard to notice when they were heading off in a different direction. Only one person on the team had visited us in California. Communication got a lot more difficult when he left the project.

DaveSmith 3 Apr 2003

I don't see how geographically dispersed teams can succeed if they have no personal basis (trust, respect,...) to manage their relationship. JohannaRothman 2003.04.04

Those phone calls are hard. Tactical stuff goes by email, so the phone call is for the human/personal stuff... in my case, one introvert trying to establish a relationship with another introvert, with different cultural backgrounds, and noisy phone connection.

KeithRay 2003.04.04

Oh dear. If you want concrete suggestions for how to make the phone calls work better, take a look at the sidebar at the end of Managing Multicultural Projects with Complementary Practices. Maybe you just need a facilitator for a couple of calls to get you folks on a track you can follow? -- JohannaRothman 2004.04.05

So getting better at talking across the time difference is one mitigation. The other is reducing the need for and impact of that communication.

This is an example where a regular pulse of deliveries (see IterativePlanning) might help. If you folks are working from two repositories, or with two test beds, for example, weekends (the 36 clean hours you *ought* to get each weekend) would make a great snych up time. You push some of the coordination between teams into this regular synch process, and you are less dependent on talk. "Everybody in the same room talking more" would be better but that options not on the table, apparently.

Are you guys working together on this (Keith & Dave?) I'm envious. I'd much enjoy working with either of you. -- JimBullock, 2004.040.05

Dave isn't on my project. I only saw him at AYE.

I'm trying distributed extreme programming... no pair programming across time zones, but I encourage them to integrate code daily, which I review and comment on (I try to point out the good stuff as well as stuff I'd like changed.) They can send me questions and I respond.

KeithRay 2003.04.05

*cough* and BayXP

JohnSuzuki has a great article on this subject in the AYE Articles database.

http://www.ayeconference.com/Articles/Somebarrierstoteams.html
- JerryWeinberg 2003.04.06

I just remembered one of the other joys of having a team 12 1/2 hours away: Holidays. Chances are excellent that your holiday calendar and theirs don't mesh. There's nothing quite as frustrating as thinking you've got a schedule worked out only to discover that your coworkers aren't in "tomorrow" because of some annual festival.

If you're working with a remote team, a Very Good Move is to synchronize your holiday calendars early. --DaveSmith 2003.04.14

Since India has about twice as many holidays as the US, I'd like to sychronize with them.

KeithRay] 2003.04.15

Is the holiday sync just wishful thinking? Even here in the U.S. some communities are out of sync with others. The Jewish community in particular may take Yom Kippur and Rosh Hashannah off even though they are not on the schedule. (My town's schools give both those two, Good Friday, and Christmas off to all the kids. If the Islamic community keeps growing, I can imagine Eid being added.) Add the complications of, say, Hindu holidays or even the French secular practice of taking the month of August off and you've got something non-solvable unless you ask people to set aside their nationality and religion.

But then, perhaps I'm missing the boat not having been in the situation. Are we just talking about arranging teleconference meetings only on non-holidays for everyone?

Mike Melendez 2003.04.16

By "synchronize", I mean sharing calendars, both regional and, if appropriate and necessary, personal, so that you won't find yourself stuck when someone at the other end of the long wire isn't there when you expect them to be. Perhaps "synchronize" is the wrong term, as it might suggest establishing a common set of holidays. That might be interesting, but I have no belief that it would be workable.

When people are all in the same building, it's easier to mention in passing that you'll be out on vacation this Friday. And all of the people in the building might get the email from Facilities reminding them that the power will be out Wednesday afternoon. People 12 timezones away might miss that, and be surprised when they can't contact you. --DaveSmith 2003.04.16

There's a principle here I think. You've got to work on communicating information where you are used to being in synch with the people you work with, you might have different expectations, and where casual, ad-hoc opportunities for communicating aren't available or sufficient. So you've got to work at communicating things like holiday calendars, when you suddenly go multi-locatin and multi-cultural on your development team.

I suspect this might be an indicator for when an InformationRadiator would help - to share information that used to be "the same", but now is different, where there's no guarantee of casual communication working. How many times has an organization grown to where hallway conversations don't do it for coordinating work (not just development) then fallen down because they didn't get serious about this harder communication challenge?

Of course, I could say that this is just an example of the yet more general principle of tuning your processes for the problem at hand, but that would be repeating myself, so I won't do that. -- JimBullock, 2003.04.16

Say, Keith, do any of your Indian developers review and comment on your code? I've found that's a great way to legitimize a practice - be willing to engage in it myself. Great way to build a personal connection and get listened to as well. -- JimBullock, 2003.04.16

Information radiators work because they're painlessly visible to a colocated team. People see them when walking by, and can gather around them and have discussions. A calendar up on the web, while useful, isn't an information radiator, at least not in the sense that Cockburn defines them. --DaveSmith 2003.04.16

OK.

Care to offer a label for some kind of shared info commons that isn't physically colocated? Such things seem to be useful to me, like, oh I don't know, a wiki, for example. -- JimBullock, 2003.04.17

Perhaps (good) Wiki, Blogs, and forums should be classified as InformationMagnet -- they work by pulling people with desirable information that leads people to seek them out.

The difference between and InformationRadiator and an InformationMagnet is that InformationMagnets preach to the choir. People who visit them are mostly already insiders. On the other hand, an InformationRadiator attracts both insiders and outsiders.

There's nothing wrong with discussions among the insiders -- I wouldn't pass up SHAPE for the world -- but their influence is necessarily more indirect.

--BobLee 2003.04.17

When your team is dispersed, perhaps a blog/wiki is the best you can do. The problem is that you can't be assured that people will look at it on a regular basis in the same way the would a common whiteboard. This is one of the conundrums of distributed teams. --DaveSmith 2003.04.17

My own location is deep into email as an online information radiator, (note lower case avoiding the link) broadcasting much to large classes of people. Discussions much broader than a dialog get started. Information is widely available. I remember that being a broad practice in the late 80's at the companies I worked for. The downsides are also numerous. You drown in information. Items important to your work get lost in the forest. Newsgroups attempted to solve that problem, particularly with threading, but also collecting broader lines of thought into a single newsgroup. Now there are tens of thousands of newsgroups and moderation is far more common in the serious ones. The web, originally, was good for sharing information but not for discussion. Wikis seem to have addressed that rather well Blogs are something different; one person's observations shared with those of like mind without having to seek them out.

Yet my company continues to use email. We're small, 30 people, and deep into telecommuting. So deep, that the work-from-home engineers (one each) in Toronto and England seem little different from the local who always works from home. Weekends and holidays here don't really seem to matter as all of the key engineers tend to read email everyday, except when they are on vacation. And yet, we are not deep into crisis management. Not that we always hit our scheduled dates. We just don't seem to go into a tizzy when we don't, though we do hit an advanced state of self-awareness. Email: does that help for those 12 hours apart?

MikeMelendez 2003.04.18

Jim - they have been reading the code, and sometimes imitating it too slavishly, but I haven't yet encouraged them to send us feedback on the code. I will.

Email works when people read it. My wife, working with people in China, does conference calls and email. The horrible phone connections I've gotten discouraged trying conference calling again.

KeithRay 2003.04.18

In my experience, email is a horrible "radiator". Trying to cull information out of email is like fishing in a fast moving, polluted river after a flood. Information in email doesn't "stick". It gets buried. You end up spending as much effort fending off the stuff you don't want as finding what you do want. In a discussion, you can't be assured that two people have seen the same version of a message. ("But have you seen the latest latest schedule?")

An InformationRadiator on a wall (or floor, or, failing that on a web page) gives everyone a common picture to agree or disagree about, with fluff and chaff removed. --DaveSmith 2003.04.18

I've seen an awful lot of white board ignored, religiously.

There's a piece of social engineering that goes on, that makes the thing we look at be the thing we look at, whatever the material and location. I am observing a couple collaborations I'm involved with lately, and I am discovering that the thing that makes a source of information useful is the agreement that this source is the the thing we look at.

I do think some media are better and easier than others depending on circumstances. But the agreement has got to be in place or the format doesn't matter at all. -- JimBullock, 2003.04.18

Wait a damn minute. Is there no project definition? Do you not have measurable goals against which progress can be unequivocally assessed?

I agree that dispersion geographically and temporally can be a problem which needs special care, but I think the way to assure that everybody is pulling in the same direction is to make that direction (which changes frequently) so clear that your mother in law could be expected to make correct assessments of progress.

If you don't have that, then continuous on site coordination is not enough to give you a good chance at succeeding. This is why around half of the big projects fail. And why they fail AFTER all the time and money, or much more than all that was budgeted, has been consumed.

Perhaps that is so transparently obvious that everyone assumes that everybody does that measurable goals thing already, but I don't think so. See TrashingRequirementsEngineering, ExtremeIncrementalism, and TypesofCodeReview.

DickKarpinski Nitpicking Monster 16 Aug 2006

Dick,

I like seeing your comments. It's good to have you back. I remember you from the first conference. I hope you are well.

I don't think you have met Jim Bullock. I am sure both you and he will learn something from conversing with each other. I'll step back and let you and Jim converse.

Enjoy, SteveSmith 2006.08.16

See DickKarpinski for my response.

Updated: Thursday, August 17, 2006