BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Agile and Offshore: Asking for Trouble?

by Amr Elssamadisy on Oct 01, 2008 |

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

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

does offshore even work? by Christopher Brind

Firstly, does offshoring development work at all, agile or otherwise? I am not aware of any high profile success stories and everyone I talk to about it seems to agree that it just doesn't work or the overheads are just too high, negating the reason for doing it in the first place.



Personally, I am not involved with any offshore activity. I have always felt that it would be a bad idea and have gone out of my way to keep away from it as a result. However, I now have friends/ex-colleagues who are involved and all I ever hear are horror stories. I'm not sure they use a specific Agile methodology, but it sounds as though they are forced to be agile because of the quality of what comes back. I will see if I can get one of my friends/ex-colleagues to comment.

Re: does offshore even work? by Kiran Rao

Firstly, it is an understatement saying if anything works in offshore whether it is Agile or otherwise. The guy who is responding, himself claiming he was not involved in any offshore projects. So let me make this clear, whether it offshore or onsite, we should make sure once if we say we are Agile means what we are saying. R we really really Agile or for the sake of getting the client we are saying that we are Agile.
I know lot of success achieved using Agile in offshore, where I can't name the companies. But be sure, whether U are Agile, once that is confirmed, then look what is the problem with the teams who claim to be Agile and are not , I promise it would be a fascinating journey.

Offshore Agile by Kiran Rao

Whether this offshore project had any onsite customer...?
What methodology was decided to be used for the project ...?

I do not care about the billing or any other scrap if the team is delivering quality and timely product. If not, the customer or the project manager or SCRUM master in charge should probe what is the problem during the interospection after few iterations, if not done, even the Agile project will goes for a toss....

I ask a simple question, all the Agile projects that are implemented in onsite are successful...? Maybe rate is little higher, but not 100%. So failures are on both the sides. An organized company looks deep into the problem and corrects it timely.

So before we conclude, whether Agile works in offshore or onsite, we should be sure how we are going to implement the Agile methodology both in onsite and offshore.

Re: Offshore Agile by Amr Elssamadisy


So failures are on both the sides. An organized company looks deep into the problem and corrects it timely. So before we conclude, whether Agile works in offshore or onsite, we should be sure how we are going to implement the Agile methodology both in onsite and offshore.


I think finger-pointing will not help this discussion. I also realize this is a sensitive subject that raises all kinds of feelings - yes FEELINGS - that can easily dislodge any productive discussions :)



So - how about a few assertions and I'll leave it for others to agree or disagree:



1) The majority of offshore organizations are more experienced in CMM-like processes and cultures.

2) There is a significant number of offshore companies that say they are Agile and are not.

3) There is a significant number of US companies that say they are Agile and are not.

4) Chances are, based on (1) and (2), if you are a true Agile team in the US, you will work with a non-Agile team (or one that is cargo-culting Agile) offshore.

5) There is a fear of losing jobs to offshore that makes US developers nervous and gives them an ulterior motive to find failure modes.

6) There is an inferiority/superiority stereotype when it comes to US/offshore development. This stereotype brings up feelings that derail a project before it begins.



Ok - that is enough for now. Next week, the Agile Journal issue for October is out and there is a positive article written from an offshore team that readers will see do not invalidate Kevin's experience. There are also other articles focused on human dynamics which underlie every single success and failure of Agile adoption.

Agile needs a good team which needs a good culture mesh... by Kevin E. Schlabach

I believe a big part of a having agile work is having the team work well together in addition to the surrounding organizational culture. One of the main complexities of offshoring is the potential cultural differences.

There are cultures where saying "I can't" to a request from a higher level person is not acceptable even when the request is impossible." - from Agile Commentary blog

Re: Agile needs a good team which needs a good culture mesh... by Robert Morschel

We use offshoring fairly well with India in my current company. As for Agile and offshoring, given that Agile is big on communication and low on formal documentation I don't see how Agile and offshoring can go together since offshoring requires more formality and communication is often a challenge.

Robert
soaprobe.blogspot.com

Offshore worked for me -- with conditions by Greg Willits

I have worked with two offshore outfits. One worked well and suceeded, one I didn't care for. There was no claims of Agile in the latter, so not real relevant to this discussion. I inherited it, it was brief, and was a stereotypical relationship everyone hiring a crew prays to avoid.



The other project is one that I started, it lasted for about a year, and was successful. However, there are several contributing factors which I believe made it uniquely qualified for success.



1. The company we used is a (the?) leader in Agile methodology with several offices throughout the world. So, their Agility is well established.



