Lurking Under that Resistance

Some of the topics at the AgileAustin Open Space revolved around a theme. Is Agile appropriate for critical systems (medical, life-supporting software)? Can we use Agile when we have a fixed timeline and a finite budget? Will Agile work when our software supports an always-on manufacturing floor? What about when developing strategic software, breaking new business ground? Are there times when Agile is not appropriate?

I believe the conveners are primarily asking these questions as proxies. They're at the conference because they believe in Agile, but they've been asked these questions by stakeholders they need to convince. So they're looking for help in crafting their arguments.

In my experience, resistance to Agile derives from an underlying fear. That fear tends to take some mix of two forms: "I've invested my career in getting good at one way of doing things, and you want to make me obsolete," and "My rear is on the line for a lot of money. I'm not interested in risking my rear while you experiment with your touchy-feely methodology. Just deliver."

When trying to convince someone, first sussing out his concerns and then pitching your argument to address them will make you most effective.

For the fear of obsolescence, convey that, while some ways of doing things may no longer be needed, the person is still valued, and he has skills and experiences that will help the team make the transition. Give that person a clear role, an obvious place of value, and his fears and therefore resistance should relax.

To those who are inherently change-averse, you can still work to improve the feeling of safety, to make the change more palatable. There are some folks, however, whom Agile doesn't suit. Let them find jobs as SOX auditors or something.

For those who seek assurances that this crazy experiment will deliver, on time and on budget, I take two tacks. I show them burndown charts, and explain how you can clearly see, "Does this trend line look like it's going to hit the finish line when you want it to?" Burndowns are very communicative graphics; they're a great tool. Second, I ask permission to try it for a month. Just, give me two sprints. Worst case, you've lost a month, which you would have spent writing half of a Business Requirements Document. Best case, you might have a few high-value, ready-to-ship features. That's a pretty good risk-to-return ratio.

Understand what fears are hiding behind their resistance. Address those fears (usually without making direct mention of them; fear tends to turn defensive if you point out a perceived weakness). Talk in their language, using their own levers, to present your case (e.g., talk numbers to a finance person). Finally, ask for something reasonable: "You don't have to do this forever, just let us try it for a bit, and then you can decide whether to continue or adjust."