is there any way to collaborate in onsite offshore model ?

[shailesh sonavadekar]

hi there . in the scenarios , where there is agile methodlogy is used like xp & onsite & offshore model is used for development & both the teams are working simulataneously on the same code & there are lots of mistakes, people working on same code. makiong changes. resulting in code smells or spagehtti code.

is there any way to avoid this ? any process ? what is your esp javaranchers ? how to effectively use CVS on such crucial issue & save imp man hours ?

advice from great proponents of XP like Martin , Scott will greatly appriciated.

with warm regards
Shailesh M. Sonavadekar

[Jared Richardson]

You mention XP and agile methodologies. You are using a Continuous Integration system, right? Check out Martin Fowler's paper on CI. CI

The CI system compiles after every code change, catching tons of basic editing errors in the same files.

Then the CI system will run your test suite. You do have a test suite, right? If not, check out my blog entries on Blitzkrieg Testing and Mock Client Testing. These entries are about adding test coverage quickly to an established system.

By having a basic test suite and letting a CI system run after every single code commit, you'll catch errors as soon as they occur. This fast feedback will help developers fix the problems as soon they commit the code (before they forget what they were doing in the first place!)

I recently heard Dave Thomas (or Pragmatic Programmer fame) speaking about his work with Ruby. Many of the developers are Japanese. Dave doesn't speak Japanese, so when something is broken, he and the other Ruby developers swap unit tests! These tests transcend language barriers and let everyone have a clear, well-defined solution to a problem.

You might want to check out Mike Clark's book Pragmatic Project Automation if you questions about how to set up build scripts or a CI system.

[ July 13, 2005: Message edited by: Jared Richardson ]
[ July 13, 2005: Message edited by: Jared Richardson ]

[Ilja Preuss]

Additionally, communicate as much as possible. Do your standups together, per video-meeting or something. Practice cross-site pairing, using collaboration tools like remote application sharing, webcams etc.

[Jared Richardson]

Originally posted by Ilja Preuss:
Additionally, communicate as much as possible. Do your standups together, per video-meeting or something. Practice cross-site pairing, using collaboration tools like remote application sharing, webcams etc.

Good point! One tool we've been using at SAS is the blog/plog. (A plog is a project blog.) I have team members update their plogs weekly (at a minimum... most do daily updates). This is an easy and cheap way to do cross site information sharing and it's lets management "drop in" and see what's going on as needed. I like having the information more persistent.

[Scott Ambler]

You might find Bridging the Distance and Agile Outsourcing to be helpful.

- Scott

[Ilja Preuss]

I've heard that meeting face to face at least once at project start can make a big difference! Some teams even manage to have single team members swap locations from time to time, which greatly improves the understanding between the groups.

[Scott Ambler]

Another interesting essay is Communication, in particular the Modes of Communication diagram. The way you want to use this diagram is to understand that there are many ways to communicate/collaborate, and that you want to use the most effective ones given your current situation.

- Scott

[Barry Andrews]

Is there anything specifically mentioned in the book about how to manage offshore development? The biggest problem we face is communication. A few weeks ago, we were sending emails into the black hole for a week. We thought the project lead was just ignoring us and nobody was working. It turned out he was out sick. And of course we still had no explanation why no one else on the team seemed to be working.


thanks,

Barry

[Jared Richardson]

We don't specifically address offshore, but we do talk a great deal about communication. There are a few tools that are just as useful to use locally as they are overseas.

One is using a Continuous Integration system and enabling Code Change Notification. This sends you mail every time code is checked in as well as archiving the event on a web page. This is a great activity meter (in addition to all the other great benefits of Continuous Integration).

Using a blog/plog (as mentioned above) may have helped as well. I have daily meetings with a team but still have them update their plog weekly. It's as much an organizational tool for team members as it for me (the manager) to keep aware of work progress.

It sounds like your primary problem was a lack of regular communication with the tech lead ~and~ the team, so when the tech lead dropped off the map, there was no fall back.

I'd strongly suggest you pick a "second in command" to back up the tech lead. Think about this concept... you were completely in the dark when the team lead got sick. What happens to your project if he quits? Your project sounds like it's tanked.

As Ernest Friedman-Hill reminded me yesterday, our book talks about your Bus Number on page 115. Read about Bus Numbers at the C2 wiki.

[Tony William]

Any major problem about offshore development is the techincal skill transfer.... regular communication / team meeting may help to keep everyone updated on the project status.

But what should one do if the offshore developers are all of less experience (or in worst case, is totally new) to the system?

[Jared Richardson]

Originally posted by Tony William:
Any major problem about offshore development is the techincal skill transfer.... regular communication / team meeting may help to keep everyone updated on the project status.

But what should one do if the offshore developers are all of less experience (or in worst case, is totally new) to the system?

I recently heard Dave Thomas speak on open source eco-systems (catch the talk if he's in your area!). He mentioned to things that I think apply.

First, in working with the Ruby developers (mostly Japanese), they couldn't "talk" directly, so instead they swapped tests. If Dave breaks something, he'll get a Ruby test from a Japanese developer that "explains" what he did wrong. When the test passes, everything is fixed.

Secondly, he talked about tiers of developers on a project. On most open source projects you have a maintainer (or owner), a few committers, more that contribute code, and tons of users. In your case, you could keep the committer rights here and have the remote developers submit patches. But I've never tried this in this type of situation.

You should also use Code chnage Notifications so you can watch their work and catch problems. You need a Mock Client Test suite to ensure basic customer scenarios don't break.