Don't let 'fair' keep you from success


In software development, as in life, fashions change. In-house teams get dis-established and contractors are brought in by external vendors. Later the situation is reversed, and reversed again, in an endless cycle.

There are many organisations that have blended teams with a mix of internal and external resource. We are working with a number of groups like that at the moment across China and New Zealand.

There is one thing that I think is severely restricting the ability of these teams to deliver value - a lack of training. They want to become agile (or at least get the benefits of being agile) but large blind spots are stopping these organisations from even getting close.

What effect can we hope to have when training the team

Let's take a hypothetical example - I'll call them Sino Bank West (SBW). SBW has two teams rolling out an ERP system organisation wide. It's a customised off-the-shelf solution and is planned to take around 18 months. The teams are a combination of internal staff and contractors provided by the vendor. Some of the internal staff and project management team have had training. The teams are not multi-disciplinary, rather they are highly siloed with individuals responsible for individual components or layers.

Working with SBW, it becomes immediately clear that the contractors provided by the vendor have not worked in an agile environment before. They had not been supported (through training) to understand the agile mindset. Naturally they were extremely pessimistic about the value of agile and dismissive of the approach.

Five Dysfunctions

Looking at the situation through the lens of The Five Dysfunctions of a Team (Patrick Lencioni), it is clear that there was a lack of trust within the team and the wider organisation leading to widespread, persistent and persuasive dysfunction.

I approached the PMO with a proposal to secure training for the external contractors and the internal team together. My experience has shown that this has immediate and tangible benefits, including:

  • increased empathy and trust amongst the team
  • breaking down the "us and them" atmosphere
  • a shared language with which to talk about the work
  • alignment around the purpose and vision of the project
  • demonstration of organisational trust in the team
  • a shared understanding of the benefits of an agile mindset
  • a shared understanding of the mechanics of Scrum (in this instance)
  • a shared commitment to being agile.

I immediately hit a brick wall. The organisation is adamant that they will not train the external contractors. Their reasoning is that they will lose 2 days of development time and that the cost is not theirs to bear. I understood - it doesn't seem fair that the organisation should pay to train external contractors.

Why train your external contractors?

Let's look at some hypothetical numbers.

The team are 6 months in to an 18-month project. There are 10 internal staff and 10 external staff. Let's imagine the team will finish the project on time and on budget in 12 months.

If the external staff cost $200/hr and the internal staff $100/hr then the total cost for the project is $6 million.

  • 10 people at $100/hour
  • 10 people at $200/hour
  • 2000 hours per person over the year

Total cost of project: $6,000,000

2000hrs x ((200 x 10) + (100 x 10)) = $6,000,000

The ROI on training the team

The cost to train the team includes the wages for the team over the 2 days of training as well as the cost of the training itself.

  • Training for 20 people - $20,000
  • 10 people at $100/hour for 2 days - $16,000
  • 10 people at $200/hour for 2 days - $32,000

Total cost to train: $68,000

If the training increases productivity by 10%, as a result of the team being more agile, the work would be completed in 1800 hours/person or 5 weeks earlier. This is a saving of $600,000. Additonally the product will be in market over a month earlier - making money, reducing cost or both.

So the ROI on training the team is 12:1. The 2 days spent on training is made up within the first month.

  • 10% increase in productivity = 1200% ROI

This is a very synthetic example, but the 10% in productivty is extremely conservative. In a study by QSM Associates they found a 61% reduction in cost and a 24% reduction in time to market when comparing agile and non-agile projects.

Even a 2% increase in productivity yields an ROI of nearly 100%.

In my experience the increase in productivity is much higher than this and increases over time. The increase in productivity is a secondary benefit of being agile. The primary benefits we can expect are:

  • increased alignment
  • focus on results
  • accountability and empowerment
  • increased code quality
  • improved team moral
  • getting to market earlier
  • a focus on delivering value early and often.

full cartoon


If we are taking a rational, economic approach to decision making this would seem to be an easy decision. In my mind there can be only 2 possible reasons not to do this:

  1. the organisation does not believe agile will increase productivity or value delivered
  2. lack of rational decision making, led by a lack of trust.

Which reason is it? Why does your organisation not train its external contractors?