Agile and Offshore: Asking for Trouble?

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.

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.

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.

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 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

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

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.

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

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"

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"

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

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

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...