Software Sweatshop

Jon Graham shared the following outsourcing advice for newbies... 

"The outsourcing movement has just reached puberty and will be maturing over the next few years. In the past, it was thought that only large organizations could afford to outsource, but that is not the case any longer. The small to mid size companies are getting into the game as well. However, for the outsourcing newbie's out there that want to take the plunge, there are a few things to consider in order to ensure success."

Whether you're looking at India, Russia, Ukraine, Vietnam, China, Brazil, Montana, or the Philippines, outsourcing isn't easy. Here's a list of tough questions you need to ask:

1. Process: How am I going to manage the work that I am going to outsource? What processes and procedures do I need to have in place? How often do I want updates? What level of information do I need? What delivery model am I comfortable with?

2. Tools: What tools can best help me manage the process I've defined. Do traditional individual tools work; mpps, word docs, emails, spreadsheets? How can I get real time project updates about vital project statistics/metrics? Is there single web-based, software development management (SDM) system?

3. Vendor Selection: What type of experience/skills/corporate culture does my service provider need to possess in order for us to be successful together? Is this a one project stand or is there potential for a long term engagement? What types of work has this vendor done in the past. Interview them as you would a potential employee.

(This is not a new post. I just decided to change the title...)

A lot of offshore companies will tell you (primarily India, Philippines, China, and Vietnam) that if you work with them, the timezone difference will allow them to work while you sleep. They're an asset because you now have a 24/7 development cycle. Sadly, it's often a liability.  

In most cases we've seen, unless the specs are really good, and the development team sees the big picture, a 24/7 development cycle becomes a 24/7 headache. The lesson is that you should either have good specs, or be prepared to pay for specs. A mature development team will tell you this from day one... it's a sign of maturity. We've seen too many floundering projects resulting from poor specs.

I met a guy that was looking for offshore Java developers. He did a lot of research and ended up working with a company in India. As expected, part of their pitch was that they program while the client sleeps, a real 24 hour development cycle. We've heard this pitch before, and in theory it sounds good, but it assumes that the developers don't make any mistakes. In our experience, problems occur when requirements are not clear and there is a lack of communication between both parties. The client ended up working with a "near shore" vendor, but the following advice could help prevent problems with your offshore team.

-Committment on both sides: Make sure you have a local and offshore project manager. The local PM will communicate with users or internal stakeholders and the offshore PM will communicate with developers. It's helpful if they both have experience working with distributed teams.

-The Key to Any Relationship: Whether it's a marriage, a football team, or a team of software developers, consistent and structured communication is the only way to prevent heart-breaking (not to mention bank-busting) misunderstandings.

-Proper Methodology: Agile or Scrum methodology is helpful because it's highly iterative and allows for changes

-Solid QA: The offshore team needs to have a solid QA process in place. Developers aren't the best testers, and they shouldn't have to be. Make sure your offshore team has heavily invested in QA. Ask about their QA process and how they ensure that their work makes the grade.

-Find Solid Developers: Past work, a pilot project, or an exam are all helpful to make sure you're getting a qualified resource. It's not always critical to get an incredibly experienced developer as long as they have a good attitude and are willing to learn. An honest vendor will tell you the strengths and weaknesses of their team.

...you can’t negotiate with a methodologist.

Needless to say, following a good methodology is an integral part of any respectable software development effort, particularly when you’re working with an offshore team. In fact, most offshore horror stories have less to do with the technical expertise of the developers and more to do with how the project is handled. Many times projects get compromised because the vendor is juggling too many projects at once. Resources are scarce, teams get stretched, deadlines are missed… you know the drill.

Project failures rarely happen at the ‘ones and zeros’ level, so the real trick is to communicate with your team constantly (daily) to make sure expectations are clear and work is being done according to plan. So what you’re paying for is the set of principles that your vendor has established, their culture, their hiring and retention strategies, their growth vision, their industry expertise. The real question becomes, at the moment of truth, are they willing to cut corners and compromise these principles?

Even if they have technical weaknesses, working with principled methodologists who compromise for no one will always lead to success. Companies that define themselves and refuse to compromise will give you the only thing that really matters in business… trust.

I just saw a great video on the Scrum methodology delivered by Ken Schwaber at Google back in 2006.

Scrum is like having a gun to your head; if you can't produce results, be transparent, look for the simplest solution, adhere to strict deadlines, be held accountable, work incrementally and iteratively, respond to dynamic change, and deliver quality, you, your project, your company, and your career are dead. It's not all gloom and doom though, you'll be surprised at what you can come up with if you actually do follow this methodology.

It's perfectly suited for offshore software development. In fact, I can see why distributed software development teams that don't follow Scrum or Agile usually fail.

But as you'll see, Scrum isn't for everyone. It means looking at the facts, good or bad, and making very tough decisions. True adoption of Scrum is a real test of an organization's culture. With Scrum, you can't stick your head in the sand. A very valuable lesson for anyone that's been part of a failed offshore development effort.