07 May 2014
My Agile is not Your Agile
by Melanie Franklin
Stuart Rimell, Head of Web and Mobile development at IG gave a very well constructed talk on the elements of an effective agile environment last week, with over 50 Agile Londoners @AgileLondon attending, despite the bad weather.
My Agile is not Your Agile
The subject of his talk was ‘My Agile is not the same as Your Agile‘, highlighting how agile doesn’t have a standard recipe which if followed will move the team from waterfall to agile projects. Whilst he did not give IG specific examples, I totally support this premise of diversity as I have never implemented an agile approach the same way twice.
Dilution of the term Agile?
Stuart explained that this partly because agile has become subject to semantic diffusion, a definition created by Martin Fowler in 2006, resulting in agile meaning something different to everyone who hears it. Stuart also says its because it’s a neologism (a new term just entering common use but without full agreement on what it means) just like Web 2.0
Agile is so simple
He wondered if this open interpretation is because agile is so simple? After all, there are only 4 values on the manifesto but I think the broad interpretation relates to another of his points – that agile is a mindset and not just a mechanism. A mindset means people have to interpret what agile means for them personally and their unique perspective will be demonstrated in their implementation of it.
The most obvious example of this that I encounter is the assumptions that senior business managers make that agile delivers faster to market solutions whereas the delivery teams see it as a way to cut down on process and documentation.
Shifting the bottleneck
Irrespective of these different interpretations, Stuart made the very valid point that if only the delivery teams adopt agile and they don’t take the business with them then only limited benefits can be achieved. This is because project teams can optimise development as much as they like but if the speed of decision making and the collaboration from the business doesn’t exist then the business becomes the bottleneck and everyone slows down to their speed i.e. The theory of constraints kicks in.
Personally this is where the real challenge of implementing agile lies and why I enjoy it so much – unlike implementing the old waterfall methods like PRINCE2, business buy-in is a prerequisite to success. Translating the benefits and constraints of agile from tech speak to commercial terms and demonstrating agile supports the realisation of strategic objectives is very challenging and forces me to work at the top of my game.
Can training add value?
I don’t want to turn this blog into an advert for training, but it seems obvious to me that if you want to join in the debate about how your organisation should apply agile, you have to learn the core principles and techniques first. Training courses are a valuable and cost effective way of getting everyone onto the same version of agile – so next time you are wondering what version of agile you want your business to run with, call me and I will be happy to explain the options available.