Meanwhile, someone who likes ideologies will devise the next big approach (Software craftsmanship anyone?) and everyone will start preaching that. By fits and starts we take this infant engineering discipline we work in (It’s less than a century old.) and we advance the state of the practice and the state of the theorizing about practice.

To answer your question Agile is nowhere near dead. I know a large number of companies that are looking to either add more agile into their existing processes, or extend agile principles and practices into other areas of their business. I do believe that we are past the point where marketing is needed for the Agile movement, and now we need more people like you talking about their experiences with Agile and how it’s worked best for them.

[I agree. I'd would even go so far as to say that the strongest opposition to lightweight methods I have seen are with people who's arguments boil down to "but we only have one kind of tool. If you take away our process, our templates, and our documentation, we don't know what else to do." Somehow, I expect that a deeper tool belt would have helped.]

It is like looking at the challenge of building and delivering software that meets our needs through two different lenses that help us understand different things. To the extent that those lenses highlight different interesting things (people, motivation, communication and coordination, trust, etc.), we gain more value from the comparison. YMMV.

[Good point. And please tell Andy I said Hello.]

[Matt too, but I think I took a more system-thinking, less "branded" approach.]

I drank the koolaid fully because I have seen it work, and truly believe it is a good way to deliver software.

[I think I know what you mean, Janet, and I think I agree, but I feel obligated to say "Drinking the koolaid", as a metaphor, is entirely opposed to everything I am trying to do. The people who drank the koolaid at Jonestown /died/ because of that choice.]

I think that the dogma years was necessary because people were trying to explain what it was, and how to use it.

[Were they? I'll give you two examples - XP and Scrum. XP came out of a big corporate beuracracy that couldn't get anything done because, to do anything, you needed to spend two years writing a big thick 3 ring binder spec, that you would pass off to implementors, who would have no idea what you were on about. So they wanted a method to do /something/ right now, and adjust. Scrum, on the other hand, was popularized at Easel corp, where they had the opposite problem - the marketing people had flavor of the week disease and they couldn't get anything done because the tech team was always changing direction. So Scrum had the idea of the 30 or 90 day iteration so the customers would leave the developers alone to actually get something done. Two subtly different solutions to two very different problems. Now say it's 2001 and I'm dogmatically recommending a specific implementation of XP. Is that the right approach? Do I even know what the problem is that I'm solving? (I used to ask this kind of question five or ten years ago; I find that today, I get a different response.)]

We now know so much more than we did 8 – 10 years ago. Each of the ‘prescribed’ methods have strengths and limitations, so organizations have combined and chosen practices that meet their needs. And yes, there still is a lot of dogma out there.

[If you are saying the body of experience has evolved so we can tell the subtleties apart, then I think I agree.]

I am consulting these days, and am usually called in because the testers aren’t getting it. I find that usually isn’t really the problem and that there is something else that needs to be addressed to fix the real issue. Agile isn’t easy, and sometimes it helps to follow the practices in a particular method(s) exactly to get into the groove rather than finding out by trial and error.

[I hear this argument all the time. I think I sort of vaguely understand where you are coming from, and I have some concerns. I suspect we should talk more, and reason together.]

Organizations have been using it for a while and are now finding their groove, and determining what they need. That may be ‘why now’.

It’s now become a matter of regularly delivering good software that meets business needs. I liked Lanette’s comment “Agile is beautiful when done well because it builds teamwork and grows people better”. I think that says it all. The trick is … to do it well.

[Point taken, and it's a good one. Thank you.]

This post was mentioned on Twitter by chris_mcmahon: this on agile from @mheusser is pretty righteous: http://bit.ly/pciy8…

“Let’s agile this, agile that…”

It reminds me of the Dilbert comic about Agile Programming: http://farm4.static.flickr.com/3062/3345485483_8e1816fa9f_o.gif

I don’t think Agile Software movement hit a brick wall. I think the hype might have, but agile adoption is still making its rounds and growing.

This, to me, is part of the evolution of Agile and an indication that it is really taking hold. Over the past year or so, many Agile consultants have told me that, previously, they had to convince clients to accept their development process. Now, the process is often a given.

Sure, ‘Agile’ has become a bit of a buzzword, but that’s largely due to the non-technical/management people finally letting go of the traditional approach.

I’m new to Agile, as you know, and I think why now is because the other process driven methods aren’t working in this economy. To be blunt, the huge overhead involved with the “let’s be like manufacturing” derived methodologies is too expensive and is not good for keeping a motivated and highly productive team together.

Agile is beautiful when done well because it builds teamwork and grows people better than the “every cog is micromanaged in the well oiled machine” methods (fishing maturity model). Also, human beings like being important, good testers and engineers are too clever to enjoy being managed, and want to be enabled, have resources to make great software, and a good scrum master can make that happen.

[The well-oiled machine thing is bigger than software - it's about the way to run a company - it's based on an ideology. And I may finally be getting to a point where I can do some writing on that. Thank you for the encouragement.]

When I question you about “Why is THAT Agile?” I really want to know. I want to know because it has more potential than the other things we’ve tried and it just feels better than the overly bureaucratic alternative.