CIO magazine posted an article this week entitled «7 Tips to Offshore Agile Development», and they got it mostly right, but I would like to add 4 more tips that I think are critical to effective agile outsourcing.
Stephanie Overby wrote these 7 tips:

1. Be prepared (with standard tools and communication rules)
2. Start small (use small teams and trial teams)
3. Consider a hybrid model (of onshore and offshore team members)
4. Manage Actively (you need to be involved)
5. Invest in onsite training (ie, bring them to you to learn your business)
6. Pick the right partner
7. Account for time zones (when choosing the time for daily standups)

Those are all good tips, and in our experience at AgilityFeat I agree with them all.  Our development and design teams are primarily in Costa Rica, and our customers are primarily in the US.  We are particularly proud of our application of agile methods like scrum and kanban to our distributed development, and in fact our entire business model is based on applying agile methods to distributed development.

Based on our experiences, I believe that these additional 4 tips are critical to using agile effectively on distributed teams:

1. Initial co-location

We encourage all of our customers to come visit us in Costa Rica and work with us for the first week or two of a project.  This initial co-location is critical to building a good working relationship as quickly as possible, and a common understanding of what our customers need and how they will judge success.

You can develop that same level of understanding without co-location, but it takes more time and will likely only happen after some mistakes are made.  You can mitigate that by meeting with the team in person initially, either in Costa Rica or in the US.  Flights to Costa Rica are easily found for under $1000 US and so it is well worth the investment to get your project off to a great start.

2. A great Product Owner is critical

As Stephanie writes, you need to actively manage any outsourced project.  That is the great failure with traditionally outsourced projects.  Writing requirements and «throwing them over the wall», or over time zones, simply doesn’t work.  I have seen that method fail time and time again.

In Scrum, the job of the Product Owner is crucial.  They must understand what the end users need the software to do, and they must become the voice of that customer to the team.  Most importantly, the Product Owner must have enough decision making authority to manage the priorities.  The team will need the Product Owner to make final decisions about what feature is most important to work on next.

Our most effective projects have been the ones where we had a good Product Owner from the customer, who devoted 5-10 hours per week to our project.  A good Product Owner will meet with the team daily on skype and for weekly planning and demo meetings, and they actively participate in the design and testing of the product.

We can mitigate some of the risk of uninvolved product owners through our excellent UX and design leads, who can also help represent the views of your users after we get to know your product and company well.  But you can’t expect us to fill those role entirely and still deliver the product you want.

The most challenging projects we have run have undeniably been those where the customer did not provide as engaged a Product Owner as we asked them to.  Don’t shortchange this role!

3. Nearshore, don’t Offshore

The CIO article refers to offshoring, which could be any form of outsourcing, in any time zone around the world.  In our experience, this is not reliable.

You should be nearshoring instead, which means stay closer to your own time zone.  If you are in North America, then you should be looking to Central and South America for your outsourcing needs.  If you are in Europe, you should be looking at Eastern Europe or Africa for your outsourcing.  And so on.

I’ve seen teams do agile when they are 12 timezones apart, but it is hard to make it work reliably.  Somebody has to stay late or get up early for daily standups, and those teams have always resisted having joint planning sessions and demos.  And they almost certainly don’t hold retrospectives.  Inevitably, the teams become more plan oriented and they have to add in extra bureaucracy and documentation to account for the reduced communication of teams.  And they very rarely, if ever, visit each other in person.  In short, these teams lose out on a lot of the benefits of agile and never achieve the optimum level of productivity.

4. Look for truly Agile partners

Agile is trendy, and so everybody wants to claim that they are agile even before they understand what it means.  As an agile trainer and consultant, I have gone into many companies telling their customers they are agile and had to bite my tongue.  The same is true in outsourcing.

Don’t just accept it on face value that a nearshoring partner is agile.  You need to dig deeper.  What is the company leadership like?  Which specific agile practices do they follow?  Are they thought-leaders in their region? Do they hold retrospectives after every sprint?  Asking about retrospectives is a pretty good measuring stick, because this is the thing most people leave out first.  Ask them to talk about changes they made in a project based on action items from a team retrospective.

At AgilityFeat, we are definitely agile.  Our founders, Arin Sime and David Alfaro, are both agile coaches and trainers.  Arin is in the US and David is in Costa Rica, and so together we ensure that our teams are following best practices.  We are so agile, we even built an online tool for distributed team retrospectives with Lithespeed (the tool is called Sensei and is currently in beta).

By following these additional 4 tips, our experience tells us that you will have a much better chance of making your agile nearshore project a great success.