The Agile Backlash?

My colleague and friend Jon Kohl just finished the excellent post The Agile Backlash.

While I agree with his sentiment, my conclusions are a little different:

1) John Wrote: Obviously, this is behavior that is completely against the values of any Agile methodology I've come across.

It's easy to say that you are doing Extreme Programming. It's really easy to say that you are doing Scrum. The hard part is making decisions that line up with the Agile Manifesto - such as forgoing mind-numbing documentation, making the tough decision to forgo an "extensible" infrastructure, or refusing to accept the status-quo requirements document and insisting on a face-to-face meeting.

To quote Shakespeare from Henry IV ...

Glendower: "I can call spirits from the vasty deep!"

Hotspur: "Why so can I; or so can any man. But will they come when you do call for them?"

Right now, I am much less interested in companies using Agile terminology and much more interested in them making good decisions. Personally, I believe values of the Agile Manifesto are better than the current default in corporate America. By "Better", I mean that they will result in faster time-to-market, fewer defects, and better competition.

2) Jon Wrote: They forget to adapt and improve to changing conditions, and they just stick to the process, and try to follow the formula that worked in the past. As they get more desperate, they make wild claims promising that "Agile" will help them unseat a powerful competitor who is "waterfall", or will guarantee bug free software, improve all employee morale problems, etc.

This really odd - and very familiar. I see a lot of "Agile" process zealots. I don't get it. One of the points of the manifesto is to focus on individuals and interactions over process and tools, and yet people keep selling methodologies and tools. I suppose that's because it's easy to sell. I intend to propose a session at the Agile Conference 2007 to discuss this.

----> Overall, here's my takeaway. To paraphrase Esther Derby "Any good idea can be implemented poorly." Personally, I think this Agile/Non-Agile discussion is divisive and damaging, for some of the same reasons Jon outlines in his article. In my discussions with people, I have dropped Agile/Non-Agile from my vocabulary. My talks are more about More-Agile or Less-Agile, and by more-or-less I don't mean adherence to a process document, but instead consciously choosing to focus on:

individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan

Of course, this isn't as easy as mindlessly following someone's process description; you have to think.

I wouldn't have it any other way.