Rolling back offshoring

For some companies, offshore development, particularly in India, is losing the financial advantages it once had. Software developer wages in India are overall about 30% of what they are in the US, but top performers are able to demand 50% to 75% of US salaries, with 15-30% annual increases, according to this story.

"If you're a startup and you're doing a lot of iterative design and you constantly need a higher level of agility, you might find [offshoring] more burdensome than the cost differential is worth," said Fran Karamouzis, a research vice president at Gartner who specializes in outsourcing issue.

On the other hand, "If you can give the Indian team things that are clearly delineated that they can own and drive on their own, then it works out pretty well," said Pejman Roshan, cofounder and senior director of marketing at Agito Networks, a wireless technology startup in Sunnyvale, Calif. that outsources software coding to a services firm in Bangalore.

In addition to the communication challenges introduced by different cultures and a 12-hour timezone difference, multiple power outages every day eat into efficiency of Indian teams.

An offshore agile success story

In a previous post, I briefly mentioned the success my team had applying an agile approach on an offshore project. Here is some more about what we did that worked well for us.

In agile methodologies, a co-located team is critical to success - a prerequisite, some would argue. But what if you're stuck with a geopgraphically distributed team? Even worse, what if part of the team is offshore, 15 time zones away, it's members a part of a very different culture, and their English comprehension is limited? Is it possible to be agile in this situation? If so, how?

This is the situation I faced on my recent project. The onshore (US) team was colocated with the customer, and consisted of a project manager, a business analyst, and 2 architects/senior developers. The offshore contingent was located in Hangzhou, China and was a team of 8-10 developers and testers.

The project: build a leading-edge video streaming application using linux, MySQL, Java, javascript, and a few other technologies (Perl, PHP) thrown in for good measure.

The result: we delivered a high-quality application on time, to rave reviews from end users.

How did we make offshore agile work? To some extent, by being less agile, and less offshore. Here is how we organized the project for success.

• Bring your offshore team onshore and have a single colocated team - at the customer site - as early as possible, and for as long as you can. We had our entire China contingent onsite for 3-4 months at the beginning of the project.

Note: obtaining visas can be tricky. We used B-1 visas, although we were pushing the limit on what can be done with B-1's. H-1B and L-1 visas are possbile in some cases. J-1 visas are another option, and there may be organizations that can help you arrange these. BoldTech worked with CAST, the Chinese Association for Science and Technology USA, to obtain L-1 visas for some people.

• Share the vision. The entire team should know and be continually reminded of the vision and road map for the project. What is the end goal? Who are the end users? What are the key features in the next release?

• The offshore team participates in - and drives - demonstrations to the customer. Delivering potentially shippable software each iteration has a very tangible meaning to developers if they know they will be personally demonstrating it to the customer. We got lax on this and stopped doing it after the team went back to China - looking back I kick myself for not making it continue.
  

• Send US team members to your offshore location. Do this as often and for as long as you can. When the developers returned to China, I spent 4 months in China as the team lead, and brought my family with me. It's hard to find people willing to take that assignment, but you can send various US folks on a rotating basis for shorter visits if that's the best you can do.

• Sufficient analysis and documentation. Once the offshore team was offshore again, scribbling a few notes on a note card wasn't sufficient to communicate requirements. The developers comprehension of spoken English was limited, so thorough requirements documentation became very important. And unless you like to answer the phone at 3 am to answer questions from China, I recommend that you have good-enough documentation. We combined screen mock-ups, narrative text, and use cases, as appropriate for each feature / user story.

• Online collaboration tools. We used XPlanner, Mantis, and Mediawiki. For meetings and communcation, we liberally applied phone calls, web conferences, IM, and email.

• Shift work schedules so working hours between locations overlap

• Adjust your communication style. Listen closely to a conversation between two native English speakers, and you'll quickly learn that a huge proportion of what we say is idioms, expressions, and sayings. "Are we on the same page?" "Don't go down that rat hole." When you're talking to folks from China, you can't talk that way. Slow down, use common, simple words, and avoid the idioms.

New gig at IP Commerce

I accepted a job offer today to be Director of Integration Delivery at IP Commerce, a company based in Denver. The company is building a software platform to enable and simplify electronic payments over the internet. So what will I be doing? Building and managing teams of developers that will build software to connect the system to various banks and payment service providers. I'm excited about the opportunity, and I'll be among friends - I've worked with many people there in the past.

I've enjoyed my 2nd tour of duty with BoldTech, and the unique opportunity I had to work in China and build a cool video web site at the same time while using agile techniques. This new position should be a great opportunity for me, though, and I look forward to it.

It's a bit premature for me to say how agile methodologies will figure into the work, but I will write more about it later.

A successful agile offshore project

Since July, I've been working for BoldTech Systems as a consultant to Envysion, a start-up company in Boulder that provides web-based video management solutions. This is the project that brought me to China to lead a great team of developers in building Envysion's new web-based video application. We officially released the web site to the public this week, although several customers had been using it prior to then in a beta version.

I lead the team using agile principles and practices, and the result is a happy customer and very enthusiastic end-users.

Is "agile offshore" an oxymoron? To the hard-core agile fundamentalist, maybe so. With a distributed team and a remote customer, you need to try harder to be agile, and compensate for the obvious drawbacks of the situation as best you can. This project shows that a practical approach based on agile principles can yield fantastic results.

Check out the site here! Note - you will need to use IE on Windows XP. We'll be adding support for other browsers and platforms in the future.

Grass-roots Agility

This Monday, Feb. 26, I attended the Agile Denver meeting for a presentation by Greg "Hap" Pearman entitled Being Agile in a Non-Agile Space.

The gist of the talk was, how can one be agile if the company you're working with isn't embracing agile methodologies? Greg advocates a grass-roots effort.

Here are Greg's suggestions.

1. Have courage
- many agile initiatives are grass-roots
- to know when it's best to quit or start over
- don't be afraid to fail

2. you need to really know your stuff to push agile
- how and why agile works
- sharpen the saw

3. Set expectations
- communicate often and early

4. Lead by example
Build trust

5. Start by fixing the biggest pain points of the process
- don't start with the easy/small stuff!
- biggest ROI

6. Understand dependencies between agile practices.
- If you don't do one practice, how will you compensate?

Based on his experience at US West / Qwest, Greg has the following advice if you will attempt to transition a large organization to agile methodologies:
- go fully agile from the start, and give team lots of support to succeed
- agile practices are interdependent