Software Sweatshop - How to Avoid an Offshore Outsourcing Nightmare with Agile Development

Entries in outsourcing risks (2)

Tuesday

Apr072009

Agile Management: How Siemens Manages Offshore Development with Scrum

April 7, 2009

The Chicago Quality Assurance Association had an interesting lecture at the Willis Sears Tower on March 24th titled "Building and Managing Successful Offshore Teams Using Scrum" There is a big difference between offshoring internal IT projects versus offshoring commercial product development, but some of the same lessons still apply. In the case of commercial work, there needs to be a vested interest on both sides to adhere to the constant communication... doing this offshore is tricky. The main problem with traditional waterfall development (especially when working with offshore resources) is that problems are hidden and they only appear at the tail end of the project. It's no wonder that almost 65% of software projects fail! How many horror stories have you heard about offshore IT projects over budget, out of scope, or over due because no one knew what the offshore team was really doing?

Benefits of Distributed Agile Development

1). Lots visibility and transparency

2). Were able to deliver work fast enough with acceptable quality

3). Offshore team enjoyed agile/scrum, especially the intense collaboration with each other

4). Not one "onshore" resource lost their job

How To Do Distributed Scrum

1). The most important thing is that they took the attitude that outsourcing would succeed; no matter what

2). They did a lot of risk analysis and thought of everything that could go wrong: communication, source code violations, connectivity, etc.

3). Asked their friends and they said "don't do it"

4). Lots of cultural awareness training... learned about the Indian head bob

5). Refined the product backlog: for the first sprint they had 2 guys at a time in the US. Hires were all fresh off the street, not much experience

6). Created a sprint planning calendar

7). Trained Indian team in scrum

8). Lots of product training in the design, architecture, etc.

9). Held both teams to the same standard

10). Created team bios on MS Sharepoint

11). VSS was a problem so they had to merge code every month, it was a huge pain

12). Made sure user stories are well defined; good user story should be well developed

Challenges with Distributed Agile Development

1). Had to have a few conversations about underpromising and overdelivering with their offshore team because they took too many user stories and then ended up failing at the end of the sprint. this is a common issue with Indian developers. The desire to please is common in Indian culture, so it has to be tempered with a sense of creating realistic expectations.

2). Because of the problems with Visual Source Safe, they didn't see offshore code till after the monthly merge... code review revealed problems which they had to fix

For more on agile offshore software development listen to Andy Singleton's podcast on managing distributed agile software developmentand read Martin Fowler's article about offshore agile software development

Also check out Tackling Offshore Agile Development and Making Offshore Agile Work

Raza Imam |

The Sad Truth About Your (failed) Outsourced Software Development Project

January 5, 2009

Here's an email I received this week about outsourcing failure. He substantiates what we've been saying all along: most outsourcing vendors are the same. Finding good technical resources is easy, finding a team you can rely on isn't...

All outsourcing vendors are the same. I work in India, China, Malaysia and UK. All of them are already sub-contracting it themselves and have a tremendous shortage of talent.

Resources have no vision and no experience. To mask this drawback, for every smart individual they would have 4 non-performers who have fudged up their resumes and working behind the scenes to get knowledge and experience so they can bargain for bigger and better money.

To the offshore advantage, the onsite and permanent manager has a budget and a fixed time to deliver, so they have to compromise. Unless you are extremely technical and functional and do it hands on, consider it a failure.

The only reason, my projects have all been considered a success is simply I manage both the stakeholders and the technical and functional teams really closely. Every new recruitment on either side goes through me and my onsite support team. I stick to the plan and any deviation from me is costly and you have to get the financier to tell it to the stakeholder. I closely monitor the development as well as on the steering committee of the business.

Most importantly, your relationship skills should be able to wine and dine with the key committee once a week. I have to do it at the expense of the family, something that you will need to consider. You have to work overtime sometimes doing 18 hour days. 12 hour days should be the norm unless the projects are less than 25 million USD. No matter what factors you would consider, the only thing to sell to the shareholders is the money. Nothing else matters.

I have been working on offshore-onshore on some of the biggest projects in the US for the last 7 years and still doing it now. Not just one company but 3 of the biggest companies.
The junior stakeholders along with the indirect business seem to grunt, ramble and complain all they can but at the end of the day, when the board of directors see the money saved at the cost of quality, performance, resources, time, priority, significance, heavyweight, seniority, everything else become oblivious.

Go to any BPO conferences you will soon find out that anytime the project becomes complicated and out of the ordinary, it is a disaster. How do you manage expectations from the beginning will be a key factor for your success and not the failure of the offshoring teams. Remember, blessing of the financier and communication is the only key you will need to deliver.

Raza Imam |