BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Agile and Offshore: Asking for Trouble?

Agile and Offshore: Asking for Trouble?

This item in japanese

Bookmarks

Kevin Coleman told his story working with an offshore team that claimed to be 'Agile' and the woes and worries that came with that experience in last month's issue of the Agile Journal.  Several readers validated his experience with their own.  In practice, can Agile methods be used successfully with offshore teams given today's business reality? 

The key assumption Kevin makes is:

Most off-shore development organization have standardized on the traditional waterfall development as their methodology.  These more traditional methods define tasks that have to be done on a large scale, classically organized project. These traditional development techniques tend to run contrary to the fundamental concept of Agile.

With this in mind, Kevin then introduces a set of very common (and costly) problems:

The offshore development team looks at this inventory, evaluates the requirements, size, complexity and effort required for each component in the inventory. Based on these estimates and the size of the development team the onshore and offshore team define and then refine what functionality will be delivered in the Sprint.  Once the definition of what will be delivered is agreed upon, the development process begins.  This is where the problems start.  ....  As the Agile methods progress through what has been called an iterative discovery process using demos and proof of concepts, new requirements are uncovered.  This becomes very costly, as billable hours are spent rewriting code and estimating the newly discovered requirements and changing schedules.

and

But it gets better.  Many hybrid (Agile/Traditional) projects use time-box management techniques and call it Agile.  Time-boxing is a technique that fixes the time spent on a given task or set of tasks.  Once the time-box is established, the development staff does the best that they can to stay within that time frame. So instead working on something until it is completed, as is the case with typical waterfall development, the offshore team only works on it for say, 5 days. At the end of those 5 days the work is either completed or is placed in the backlog inventory to be addressed at a later date, or replaces other functionality that was originally scheduled in the Sprint.  The reason this is done, is that the costs have now changed to implement this piece of functionality and needs to be re-evaluated by the onshore team.

and

Another hybrid technique replaces traditional reviews with functional demonstrations.  As the work progresses, feedback from the onshore team, business user/SME as well as the key stakeholder is received the feedback is integrated or if it requires significant additional effort it is deferred and entered into the function backlog inventory and addressed in a later Sprint.  If the feedback is required at that specific time it is, you guessed it, added to the Sprint task list, the work is estimated, change orders issued and the cash register rings yet again.

 

So, according to Kevin's experience, everything is costly when an Agile team works with a non-Agile offshore team.  The root cause seems to be, in Kevin's experience, that many offshore teams are not really Agile.  It also seems the readers who chose to leave comments on this article have similar experiences:

You have a very good point that combining the two two methodologies is risky! However, until both companies have worked together on a project or two and the level of trust is established between them, I have never seen a traditionally waterfall organization complete an Agile project smoothly. Usually you have to determine which practices each company hold firmly to then creatively build the hybrid/mutual process from there.

and

A word of caution to those who are using Agile Development by Offshore Developers, you have to make sure that the developers understand that it is your business and your money and your time that is being used by these developers. Since comprehensive planning goes on while the developers tackle the job and if you are not in the loop and no constant communication, then you are going to be in trouble.

and

I am living this issue right now - glad I am not alone. What’s the old saying misery love company?

Is this the same experience our readers at InfoQ have found?  If so, it should be noted that most of the articles this reporter has read on Agile offshore have been positive - is this a case of mis-information?  Or is Kevin just in an unlucky minority?s

 

Rate this Article

Adoption
Style

BT