Ajax, Agile and Offshoring

Dietrich Kappe, Wednesday, October 4, 2006 @ 8:00 am

Into each life a little offshoring must fall... First came the opportunists who thought that lower wages would inevitably lead to lower costs. They soon found out that if their software development practices weren't already stellar, their costs went up. For those that did everything right, one might see a cost savings of up to 30%. Lately, I've seen a different trend in offshoring. I see companies retaining offshore teams not because they are cheaper, but rather because they are available and available quickly. Putting together a first rate software development team in the United States made up of employees and contractors can be very time consuming and require the full-time effort of several in-house technical recruiters. Who wants to wait six months for a technical team to fill out?

Lately I've beeb asked by clients and prospective clients who are having a hard time filling their Ajax job postings whether they should go offshore for Ajax talent. I tell them that they are likely to be disappointed because the effects of supply and demand are accentuated in the offshoring market. In other words, the tasks that got offshored fell into two categories: those that were expensive (like J2EE development), those that were easy to offshore (like QA testing), or both. User interface design before the advent of Ajax has historically been difficult to offshore and comparatively inexpensive to perform; and JavaScript development, which is at the heart of Ajax development, has usually fallen in this domain. Therefore you are unlikely to find a glut of highly skilled Javascript programmers in the offshore market.

Since I'm already dispensing advice about offshoring, and since this blog isn't simply called "Ajax" but "Agile Ajax," I thought I'd dispense some more advice about how agile practices and some common sense can help with offshoring.

1. Give yourself a chance to succeed. Pick a company that has a proven track record when it comes to agile development. Check references, demand to see deliverables.
2. Pick a company for whom you represent a substantial part of their business. Pick a company that's too large, and your project may be frequently inconvenienced in favor of those of larger clients. Pick a company that's too small, and you assume a greater risk when it comes to that company's viability. The right number for you depends on how responsive you want your offshoring partner to be and how much risk you are willing to take on.
3. Don't pick a company in the white-hot geographic center of the offshoring boom. Think Silicon Valley during the dotcom craze. You don't want your offshore developers walking to the next storefront for a better paycheck. In India, for example, avoid Bangalore in favor of cities like Nagpur. If the local universities have good computer science departments, the local offshoring companies will have good talent.
4. Find an offshoring partner that is willing to work during your workday. Moving to a two shift or round-the-clock development schedule may seem like a good idea, but unless you've pulled it off onshore, you've got no business trying it now. The one thing you can try on a different schedule is testing. Handle with care.
5. Have someone on your team who understands the language and culture of your offshoring partner. If you offshore to the Philippines, make sure you have a Filipino on your team. If you offshore to India, make sure you have an Indian on your team who is from the same part of India and speaks the same language as your offshore team.
6. Interview all the developers your offshoring partner proposes to put on your project. Don't lower your standards for technical or English-language competency just because the developer is an offshore resource.
7. Mirror major project roles in the onshore and offshore teams. That means that your project manager, technical lead, functional lead and testing lead should each have a counterpart in the offshore team. If your development method calls for more major roles, mirror those too.
8. Make sure you have seamless communication via VPN, voice and email. Communication is key with a distributed team.
9. Considering establishing a project Wiki.
10. Consider holding a daily scrum. Distributed teams can easily drift without constant attention to focus. It goes without saying that this is part of an iterative development method.
11. Establish a central source code repository, but allow onshore and offshore teams to have separate development and testing environments.
12. Use a modified form of pair programming to build team chemistry, improve communication, and guard against knowledge loss. In this modified form of pair programming, each onshore developer is paired off with two offshore developers. In practice, we've been able to quickly double the size of our team by breaking up these "pairs" and reassigning the experienced onshore developer to two new offshore developers, and vice versa. This may seem like a crazy idea, but I can't emphasize how productive and useful the practice really is.
13. Insist upon unit tests. Code is incomplete without the unit tests. Unit tests are a form of communication in that they impose a behavioral contract on an interface or class. The more you communicate in distributed teams, the greater your chances of success.
14. Use a continuous integration build server like CruiseControl with a code coverage tool to exercise the unit tests on a regular basis. Hourly builds are not at all unreasonable. Translation: communicate early and often.
15. Hold regular full development team code reviews. More communication.

I've focused mostly on places where agile practices can help, but certainly the subject of selecting an offshore vendor and managing an offshore project is huge and I can't pretend to have addressed all of them. (You can find more info on that here and here.) There's a lot more I could say on this topic, but then they would devolve into a general software development rant not particular to offshoring.

Technorati : agile, offshoring

agile ajax

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I like the way you state “the tasks that got offshored fell into two categories: those that were expensive (like J2EE development), those that were easy to offshore (like QA testing), or both.” … well “got offshored” is past tense.

   With the advent of better tools and technologies of communication, even that is changing. A highly simplistic way of looking at IT offshoring would be: If the requirements are defined, and it can be done by skilled developers, it probably can be done remotely…and offshore.

   This said, your arguments Offshoring Agile projects is not for everyone….

   Comment by Mohan, Wednesday, November 8, 2006 @ 2:25 pm

2. 

   Interesting post. One of the challenges is going to get business owners engaged in this process so that the core business logic that must be implemented is correct. I believe the use of a business rules technology to manage this kind of logic is potentially very effective. Business rules are not requirements (http://www.edmblog.com/weblog/2005/11/fix_the_require.html) and can be easily integrated with an agile approach (http://www.infoq.com/articles/Agile-Business-Rules-Taylor and http://www.edmblog.com/weblog/2006/02/agile_rules_a_c.html). Offshoring code development while keeping business rules management onshore (http://www.edmblog.com/weblog/2006/02/offshore_backsh.html) can also make for less risk and better development.

   Comment by James Taylor, Monday, November 20, 2006 @ 11:22 am

Leave a comment