Agile Fear

Agile is buzz word in software product development world. Proven time and again by pundits and practitioner as possibly the best way to develop software products, agile is drawing more and more attention from success hunger companies. Displacing water-fall as most preferred way to develop software products, agile is fast become popular but not without a tireless effort from people who advocate and promote agile without which story of agile would have ended long back.

The fact today is that agile still face resistance from various corners and its adoption still being debated in board rooms and on coffee tables. I spoke out my heart on some occasions challenging people to explain 'Why NO Agile?' and so did participants opened up to express their concerns. What followed was a good healthy discussion, results were positive and hear is my learning of why people say 'NO' to agile.

Why they say NO to Agile

Team members / engineers / testers: I will be micromanaged, tracked on hourly basis and my productivity will be questioned. Daily updates and hourly tracking in burn down charts are clear indications of control freak management.

Leads (Tech / Team / Module): This is just another way of cutting down on requirement documentations. Asking me to deliver with fewer clarifications and greater assumption is not going to work out for long. Management is ignoring need to detail out every aspect of requirement only to question me on fag-end of the delivery cycle.

Managers (Dev / QA / Delivery): All seems to be going well, why this change now? Is this another way of cutting down middle layer, get rid of unwanted redundant managerial staff. What will we do if teams are self managed.

Old war horses / IC: it is good when we are in control of our deliverable. However embracing agile now will bring in lots of surprises that we cannot think of. (Largely fear of unknowns)

Product Managers: Agile is good but only when you know what exactly is the requirement. It is not a good fit for first time products and also not a good fit for high stake customer deliverable. Pace of development might effect quality of deliverable.

Business owners: Why should I rock the boat, it is going fine for years now and let continue the same way. This might also call for unwanted training and hiring budgets. We do not have budget for this now, let us continue with the same method as we were doing early on.

Customers: it might be an attempt to make us accountable for their engineering failures, how can they do so.  Let us stick to our original plan.

I have learned this hard way, educate before you recommend. Change is certain but is smoother when welcomed with conviction. Agile evangelist have some tough tasks on hand, and its success will largely depend on how well agile as understood by the masses.

@mathurabhay