· agile offshoring

Onshore or Offshore - The concepts are the same?

I’ve never worked on a distributed or offshore project before, but intrigued having read about Jay Fields' experiences I attended the 'OffShoring: The Current State of Play' Quarterly Technology Briefing held this morning in Sydney to hear the other side of the argument.

The underlying message for me was that a lot of the concepts we apply for onshore projects are equally important for offshore projects.

Forrester’s Tim Sheedy started off by providing some research data on the state of IT offshoring, some reasons he had identified around which type of work should be offshored before closing on some reasons that it might fail if not done correctly.

My colleague Dharmarajan Sitaraman followed, speaking about ThoughtWorks' experience in offshoring, again covering some of the things that can go wrong, the use of agile in offshore development and finally gave some recommendations on making it work.

What I learnt

  • Tim spoke about a tool Forrester have designed for working out whether your application should be offshored. I’m not sure exactly what the conclusion around this was but ThoughtWorks aim to do work traditionally considered 'not safe' for offshore development - i.e. enterprise business application development/product development.

  • The same problems such as communication with the business, inability to deliver business requirements, not adaptive to change were listed as reasons that offshore development can fail. From my experience these are the same reasons that we can fail on any project especially if we take an approach that doesn’t encourage quick feedback loops.

  • The advice given with regards to selecting an offshore vendor was to select them based on what they are good at. This seemed to be fairly sensible advice for selecting any partner. The benefit of taking an agile approach is clearly reduced if access to the business or final users is not possible for example.

  • Software as a service was a message both speakers considered. It was suggested that Australians don’t like to take risks with IT and therefore prefer a partner led approach. For me the first thing that came to mind when I heard this idea was that if software is a service then it should cover the whole life cycle of an application rather than just the development. I think the intention was more that IT should be considered as being more important to organisations than it currently is.

  • One of the questions from the audience was around how to price these engagements. A risk/reward model was suggested as being a good approach - the idea being to incentivise the partner to help the business to achieve its' outcomes. The underlying message seemed to be that trust is necessary to achieve a successful outcome. It was also mentioned that this pricing model generally works better for longer (18-24 month) projects.

  • The idea that you get what you pay for was also brought up with regards to pricing. Although cost is clearly an important driver when deciding to offshore work it shouldn’t be taken to the absolute extreme.

  • Tim also spoke briefly about some of his ideas around the 21st century IT shop where he summed up the difference between the agile and waterfall approaches to software development as follows:

    Waterfall gives you what you ask for...agile gives you what you want

    </ul>

    == Overall

    It was certainly interesting to see the view of software development from a different perspective and to see the data about how other organisations consider their relationship with IT vendors. It would have been interesting to hear more about the distributed agile approach to development that Jay spoke about and whether/how this differs from complete offshoring but that wasn’t the focus of this talk.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket