Some of the pure “Agileistas” will may answer this question in a manner that isn’t very possible for some of us in the real world, with “Don’t do it” or, “Reorg your company.”

I don’t’ know what those people expect here- is it possible that you can convince your management organization to tear down its office walls, move entire teams from across the country into one office space, just because you heard it at a conference that it was going to be really hard to do Agile remotely?

I certainly don’t believe that doing Agile with remote teams is a bad practice, nor do I believe that it’s impossible. Challenging? Yes it is. Easy to mess up? You bet. But there are some simple things you can do to avoid some of the pitfalls of remote organizations.

Agile with Remote Teams

Use face to face communication methods:

I just got the iPhone 4. It has face to face video chat. I also use Google Talk, and this also has video chat built in. It works great! With all the communication technologies we have now a days, there is no reason to avoid personal contact with remote teams.

If the remote team is a faceless organization, it will become a perceived impediment for the local team if there are problems. They wont’ be treated like part of the team, but more like an outside entity that drops code in and risks messing up the release.  We can bring these teams closer together to encourage communication, and allow them to adapt and respond to each other as issues arrive. Creating a persona and human link turns those faceless “code drops” into real people, people who you can reach out to. This gives the team the power to self manage your priorities, impediments and conflicts.

Create Agile ambassadors

We can even take face-to-face chat on the internet up a level. Sending ambassadors back and forth from the remote teams to home base and vice versa creates a human link that is deeper than any piece of technology can provide.  The ambassador’s job is to strengthen this link, because if the link is strong, each side will be more inclined to help each other.

Sometimes having a planning session with the remote team doesn’t give them the overall sense of how important the stories you’re working on might be. They may not feel as if it’s important, and that’s because they don’t know all the juicy details that led up to the creation of that story. Having an ambassador at that site gives that team visibility into all of the bits of information that make one user story important. In other words, the ambassador gives the entire back-story to an iteration (IE the gossip) so they can get a sense of how important something is, it’s not just a priority number in the ITS.

Use Tools That Work Globally

With all of the face-time, ambassadors, and communication, it’s essential that teams have a global view of what’s happening during the development cycle. It wouldn’t make much sense to reach out and then not provide a way to extend that communication on the development level.

Imagine a team where having access to a user story or a piece of code wasn’t easy and available to them? This handcuffs the team tremendously.

Any remote team will need to be able to:

• See each others user stories and tasks
• Enter updates to user stories and tasks
• Diff baselines and branches
• Check out code from remote teams
• Contribute to team discussions and wikis
• Run continuous integration globally

Use Multi Stage Continuous Integration

Using multistage continuous integration lets people take a look at what’s been built, and if it functions correctly, give it to the other team. Having multi-stage set up gives you a way to integrate early and often, but only deliver changes that are “done”.

One of the main problems with remote development is integration, and it’s a double edge sword for most SCM tools. If you isolate the remote team too much, they won’t integrate often. And when they do integrate to mainline, they may break functionality. The problem with this is that they will not be able to respond to that change for 6-12 hours if your team is in another country. This basically means downtime for everyone.

But with multistage CI and AccuRev you can keep that team isolated and integrated at the same time.

Is it possible to do offshore Agile?

I’m not sure if it’s a question if it’s possible, I don’t think we have a choice. Offshore development is a reality that isn’t going away, and the simple answer of bringing teams together to practice Agile isn’t always variable.  Doing Agile with remote teams isn’t’ a choice, it’s a reality.

Failure teaches a man many things: don’t mix beer and tequila, dates don’t want to hear about your ex, and good software isn’t developed offshore. But success can be a better teacher, and a little failure combined with some success is best of all. After fifteen years doing projects in India, England, Israel, Canada, Moscow and the Ukraine, I’ve got the scars to prove I’ve learned a few basic requirements.

Requirement Number 1:

Leadership is everything. In case you missed it, Leadership is EVERYTHING. And I don’t mean sitting on the phone in the corporate office. I mean the person who represents everything you want to achieve and sits in that remote office having to drill the corporate mission into people who have little respect for corporate, and strongly suspect that the feeling is mutual.

The Roman Empire lasted for a thousand years, which might be longer than your project is going to last. The job with the most difficult requirements in the Roman Empire, tougher than Senator, tougher than General, was Governor of a remote province. Romans knew that the Governor had the toughest job. He had to convert his provincials into people who wanted what Rome wanted, people who would profitably grow Rome’s Empire, not people who would revolt and suck up Roman resources.

There are few application development jobs tougher than managing a remote development group. And there are precious few people that can do it. It takes great leadership, as well as management ability, which is hard to find.

Next, in Part 2, if you can’t identify the fish at the table, the fish is you.

Lorne Cooper