When to Agile
Sales people sell dreams… developers make them reality. But with this often awkward tryst things sometimes go wrong. We have all worked on projects that I am sure we all wish hadn’t started I am sure.
It’s been my experience that Agile is often sold in with an impression of being a magic bullet. Using agile so the story goes means that communications are magically perfect, products magically appear on time and magically produced in budget. But magic bullets are called magic for a reason… they don’t exist.
As an Agilista fanboy I am often charged by some assertive management type to simply “fix” the problem with that “Agile” thing you go on about..
So how do I do that? Let me tell you:
The Agile Investment
Agile needs investment on both sides. Simply prescribing the policy without making a commitment on both the customers and the developer is as doomed as Indiana Jones entering the temple without his bull whip.
The simple truth is that sometimes a project is impossible. No practice will solve a complex problem where team is neither in agreement or certain of what is possible.
Like my good mate Tom Cruise I have drunk often from the toxic chalice of Mission Impossible projects many times in my career.
Given Mission Impossible, it has been my approach to adopt what I call the Grip it and rip it. Shirt sleeves are rolled up, home truths are spoken and late night ensue with what can only be described as a mashup of Agile communications and waterfall milestones… or FRAGILE.
After a recent post on the LinkedIn Agile forum a colleague Brett Maytom introduced me to Ralph Stacey’s Chaos model and it was an epiphany moment for me. This one simple diagram gives a crystal clear impression of how to wrestle fractious customer and development team to the ground and reset it in such a way as not to burn out developers or frazzle Product Owners in the process.
I think it should become the standard issue slide deck for sales types.
When to Agile
There are two axis; the first is the certainty of technology and the second is the certainty of agreement or in our case the requirements.
In a world where you are 100% certain of the technology; i.e. you’ve used it all before and there is nothing unknown AND you know your customers requirements clearly you can use any project management methodology (although I’d recommend agile). This is because the project is simple and occupies the bottom left of the chart.
On the other hand the where a project detail is far from certain AND the agreements in place are far from clear we enter an area on the chart where anarchy exists. The likelihood is that ANY product management methodology will fail here.
The Agile Sweet Spot
The sweet spot for Agile is somewhere in the middle. A project where the certainty is unsure and/or the agreement unclear you should consider using agile. Its iterative approach teases out the relationship and the requirements. Only of course if both parties agree to commit to the process.
Often teams are tempted to starting a project where customers have vague requirements AND furthermore a vague impression of agreement. What ensues is a soup of impossibility and such a soup with sour any relationship your sales people have made.
I think that It is far better in these unsure circumstances to clarify and classify the development and what agreements you have before starting .
Start without these in place and you are sure to have to engage Tom and his IMF team for support at some point.
And believe me that does not come cheap. (Cue Music)
I hope you find this article interesting, check out my ebook, Agile Fu Its a short sharp read as to how you and your team can use Agile to develop you innovative ideas into reality.