Outsourcing in an Agile World

Or… How to make this work without it destroying your teams

We had a very interesting discussion in the most recent Practical Agile Workshop around how to make software development in an agile framework still work whilst utilising outsourced resources.

This is a subject that much has be written on and the initial temptation from a business is that the use of outsourced resource is equivalent to having a onsite team, only the time zones are different, after all big companies like Microsoft do this so why can’t we?

Well the general consensus was that there are two models that people think about when outsourcing is referred to:

Vendor

This is where you “buy” in resources to work on part of a project, either as part of a hybrid team consisting of resources from both geographic locations and different companies ( so 2 developers from OutCo limited and a lead developer from PrimeCo Ltd who are engaging OutCo for resource) or that the entire development team (Developers and Testers) is completed by a different company (so Development team in Slovakia but the ScrumMaster is in Newcastle and the QA testers are in Latvia for example).

This is the ‘classic’ model and is usually done to provide resource or to reduce overall development costs.

Captive Service

This is where the company wanting the work done sets up or buys a company in a different geographical location (usually a different country) to do the development work.

This is usually done to get the benefits of a development team that is grown in your companies culture but can also be used to add additional resource at a reduced cost.

The differences:

The major differences are the type of relationship and what that means to your project, and to a certain extent what you can expect. The vendor model is just that, you are ‘buying ‘ a service and the vendor provides that service (in this instance development resource) whereas with the captive service you are working with people who are part of the same company.

The issues:

So the major issue that came out of the discussion was communication. As everyone at the session was working in an agile or semi-agile way there would be little point in reverting to a more waterfall approach to implement a very detailed specification to the outsourced team, who would then only develop what was in scope and anything outside of that scope would have to go through a change process.

So to get around this the following things were mentioned as needed:

Communication Technology:

This may seem like a given but it is absolutely vital. Agile is all about that communication and the freedom for development teams to question and communicate with the product owners in order to deliver the best possible solution in the time.

Without an effective communication process, your projects will suffer and will potentially not deliver what was required, or deliver it much later. In order help with this,you need effective communication and effective technology to do this.

Email is obviously one way but it lacks the immediacy of that face-to-face conversation particularly when you have a team in one country waiting on a product owner in another to enable the

development to continue. Email has a tendency to either be ignored or the priority of it can sometimes be overlooked. The general consensus was that the following methods were best

Video Chat – This gives you the ability to communicate at a much more interactive level and greatly improves the understanding. Nonverbal communication is not quite the same as with real face-to-face but it is present to some extent.

Chat/IM/Phone – This is also a good communication tool, however, you do miss out on the non-verbal side of communication which is very important

Email – Although this is a good way to get information to a person, there is certain fire-and-forget approach to email that can delay a project as you wait for a response to that urgent question around acceptance criteria.

Access to Product Owners:

In the discussion, we were fortunate enough to have a team from Poland who were about to start work for PHG as part of their development team but as part of a captive service. They had experience of working in the vendor model and said that access to the product owner made or broke a development product. They found the best projects they worked on were when the product owner would visit to discuss future work and future sprints in a face-to-face fashion.

There is also a tendency to treat vendors as just a resource that does not need to know the whys behind any work item or even the project itself. This leads to a barrier to communication so the recommendation was that Product Owners should ensure that the business reasons for work items and the larger project should be communicated to the whole team, both on-site and offshore at the beginning and during the project

Add communication points to your process:

As well as the normal processes around agile communication particularly in a Scrum team, there was a tendency on some projects for the requirements to be misunderstood or misinterpreted from the offshore team.

This can lead to a toing and froing between the development team offshore and the team on site as bugs get raised against the code that really are a misinterpretation of the requirements, and this ultimately leads to longer development times.

In order to mitigate this people have added an additional meeting between the offsite person picking up a work task, a business analyst or product owner and a tester where they discuss in a meeting (usually no more than 15 minutes) where the BA/PO goes through the acceptance criteria with the off-site person to make sure that the requirement is really well understood prior to any code begin written.

This also works with solution designs so before the code is written it is also a good idea to have a similar catch up between the offsite person and the software designer (if they are on site) to ensure that the technical requirements of the work are understood.

Although this seems like an additional overhead, these things would happen naturally in a fully on-site team but it is just to ensure that the work item has the best possible opportunity of being understood by all parties.

Conclusion:

So fundamentally the three key take away points are, if you are going to outsource any development work, you need to ensure that:

  1. You have good technology for communication and feedback
  2. You have a product owner who is engaged with the team and available for the external team to ask questions of and to get answers from
  3. Add additional communication points where needed to reduce the tendency for work items to “bounce” back and forth between sites.

Many thanks for all those who attended this workshop and thank you for your suggestions. If you can think of any others or if we missed something, please add it to the comments below.

Graham

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s