2. We began talks with US-based people to establish the culture fit and the qualifications of #1. Originally we planned to start a US-based team, but there were a few factors that had us consider the Indian office.



3. The project was not very big, had been prototyped to a high degree, and over the course of several months during #2, our side had remained steadfast in the app's goals, design etc. It was a minimum concept to prove a business model. Scope creep was declared evil. This gave the contractors confidence that the project could be done with a remote team...with a couple of conditions.



4. I and one other person went to India for 3 weeks to embed with the team to launch the project. We had the opportunity to infuse the team with the business model, the goals of our project from a business perspective, and to talk about design. We made each of those first three weeks an iteration, so we could go through the entire cycle of an interation together a couple of times. Then we switched to two-week cycles.



5. For the first couple months, I altered my work schedule to be available during India time for most of their day. I like late hours anyway. After a while, I shifted to be available at least half their day to split my attention between US and India. By available, I mean I was working when they were, and we had an open chat channel at all times that typically was quite busy. We maintained a fairly high degree of open discussion IMO.



Lest ye think because of #3 the team wasn't allowed to inject new design... it was not so. We found several small weaknesses in the prototype and made improvements during development. They were a bright bunch with good ideas, and we took advantage of that within the scope.



The initial team size in India was 8 people, and the core project was completed in 5 months. After that we used from 2-4 devs to work on extensions for several more months.



I'm sure you can see that there were some exceptional conditions in this case, but nevertheless it did work because both sides recognized the conditions necessary to ensure it worked.

Re: Offshore worked for me -- with conditions by Gavin Terrill

Greg - thanks for your comments. I found them very useful.

Offshore issues by Jim Leonardo

Many offshore "development teams" have revolving doors, this alone is an impediment to Agile practices. The team concept that is so important to Scrum, XP, etc never takes root in a team that sees monthly turnovers that would make an onshore firm cringe even if those numbers were annual. This is precisely why offshore teams use CMM waterfalls. CMM and its ilk are designed to minimize harm by bad behaviors and less skilled people, whereas an Agile methodlogy seeks to empower its people. CMM=minimize risk, Agile=maximize productivity.


I also feel if you're outsourcing, you should be outsourcing, not trying to manage the external party... in short, if you outsource, it should be a black box. You plug in requirements, it spits out software. Anything else is foolishness. As the current financial crisis proves, "everyone else does it this way" doesn't equal "this is the smart way to do it"

Re: Offshore issues by Pranab Ghosh

I also feel if you're outsourcing, you should be outsourcing, not trying to manage the external party... in short, if you outsource, it should be a black box. You plug in requirements, it spits out software. Anything else is foolishness. As the current financial crisis proves, "everyone else does it this way" doesn't equal "this is the smart way to do it"


IMO it depends on the team, the company and the nature of the project. If the team is experienced and and matured, the spec very crisply defined you might be lucky to feed spec, sit back and get the software product back.

In the projects I managed, I had to do the following to make the projects successful
- Keep all the comunication channels open, i.e. email, chat and wiki
- Work late night to catch Indian morning hours and resolve the issues for the day
- Spend some extra time to do mentoring. It's amazing how much you can get back from the team for the time you spend on mentoring.

Re: Offshore issues by Pavel Veller

CMM and its ilk are designed to minimize harm by bad behaviors and less skilled people, whereas an Agile methodology seeks to empower its people. CMM=minimize risk, Agile=maximize productivity


Exactly. I am myself working in offshore companies for the last 9 years: 7 years overseas and last 2 years on the "front-line" in the states. I can confirm that the biggest problem adopting Agile when working with a big (important) offshore company is the lack of self-organized and self-motivated (= mature) teams. Agile requires a team to be more mature than a "regular" CMMI offshore team in fact is. By maturity here I don't mean technical skills. I mean a combination of technical and interpersonal skills, specifically: decision making, problem solving, and handling uncertainty.

Small niche offshore shops can be in contrast very ready and able to make agile though you as a customer may not want to outsource to them due to higher risks of such engagement... we wind up in a catch 22.

But, big offshore companies do know that Agile is demanded more and more and are spending real effort to transform to become more agile-ready and agile-oriented. It's not possible to implement on a big scale at once, but it is possible to do gradually: team by team, office by office. We have a few very successful case studies working with US and EU based companies practicing agile.

in short, if you outsource, it should be a black box. You plug in requirements, it spits out software


Never works this way. the more the customer is involved (not necessarily co-located as "pure" agile requires) the better the result will be.

From a Nearshore provider perspective by David Alfaro

My general opinion about this topic is written in this post:"Outsourcing Software Development to another Country Stinks" agilenature.com/2011/03/17/outsourcing-software...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

12 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT