Is Offshoring a Special Case of Agile Scaling?


Nobody in their right mind will claim today that distributed agile is not possible. There are simply too many success stories available to disprove the feeling that “distributed agile does not work”. There is also enough evidence that “agile offshoring” works better than “waterfall offshoring”.

But, this was not the case ten years back.

It was a firm belief of the initial proponents of agile that to deliver good quality software that meets the user need you need to get a group of excellent developers and the key users into one room and let them iteratively build the software without outside interference.

There is no doubt that this is the most productive way of working but over the course of the years we have realized that in a real enterprise scenario such luxury may not be feasible.

Why did the Agilists believe that Agile & Offshoring cannot be mixed?

To better appreciate this we need to take a quick look at how the agile movement came into existence.

It was born out of frustration of trying to exhaustively document what the software should do, how it should do it and giving the document to somebody else to write the program. This method simply did not work.

Many people realized the problem and came up with similar solutions. Alistair Cockburn designed Crystal. Jeff Sutherland, Ken Schwaber with the help of Mike Beedle created SCRUM. Jim Highsmith formulated ASD. Jeff De Luca with the help of Peter Coad and Jon Kern proposed FDD. Kent Beck, Ward Cunningham, Ron Jeffries and Martin Fowler came up with XP. In Europe the DSDM Consortium built the DSDM methodology. Initially these methods were classified as lightweight methods.

Then in 2001 February, 17 proponents of the lightweight methods got together and created what we know today as the Agile Manifesto. People in the trenches liked the Manifesto and started adopting them.

Since the basic premise of Agile Manifesto is sound, agile success stories kept pouring in and the managers in the enterprise slowly started realizing that agile is not cowboy programming. People tried agile for different types of software projects and the success stories by far outnumbered the failures.

Meanwhile Offshoring kept growing and growing and growing

Remember the Y2K problem?

The IT industry needed to fix the problem and the deadline could not be moved. What needed to be done was reasonably clear but the effort required to actually do it was very large. It could not be accomplished by the existing programmer and most companies required outside help.

It so happened that there were many such people available, not next door, but across the globe. All you needed to do was to train them and set up the necessary communication infrastructure and bingo … the work got done. The year 2000 came and there was no mishap.

Suddenly, enterprises found that they had in hand a large number of programmers who could maintain the applications at a fraction of the cost. So, more work got shipped offshore and by and large the result was positive. As a result offshoring kept growing and became the ever expanding practice of developing and maintaining software program.

When you have two expanding practice for the same profession it is inevitable that somebody had to try a mix and match of the two.

Initial experiment of Agile Offshoring

Initially the agile proponents were reluctant. They were reluctant to try agile methods in an offshoring situation. Since the basic premise of agile was to have a collocated team how could you make agile work when the team is split between two locations across the globe? It was a big challenge.

However, software developers love challenge.

They quickly found out that the problem could be solved if you followed four basic principles.

  1. Select the right vendor.
  2. Initially co-locate the key team members.
  3. Create proper communication infrastructure instant communication.
  4. Setup a tooling infrastructure for tracking and continuous integration.

The result may not have been as good as what is achievable with a collocated team but it quiet impressive and anyway much better than doing waterfall.

So, the overlap between agile and offshoring kept increasing and today, for many of us, that is the preferred way of doing software development.

We have come a long way

Today we understand that:

  1. Agile works: In most cases agile works better than waterfall even when we are dealing large, complex, distributed project involving multiple organizations.
  2. Co-location is not always feasible: For most enterprise scale applications having a co-located cross-functional team is simply not a viable option.
  3. Single team may become too large: Number of people required to solve most enterprise scale real life problem is too many to be organized as a single team.
  4. Valuable pre-agile software practices existed: Rejecting all the software engineering practices that people used before agile came into existence is like throwing the baby with the bath water.
  5. Software development is not core competency of every organization: If an organization wants to focus on its core competency, there may be a necessity to involve specialist organization to do the software development.
  6. There is no agile nirvana: Diversity is the name of the game and difference in type of project and varied organizational context require different tailoring of agile processes.

Why is there a paucity of literature on Agile and Offshoring?

In spite of the inevitability of agile offshoring there surprising paucity of literature available on the subject. Books on scaling agile devote, may be, a chapter on outsourcing and offshoring.

If you have dealt with agile offshoring you will know that there are as many challenges as there are in other aspects of agile scaling if not more.

If you add to this the challenge faced by the vendor in managing an environment where agile projects will need to co-exist with projects executed in traditional manner, where they have to follow agile and still work within the CMMi framework then you realize that agile and offshoring is not a mere subset of agile scaling.

Agile and Offshoring deserves to be explored on its own right.

Agile and Offshoring Handbook

  1. Is Offshoring A Special Case Of Agile Scaling?
  2. Manifesto for Agile Offshore Software Development
  3. The Myth of No Upfront Design in Agile
Udayan Banerjee on Google+
About these ads
Comments
5 Responses to “Is Offshoring a Special Case of Agile Scaling?”
  1. I would like to invite you to pay a visit to our website: http://agile.fast-framework.com
    We think we invented the ultimate agile development tool. No server skills required, just javascript and xml. You might be interested having extra requirements. We do not consider the product final and are happy to extend it to your needs.
    Looking forward to your suggestions.

Trackbacks
Check out what others are saying...
  1. [...] Is Offshoring a Special Case of Agile Scaling? [...]

  2. [...] Is Offshoring A Special Case Of Agile Scaling? [...]

  3. [...] Is Offshoring A Special Case Of Agile Scaling? [...]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 989 other followers

%d bloggers like this: