1. An organization is already using Agile processes and now wants to leverage the cost/time efficiencies of an offshore team. Agile consultants and skilled staff are expensive (and often hard to find). Leveraging the huge pool of offshore talent - in India and throughout the world - should be possible.
   
   
2. An organization is using or has been told it must use offshore resources, yet it is frustrated by the waterfall-like hand-offs common to most offshore firms' processes. Offshore teams just aren't meeting users' needs. It takes too long to pull the requirements package together, send it to the offshore team and then get back a big chunk of capability that is either too late or does not deliver what is really necessary. Agile processes are known to address these issues for co-located teams; can Agile processes improve what is delivered by an offshore team?
   
   
3. An organization has no experience with offshore development or Agile processes and it has met a consulting firm who claims to do both successfully. For those looking to hire an outside firm, is this a silver bullet?

Of the three, the first scenario is the least difficult to achieve. (Note that I do not say the easiest.) I have found that organizations starting with an experienced Agile team can successfully move parts of the project to an offshore environment. Not easy, but possible. Typically, this starts by bringing some offshore team members to the onshore team to work in a co-located manner and build that all-important face-to-face relationship and trust. In addition, these organizations will frequently send onshore staff to work with the offshore team for short periods of time. Technology plays an important role here, particularly IM, email, collaboration tools and software {sidebar id=1}  configuration and build management.

The second scenario, introducing Agile processes to an existing onshore/offshore project team, is far more challenging. In this case, team(s) are already at work using existing processes and so both the on-shore and offshore staff will need training and mentoring. For these types of projects, I have seen the greatest success on those teams that first turn to Scrum to help manage the process. By adopting Scrum practices, the team can improve its daily communication skills, become more responsive to customer requests and commit to short iterations -  and it can still use legacy waterfall development processes. For example, I have seen a number of Scrum teams using offshore resources continue to use short waterfall cycles to build and test their code. Is this Agile? I would argue yes. It seems to be far easier for these teams to start by changing their team management styles first, and then change (as appropriate) their development practices. For development, the "test first" approach is typically the first step, as it can be managed and controlled locally as the staff build their skills.

In the third scenario, where an organization has neither Agile nor offshore expertise, you will need to find a strong partner to guide you through all of this. For now, this scenario is driven by the consultants rather than the customers - a mix of Agile and offshore techniques can make consultants' bids more competitive. I do not see a lot of companies seeking an Agile offshore strategy as their starting point; this is due to the dearth of resources in the industry and to the perceived risks of both offshore and Agile projects. Several US and European consultancies have built successful offshore Agile practices, including Valtech, ThoughtWorks, CEI and Sapient. As an example, Valtech has its own trained staff in India fully engaged in the same Agile processes as its onshore (US and European) consultants. So the customer staff require the education but the offshore consultants have already mastered the offshore Agile approach. I have not yet found an Indian company using offshore Agile processes as its core approach to software development.

The most interesting observation I have, though, is the changing attitudes of the Indian firms. Two years ago, I interviewed most of the leading Indian consulting firms including Wipro, TCS, Cognizant and Covansys. At that time, none of them felt the need to commit to Agile processes; most said that Agile processes didn't fit with their business models. One large firm just called Agile development a fad that wouldn't last. Last year, a few customer stories dribbled out but I still did not see the Indian firms looking to engage in the Agile community. Now, I see the complete opposite: many Indian firms are training their staff in Agile processes and are finding ways to incorporate at least some Agile techniques into their proprietary methodologies. This began as more of a reaction to customer demand than as the firms' proactive actions. Organizations are unhappy that their offshore projects are not delivering what the customers really want, and they are pushing their offshore partners to adopt more incremental and customer-facing processes. The AgileIndia 2006 conference scheduled for early May in Bangalore  (http://agileindia.org/agileindia2006) includes sessions on both the technical and cultural challenges of Agile development.

Recently, one Indian firm told me that it sees Agile processes having a huge impact on its ability to bid competitively. That alone will be the key driver: as pressures from China, Eastern Europe and elsewhere in the world put pressure on offshore pricing models, only those that can deliver high quality and timely solutions will survive.

I expect that 2006 will bring more offshore Agile successes to the forefront. Certainly, our readership is investing in Agile processes; in our recent survey, only 12 percent of respondents stated that they did not see a fit for Agile processes in their organizations. The confluence of pressures to reduce costs and quickly deliver high quality solutions is forcing development organizations to change the way they work. Using Agile processes on offshore projects may just be the solution they are looking for - as long as they are prepared to undertake the cultural and not just the technical change.

Comments (0)

Write comment

Show/hide comment form