After using Agile to develop software products for several years, we thought we’d share the challenges we encountered at the start, what we did to change and the results we saw (which were ultimately uplifts in quality and efficiency)...
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:
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.
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:
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.
Here at cloudThing we're always happy to share so feel free to get in touch if you'd like some advice or help on adopting Agile