I was first introduced to outsourcing many years ago when dealing with a client that liked using an Indian consulting company. At that time, around the late 90’s, the company was using purely waterfall development processes and agile was really just getting some publicity. My job was to translate business requirements into functions specifications that would be sent to the outsourcing company. I would then need to review the code that was committed by the development team to ensure it met the requirements, specifications and a general level of adherence to coding standards and quality. I learned a lot from those first few projects, and much of that knowledge has been supported by books and blog posts that have been written by others.

Over the course of my career, I have dealt with outsourcing in many projects, and a common theme tends to appear. In an in-house project, if you make a few mistakes you can likely recover and deliver a successful project. This is typically due to the fact that communication is immediate, and solutions can be crafted with the help of many people. With outsourcing, and in particular offshoring, that communication immediacy normally does not exist. This creates problems by itself, but when you already have made some mistakes it becomes very difficult to deliver a successful project. So, how do you avoid making a ton of problems for yourself? First, there are plenty of blog posts extolling the virtues of communication with offshore teams, so I won’t go into details. Without open communication, most projects suffer and time differences with offshore teams just makes it more problematic.

From the more technical perspective, how do you ensure that you get what you were asking for? When using waterfall development processes, you need to take the time to create detailed functional specifications that the outsource team can translate into small tasks. Unless you are very familiar with the outsource team, meaning you probably hired them and have worked with them extensively, you need to have the work completed in smaller tasks in order to understand progress as well as to have a better handle on reviewable design and code. This means that the functional specifications will take some time to develop properly.

You may be wondering why I keep talking about waterfall processes. This is really to set a baseline expectation. Many companies still use these processes and have not transitioned to agile processes. Part of this problem is that people know and understand the waterfall model, but they do not entirely understand agile processes. When dealing with outsourcing, agile processes may actually make more sense.

For example, when you are using agile processes, Scrum in my examples, you have a short sprint, maybe 2 weeks, where you plan to complete a small number of stories. These stories will be broken down into tasks in order to complete the actual development. These tasks could easily replace the detailed specifications from waterfall processes because they are typically small effort problems. In most agile processes, a task is meant to be something that can be completed in a few hours. This is likely a good size for an outsourced resource as well. There will not be a lot of clarification needed for a 4-hour task. The daily standup or scrum meeting is the perfect opportunity to communicate with the outsource team as well, thus eliminating many of the communication problems that typically plague outsourced projects.

Another benefit of agile when outsourcing is the sprint itself. By having a 2 week sprint, you get code that you can demo and test. This allows you to have a much better idea of how a project is progressing, and is one of the major benefits of agile processes anyway. With outsourcing, the management of the project and status of progress is always difficult. Completed sprints ease the pain of the outsourced project management. Again, it is a forced communication point that you normally do not have with outsourced projects.

With the benefits of agile processes, it seems like outsourced projects would actually gain more than in-house projects. So, why it is that we do not see more agile processes for outsourcing?