Agile readiness: Ready or not, here I come.

“If you take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.” — Matrix

Converting from one religion, ideology or methodology to another is a very tough thing to do. Especially when you’re fed only one thing all your life, its going to be hard digesting anything else.

Similarly with non-agile methodologies we as engineers, analysts, and managers have repeatedly seen loop-holes, failures, fiascoes but continue to use them because that’s what we were taught in college, that’s what we opened our eyes to in the corporate world and that’s what we are most familiar with.

On the flip side, there’s another kind of people who read things from a book and start following it blindly. It would perhaps work fine if you’re reading something from a cookbook and trying it out, but it would be a disaster if you read something like ‘How to fly an aeroplane — for dummies’ and thought about giving it a shot.

The latter is the kind of people that give agile a bad name. As a project manager I interview a lot of people applying for various positions in my company, and a huge percentage out of those claim to be followers of agile. Their idea of agile? Daily stand-ups, no documentation, requirements in the form of stories and estimates in the form of story points and that’s it. To top it all, almost all of them believe this recipe does not or would not work with complex or large projects e.g. ERPs etc.

First of all there are SO MANY things just plain wrong with the definition above. And yes, if that was how agile worked, it would be a horrible choice for even small projects and websites let alone ERPs. Second of all no two organizations are alike, no two teams are alike, and last but not least no two projects are alike. So you can’t just follow a checklist of principles and call it agile, you have to take into account SO MANY other things before you even THINK about adopting agile.

For instance: How empowered are your employees? How good is the level of communication/collaboration between the management and the development teams? Does your company have cubicles? Do you know what concerns your developers and testers have rght now? (even before proposing ‘Agility’) etc etc. Like I said there’s a whole plethora of factors you have to consider before adopting Agile (or any methodology for that matter).

To help you with an adoption strategy you have to have an experienced agile coach who would evaluate your strengths and weaknesses as an organization and analyze your overall agile readiness.

I would recommend the website http://www.dragile.com to all those people seeking help with agile adoption. Just take this 3 minutes readiness assessment as see how ready you are for the agile transition.

So if people tell you they tried their hands on agile and came to the conclusion that it sucked, it’d be wise to first find out their definition of agile before forming an opinion about agile itself.

If a ferrari crashed in a tree because it was being driven by a toddler, don’t blame the car blame the driver (or in this case balme the parents for letting a kid drive )

My two cents worth.