My development team has been using Agile to develop software product since 2007. 

Personally, I’ve seen many methodologies across many functions, including software development, all with varying levels success. 

Consequently, I am somewhat sceptical of silver bullet solutions, whether they appear in the form of a methodology or something else, and I’m also acutely aware that the skill of the manager and team plays a significant role success or otherwise.  Simply put, a very good methodology can be poorly understood and implemented, and therefore produce disappointing or disastrous results. 

For this reason, one needs to exercise caution when consuming content such as this very blog post!

All that aside, with little experience in our team but with a small investment in help from a company well versed in the Agile arts, we managed to transform our product development function back in 2007. 

Whilst this is not particularly unique and the case for Agile is pretty well made for the use of Agile for in-house development teams, what’s more unusual is the fact that our development team was not developing software product for our company, rather it was building product for third party customers, ultimately servicing large bases of downstream users; customer’s customers if you like.

Over a period of six months we migrated a mature waterfall development operation to a virgin Agile methodology. 

The catalyst for this change was complicated but the three facts that convinced me to cast my vote in favour were as follows:

• We couldn’t get high quality resources at an economic price in the UK and needed to include offshore talent in our resource mix.  We knew that our tools and methods needed to be rethought to manage this resource properly
• We were delivering software in a fast-moving environment and needed to be more responsive to our customer’s evolving needs.  The risk of not changing to meet this challenge was the potential undermining of long-term customer satisfaction
• We had quality and efficiency bleed that was clearly related to team members pulling in slightly different directions. Team members were well managed and doing their best but over a long development cycle with several developers, small divergences compounded over time

Put in slightly more emotive terms, to my mind we could remain as we were and struggle to resource our projects, with escalating costs, falling quality and degenerating customer satisfaction. 

Necessity being the mother of invention we decided to do something about it.

It took six months to go from review to complete roll-out across our team of sixteen developers and thereby into our customer development projects. We didn’t have the option nor, with hindsight, the absolute need to change contractual arrangements to support our new development approach.

Rather we sat our Agile development within a PRINCE2 framework that most of our contracts mandated and used it to conveniently link contract governance with the separate Agile development management. 

I understand that there is now something of a buzz around this blending of Agile and PRINCE2 project management because, as it turns out, it works rather well.

This all happened around eight years ago, to the day as a matter of fact! 

So what happened and where are we now? 

In short, at the time we saw an almost instant uplift in quality and efficiency. 

• We magically manifested the equivalent of five more developer time in our existing team. 
• We recruited and successfully on-boarded an offshore developers into our team, operating as cohesive unit, irrespective of the obvious geographical divide. This diluted our cost base and provided us with the resources we required

Customers were surprised by but embraced, and enjoyed, the open invitation to change their deliverables without necessarily changing price.

Customer satisfaction improved across the board and we collaboratively developed better software product.

In terms of where we are now, we have significantly evolved the model over the last eight years.  We have refined our overall approach, including:

• The tools that we use to support and manage the development process
• The methods that we use to gather and understand requirements
• The methods and specific implementation of Agile that we use to manage development
• The contractual framework we have at our disposal to engage with our client’s product development

It’s fair to say that we are way better at this eight years on and are not only extremely efficient and cost effective but have high levels of staff satisfaction, directly evidenced by high retention and low churn. 

Critically, as staff are tooled up to take great care of their customer’s projects, our teams are far more than the sum of their parts allowing us to take on hugely challenging projects and deliver satisfaction across the board. 

Agile has worked wonders for us and we would heartily recommend that any business with a software development function adopts Agile, if they have not done so already.