A tweet escaped from Product Tank this week from Benjamin Mitchell, watching Tom Loosemore talk about alphagov:
“It’s a mix of ignoring them [non-Agile managers] & making shit up” #ProductTank How is this consistent w/ Agile values of openness & trust?
There’s a conference-worth of material to unpack from that question. You can make up your own responses, whether cynical, pragmatic, witty or all three. I wasn’t at Product Tank, so I can’t take issue with that in detail (though I would caution readers: I know Tom, and his presentation will have been as much about entertainment as education and information, so take that statement with some amount of salt).
However, regardless of its literal truth about alphagov specifically, there is a truth in there about projects in general: if the idea of agile is used as a trojan horse to allow bad behaviours, then any success will be shortlived. That thing masquerading as agile won’t scale to other teams; it certainly won’t scale to larger projects. Agile might be seen as the success factor in the initial project, but the inevitable failure of future projects will ensure its adoption is halted pretty quickly.
This is true for small and large organisations of all kinds, and is one thing that James Yoxall touched on in his presentation to the 2011 Agile Business Conference.
When I manage development teams I see one of my responsibilities as being the angel on the shoulder of those developers, urging them to “do it right” in the face of the project manager who’s urging them to “do it now”. But project managers can be angels, too. Some will be interested only in the success of their own project. And some will want to ensure that good practices are recognised, learned and adopted by others. Unfortunately those two views are sometimes at odds.
It’s good that finally someone has a balanced view on Agile: it’s not a Panacea, and Waterfall is not evil…
PS: You might be interested in this post that I have published lately on PM Hut: Is Agile Better than Waterfall?. I hope you’ll have the chance and the time to read it.
I am a Business Analyst for a larg Comglom and I used Agile on a few occasions and each time it was a nightmare not becuase it was not run properly but becuase the very mannar of how Agile works creates a layer of confusion and will not fit most Medium to Larg projects. Small projects or improvements where the nature of the build is less complex seem to be a better fit and gives the opportunity for the stakeholder to deliver without the need of a Business Analayst.
However In My experience Agile is deployed becuase someone in the Business either a sponsor or an Head off has heard of it and wish projects to be deployed by the the Agile doctorin without understanding Agiles Limits and the problems Agile can cause.
Agile can work, but it needs a set of established requirments and would need to create a space for the process of User centered Design Agile does not currently allow space for this to happen.
Another way in which Agile is sometimes used is by a Project Managers requesting Agile normally and unfortunatly becuase they want to be able to point the finger at something else when their project is failing and this happens more than you think.