Agile India (Offshore Development)

I was doing a bit of research on Google searches and I noticed that a large volume of searches for agile development are coming specifically from Bangalore in India.

And this got me thinking about agile development offshore.

Of course I realise that India has a large number of software developers, as a result of the trend for offshore development in the last 10 years or so.

But in my agile travels, I’ve come across very little research, success stories or case studies about agile development in India, and particularly in an offshore development model where the development team is in India and the client is not.

I can see clearly how an offshore development team in India might operate internally using agile principles and practices. But I’m very unsure about how it would work effectively in terms of (a) active user involvement in the development process, (b) defining lightweight requirements piecemeal throughout development, (c) integrated testing, etc.

Perhaps the challenges are no different than for a distributed team? But when I think of the added complexity of a distributed team, the added complexity of client/supplier relations, the added complexity of distance (preventing regular face-to-face communication), and timezones inhibiting other forms of communication, I worry.

Add all that to the usual complexity of software and humans, and I wonder how high the barriers to success really are with this model.

Martin Fowler from ThoughtWorks has written an interesting article about ‘Using An Agile Software Process With Offshore Development‘.

If anyone has experience of agile offshore, positive or negative, in India or elsewhere – or if anyone has any interesting reference materials about the subject, it would be great if they could share via the comments on this blog post…


13 Responses to “Agile India (Offshore Development)”

  1. jc-Qualitystreet says:

    Stephanie Moore and Liz Barnett (in a Forrester research, 2004) see the combination Agile – Offshore as a major competitive advantage for organizations. Of course have to be done…
    The link:,7211,34978,00.html

    Major agile principles and techniques: short iterations, timeboxing, incremental development and frequent delivery, focus on tests, automatization, team collaboration … have already proved their efficiency in nearshore/offshore contexts.

  2. Paul says:

    I work for an agile custom software company ( in Poland that has clients in Western Europe, America, and Asia. I believe that, unless the project is very small and discrete, an agile approach is the only responsible way to build web applications, even if you are working in non-co-located teams.

    Given that a major component of “quality” is “it does what the user needs”, and given that product owners never know what the user needs at the start of a project (I have yet to build a product to the initial specifications.), it follows that an agile approach using short iterations, high customer engagement, and both project management and development practices that thrive on change is essential to reduce waste and to hit the mark the first time out.

    Practically, this means that we hold scrums in a room with a video conference phone or over Skype with a video so that remote product owners can participate. The programmers and testers have the product owner’s Skype address and phone number and vice-versa, so that story clarification and implementation feedback conversations can happen throughout the day.

    It works tremendously well. West coast (America) clients have to be early risers to work with us, but Europeans and Americans on the East coast consistently have a great experience using our company for agile software development.

  3. Sidu says:

    I’ve been doing offshore/distributed agile at ThoughtWorks for a couple of years now. You’re right in saying that it isn’t as easy to run a distributed agile project as it is a co-located one, but it isn’t that hard either. It takes some common sense with regard to managing communications, top notch business analysts who are permanent members of the team, high technical capability on the parts of everyone on the team (not just the tech lead or architect) and a great deal of discipline – >90% code coverage, a full suite of functional tests for each story, continuous intergration, every green build should be deployment ready etc.
    The full answers to your questions are worthy of a blog post themselves, but I’d be happy to answer any specific questions you may have.

  4. Joel says:

    I had to laugh. If I’m checking to see if my development meets 42 requirements – I’d suggest working to meet this list will quickly remove all sense of agility that founded the concept in the first place.

    Work fast.
    Produce results.
    Learn from your results.

    How’s that for a list? ;-)

  5. Paul says:


    I believe there’s a happy medium between these lists. Not all 42 points are consistent with all accepted agile models. In fact, forcing all 42 points on a team whether they see the value or not is very UNagile. Your list, however, fails to capture the discipline that is required to produce quality while working fast. Using your list, a team would probably evolve a useful agile methodology within a year or two, but why not start from the foundation laid by those who have gone before?

    Paul Klipp, president
    Lunar Logic Polska

  6. Martin Crisp (CTO, Blueprint) says:

    We use distribute Agile teams hear at Blueprint ( As you would expect having a distributed Agile team dramatically reduces the level of active communications, but we have still managed to be successful at delivering working software at then end of each 2 week sprint. We conduct our daily scrum meetings over the phone with the offshore teams. In addition we use our own product “Requiements Center” to provide “just enough” requirements detail in an iterative manner.

    Martin Crisp
    CTO, Blueprint

  7. Ralph says:

    We are starting with distributed team this moment. We have four development teams and will split the first team in two teams. We complement the team with Indian developers and testers.

    At this moment our new Indian colleagues are in the Netherlands to get familiar with our process and what’s most important to form a real strong team with their Dutch colleagues.

    They will work two months in the Netherlands as a collocated team and then go back to India.

    As they start working there, it should be no difference if they work in India or in the Netherlands.

    We know there will be problems, communicating, infrastructure etc. all kind of problems we can’t think up right now. We try to minimize the problems of course and assist the team as good as we can.

    The process itself and the team will improve their selves during the retrospectives.

    We are aware that the velocity of a distributed team is lower than a collocated team but two teams together will in the produce more then one collocated team.

    If you have any questions or want to exchange ideas, just send me an email.

  8. M. Ali Nasim says:

    We at Ephlux have been doing product development very successfully on agile methodologies with our partners and customers in LA, California for the last 2 years.

    We’ve knocked out multiple successful revisions of 3 medium to large scale products during the course which are successfully live at many end-customer accounts and effectively being supported by onshore/offshore teams.

    Our offshore teams work with our customers and their teams as one cohesive team and with telecom now so cost-effective (although not face-to-face) we meet with the customers both formally and informally every day.

    We maintain a strong level of trust and respect on either sides and reap the benefits at both ends.

    You can know more about Ephlux at and can contact me for specific case-studies.

  9. fdm says:

    More and more companies begin to mix agility and offshore with good results.

    An other interresting article of Matt Simons, still from Thoughtworks, talk about that subject.

    Even in China, agility begins to be popular. Recently InfoQ had posted an interresting article about SCRUM in china.

    I also started a blog about agility and offshoring. (, in french, so i dont think you’ll be interrested on it)

  10. Anonymous says:

    We find that a combination of agile techniques work well, especially in distributed agie. You might want to take some of the best from XP, LSD and SCRUM – definitely works for us!

  11. says:

    We ( have been practicing offshore Agile software development for last four years with great results. Our clients are in US and our dev team is in Pune, India.

    We find that Agile process works very well in this situation – the short delivery cycles (2 week iterations) makes the US clients quickly comfortable with offshore team and the frequent client feedback makes the offshore dev team comfortable and confident quickly. The overall result is great team-work. Of course, we have to attend to some of the basic discussed in this thread.

  12. offshore says:

    Thanks so much for this post.

  13. Agile Software Development says:

    Agile has emerged as one of the most soothing and result-oriented techniques to create customer-friendly techniques.

Leave a Reply

What is 7 + 10 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)