Taking Agile Offshore

Companies today are attempting to lower costs and increase staffing flexibility by taking some, or even all, of their development activities overseas. Many of these same organizations have teams that are using agile development practices in an effort to increase quality and improve project performance. Some teams might find themselves in a situation where they didn't choose to take their teams offshore; but that decision was, in fact, made for them.

What happens when these two trends in our industry intersect?

There are tools and techniques that you can draw from agile that are essential for any kind of offshore endeavor. Development practices such as test driven development, continuous integration, and pair programming can be a powerful risk reduction mechanism to ensure the quality of your product and reduce uncertainty.

Defining requirements as user stories, building out thin slices of the product, and frequently reviewing those features with the customer can go a long way to making sure you are building the right product. Using these techniques help mitigate timeline risk because the product is always in a nearly releasable state. Daily stand-up meetings, sprint planning, and sprint closedown provide essential visibility into the development process and create an environment where you can inspect progress and adapt based on that feedback.

You never get too far off before you have the opportunity to adjust.

Teams working across dramatically different time zones, separated by thousands of miles, are going to need more documentation to stay in synch. There is not enough communication bandwidth to keep everyone busy and on the same page. Documentation needs to be viewed as a means of communication and not the deliverable. It is overhead. Keep doc as simple as possible to get the point across. Having a solid architectural description, very specific story descriptions, and clearly articulated acceptance criteria are key.

You'll need to adapt some of your agile leadership philosophies to accommodate the unique characteristics of your offshore team. You might have to take a more prescriptive approach as the team is coming up to speed. Not everyone may be culturally ready to accept the level of responsibility that agile requires. You may need to have a senior team member hand out stories, rather than having the team self select, to accommodate background and experience.

Be intentional about these deviations and have a coaching strategy for moving team members where you need them to be.

Taking an agile approach to offshore development is going to expose you to more junior staff than you might be used to working with. The market, especially in India, is very tight. As developers gain experience, many of the best people will move into management. You may experience 2-1, 3-1, or even 10-1 productivity differences between your more senior onshore guys and the offshore team.

These differences, coupled with increased documentation, increased communication delays, increased management and tracking burdens, and increased coaching overhead; create a much more complicated financial picture than just hourly rate. Using offshore talent will result in increased working hours and increased demand on the capability of the onshore developers. If cost savings are your primary driver for going offshore, you might want to look very closely at the numbers and measure if you are really getting the savings you expect.

The hourly rate is not all you need to take into consideration.

If you have had a different experience with agile in an offshore model, please feel free to comment, especially if you disagree with my conclusions. If you are a developer working for an 'offshore' outsourcing firm, please let us know if you think these experiences here are typical. Do you have any thoughts on how the typical offshore relationship will evolve, over time, as rates and technical experience go up? These are all interesting questions.

I will be sharing an experience report with the community at Agile 2008. If you feel strongly about these topics, please come find me. I would love to hear how using agile with an offshore team has worked for you.

Comments

[Raza Imam]

Mike,

In general your observations are correct. I own an offshore development firm based in Chicago and have found communication to be the biggest complaint from customers who have had a bad offshore experience before.
Companies that outsource merely to save money are usually disappointed.

The most successful engagements are when the local and offshore team adhere to a strict methodology and are equally committed to following it. Breakdowns don't usually happen at the code level (although we've heard spaghetti code horror stories) but rather at the communication level. Another benefit of knowing a good methodology is that it helps you know which projects are outsourceable and which ones aren't.

Thanks for the constructive post.

Best,

Raza Imam
http://SoftwareSweatshop.com