Agile Zone is brought to you in partnership with:

I am a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. I do not care if something is new and shiny. I want to know if it works, if it is better than what I use now, and whether it makes my job or my life easier. I am also the author of and Founder of, a social media monitoring and tracking tool. Robert is a DZone MVB and is not an employee of DZone and has posted 109 posts at DZone. You can read more from them at their website. View Full User Profile

Agile And The Art Of Outsourcing

  • submit to reddit

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?

Published at DZone with permission of Robert Diana, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Keith Sterling replied on Tue, 2011/09/27 - 11:21pm

Sorry, but this article neither discusses Agile or Outsourcing and certainly does not show how Agile can be used to make Outsourcing work.

 You state "With the benefits of agile processes, it seems like outsourced projects would actually gain more than in-house projects." but don't provide any detail ?

 Infact Agile causes a whole different range of problems for an outsource company. How do you manage scrums across multiple timezones, languages and cultures. How do you over come one of the major tenets of agile, that of close collaboration between the delivery team and the product owner ?.

Certainly there are many benefits from any team adopting agile techniques such as iterative incremental build, TDD and automation but culturally a lot of Outsourced organisations struggle because they have a top down command and control structure which does not fit well with Agile.

However its the last piece of the statement above that seems to suggest that Agile is better for outsourced teams that in-house projects. This is hugely misleading because in house teams have all the benefits of colocation, easier communication and single culture. 

Sudhakar Ramasamy replied on Sat, 2011/10/01 - 8:56am

While reading this post, the only thing I could think of is how timely. In my new job, I have the same exact role as yours in the late 90's. Amazing how the technology world has changed but some of the processes have stayed pretty much the same.

In any case, I'm delivering my very first project. And my approach is to analyze the functional specifications and translate them to user stories with tasks and acceptance tests. My goal when working with the off-shore team is to

  1. Clarify the requirements by discussing the stories in plain English. Eventually I want the Requirements team to provide us the stories in plain english instead of Requirements docs, that way everybody can speak the same language, but also we can translate the stories to executable specifications.
  2. Get better estimates because we now have simple, smaller stories and their tasks laid out
  3. Deliver the code iteratively, so I'm not looking at a whole chunk of code towards the end of the development phase. Delivering the code iteratively will also let me integrate with trunk which is a moving target due to other projects, and the integration process itself is less headache prone since we are doing it a little bit at a time.
  4. Be able to provide a much better sense of project progress.
  5. Happier developers hopefully since they can see their achievements and progress much more quickly.
  6. More importantly if the requirements change mid stream we can still adjust especially if we haven't even started work on that particular story.

I'm sure there are other benefits that I can't think of right now.

Emma Watson replied on Fri, 2012/03/30 - 3:01am


 Hello Robert,

Thanks for the useful info. I have read your writing and its written in a good manner.

Certainly, Spriniting has been found to be a great benefit to outsource the agile. One can obtain code by having two week sprint and this code could be tested. This provides us a more appealing way of getting an idea regarding project progress which is always considered as a great benefit of the agile.

java program

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.