Home > criticism, waterfall > Agile Outsourcing: Get It or Forget It?

Agile Outsourcing: Get It or Forget It?

Bringing together agile philosophy and software development outsourcing has been one of the hottest topics over the last decade.  Lots of blog posts, discussions in social networks — people try to figure out for themselves if it’s at all possible to align agile methodology with the existing reality of outsourced projects.

How can vendors who practice agile gain new customers? How can customers as newly-converted adepts paste their vision of agile thinking on their existing outsourcing partners?

First of all, let’s look back into when and why actually did it all start with IT outsourcing. Manufacturing outsourcing existed since long ago, but IT offshoring only started at the end of 80’s - beginning of 90’s. Companies jumped at the opportunity to save bucks and use cheap labor not only for producing goods, but for producing software. So, the main point is that from the very beginning outsourcing has all been about saving money. No other notable motivation - just saving money and using cheaper labor.

homework

Next, along comes agile manifesto. People start seeing that the waterfall approach  they’ve been using with their outsourcing vendors is not that good after all.  Fixed price contracts do not guarantee real value (Scott Ambler writes very well on that in this article). Next, the more labor is outsourced to some country, the higher are the costs, so the main point for outsourcing which is cost savings makes no sense any more.

There’re other even deeper-lying consequences. On the one hand, the country which outsources - or businesses in this country not the country itself - they save bucks but lose in the long run as they do not grow their own engineering minds, let alone all the problems that you have working with remote teams - yes, we have all this telecom in place, but nothing ever will replace face-to-face communication. If you often go on business trips to the outsourced destination to talk to your team - again, it’s more costs.  On the other hand, outsourcing makes a dangerous long-term impact on the recipient economies as well.

But the point is not about how bad or good outsourcing is.  Vendors have written an array of blog posts on how to align agile and outsourcing - and that’s natural - they want to keep going, so they do everything to back up their point of view proving that agile goes well with outsourcing. This might work true in some cases.

The companies that outsource on the other hand - they have legacy outsourcing teams. They need to get going with them as well, to stand up to all the funds already invested in their outsourcing center/provider.

So with all this outsourcing in our hands - what do we do?

As an agile outsourcing vendor, you should be ready to invest lots of time and effort to educating your new customers on the value of agile and to building a solid relationship. This might be a very difficult task since some people just don’t want to get educated and prefer to stick to good old fixed price bids, logging and billing for gazillion of change requests, lack of communication and other “joys” of classical outsourced development.

As a company with established outsourcing facility, you’re better off. But perhaps you could be even better off if you started this relationship not with an overseas company, but with a guy next door at least.

Anyway,  you are where you are - so you would need to work with your outsourcing partner to practice the agile approach, since at the end of it all work with agile methodology brings real value, as opposed to counting short-term waterfall pennies and losing long-term gain.

  • i have read your article Really Nice one.because Now a days not only big companies like Adobe, Microsoft are doing software and product development in India at their development center. But now many other small to medium scale
    companies have started software and product development and started entering into outsourcing software product development. It is considered that, increase in business will be around 100% in offshore outsourcing product
    development.
  • The whole reason people outsource work is to save money, not to obtain anything of a high quality. The methodology an outsourcing vendor uses isn't going to change the fact that quality has nothing to do with the whole outsourcing paradigm. I've seen more insourcing projects than outsourcing projects lately, and some of the vendor code I've had to untangle was just so utterly horrible that I had nightmares about it. Most companies that outsource just want to throw requirements over a brick wall and hope the software that gets thrown back works. I've seen what usually gets thrown back, and I could probably make a horror movie about it. ;)
  • Outsourcing - forget about it. Nowadays, it's more about feedback and inside communication. I mean that to build software now is more about integration of existing components. It's like Lego and the cost is far less then it was 10 years ago. The feedback, communication, and self-dedication are significant. Moving this to outsourcing is pain.
  • agiledevelopment
    wht we dnt outsources our work to india.
  • agiledevelopment
    why we dnt outsources our work to india?
  • markpascall
    Interesting post. You may be interested in an article I wrote for Computerworld last year http://blog.3months.com/2008/04/20/outsoucing-a...
  • I think agile is possible in outsourcing dev. model, however it is much more complex. Communication is a key, and you should be very creative to break the ice and open rich communication flows.

    I (personally) don't like outsourcing in its pure form. However world is global now, and if you found a very good designer overseas, why miss the opportunity to try?
  • That's a good point. If you find a designer that doesn't happen to be local but is the best person for the job (and may even cost more than local talent), that's a very good motivation for outsourcing. But would the designer consider themselves an outsourcer (or vendor) or would they consider themselves a service provider? If I take my clothes to the dry cleaner, I wouldn't really say that I'm outsourcing the cleaning of my clothes, I'd just say that I'm paying for a service.
  • To me there is no difference. Outsourcing IS a Service. Just one more buzzword.
  • Very interesting perspective. While I am getting ready to set up Agile processes with offshore, I feel that there are few areas that become top priority to work on to make the agile outsourcing work (like communication). Just added couple of good links on my twitter @implementscrum from Martin Fowler and Matt Simons on Agile with offshore development
  • Also, today I've come across a very interesting blog post: http://andrewtokeley.net/archive/2010/01/25/it-... Quote: "Interestingly a lot of what has been written about agile software processes originated from product companies where the freedom to redefine and delay scope are critical. Success with agile practices in service companies is limited." So this issue is not only about outsourcing, but if it's an IT services company or a product company.
  • There also could be opposite situations when outsourcing service provider is trying to practice agile while outsourcer doesn't. I would say that problem isn't in outsourcing per se but rather in two different organizations working toward common goal using different approaches.
  • Sameh
    My experience in off-shore development is that the vendor is generally ready to bend its own internal best practices to fit those of the customer. After all, agile and scrum practices are flexible and scalable.
  • That's exactly what I'm saying - lots of dedication and patience needs to be in place to make agile work in outsourcing.
  • Sameh
    Outsourcing model is similar to the distributed set-up for software development. Apart from out sourcing where, there are successful stories about distributed Scrum development. Read Distributed Team chapter in Succeeding with Agile authored by Mike Cohn. Also, Jeff Sutherland has published many success stories on distributed teams.
blog comments powered by Disqus