There’s the rub. “Agile” doesn’t assume any such thing. OTOH, when people want to separate you from your money, they’re liable to try and get you to believe just about anything.

It’s clear that you are unshakeable in your beliefs. Carry on!

Where you lose me is in your contention that there’s some sort of crusade going on …

Two different perspectives … and I’m not alone.

There are practical ways we can help people figure out how the collective experience of the profession can be applied to their environment. Every organization, every team, every individual doesn’t have to start on Square One.

Who said anything about starting from Square One? That would be everyone trying to figure out everything for themselves. We just can’t assume that because one technique or set of techniques worked for you, that it will work in any other circumstance. Agile assumes it will work in every situation, or at least that is what the people trying to make money want you to believe. BTW, this sort of marketing based process adoption is not exclusive to Agile or software development. Agile just happens to be the current snake oil in my chosen profession.

Discussions of that kind are common. There are even a few controlled studies available (but not nearly enough). It’s hard to believe you’re genuinely interested in that sort of discussion, and yet haven’t come across any.

It’s hard for me to visualize how TDD in particular could become an administrative nightmare, but I guess you were just trying to give an example and not to get into specifics.

“What I don’t care about is Agile as a _set_ of techniques.”

Individual techniques can be used and may add value. No one will stop you. In some cases, a set of techniques is crafted in a certain way to achieve particular goals. XP is put together the way it is so that the strengths of individual techniques can offset the weaknesses of others. So, as a “set” it can deliver greater value than the individual techniques applied in isolation.

Even if you don’t apply some predefined “set” of practices that has a name, then you can improve results by combining techniques that enhance each other. For example, pair programming doesn’t add much value by itself, but tends to help reinforce best practices on other techniques the team may be using. My point is that sometimes you will overlook something potentially useful if you scrupulously avoid assessing the value of multiple techniques used in conjunction.

Also, the very fact that the people who defined XP as a “set” were aware of weaknesses in individual techniques and took pains to offset those weaknesses contradicts your claim that agilists think it’s a silver bullet.

Where you lose me is in your contention that there’s some sort of crusade going on, where the Knights of Agile want to gallop in and force everyone to do all these things at swordpoint, “just because.” That’s totally contrary to the whole philosophy of the agile movement, and IMO an unproductive way to engage fellow professionals in the search for effective methods.

“All we can do is share what has worked for us and the environment we were in and hope that people are smart enough to figure out how our experience can be applied to their environment.”

We definitely disagree on this point. I think it is very possible to go one better than just “hope.” There are practical ways we can help people figure out how the collective experience of the profession can be applied to their environment. Every organization, every team, every individual doesn’t have to start on Square One.

Since “Agile” is about doing a certain set of techniques, I really don’t care about it and am not interested…

What I don’t care about is Agile as a _set_ of techniques. I definately want to hear about the techniques themselves, like when pair programming worked or didn’t work, or when TDD was a benefit or when it became an administrative nightmare. Those are the kinds of thigns I want to hear. I don’t want to hear “This set of techniques has produced 1000% increase in productvity, made us millions and got us lots of girls. Send $59.99 now and you can join in the fun. It will work for you!”

The truth is, agile is about finding the most effective way to deliver value in the context of each particular situation. It’s neither more nor less than the goal you claim to have, yourself.

We clearly live in two different worlds with two different truths. If this truly was what Agile was about, then this site would not need to exist and I wouldn’t be getting so much support from people who agree with me. I also wouldn’t be upsetting people so much.

What seems hard for you to accept is the idea that some people may have already discovered techniques that are generally applicable; that they have gone past the YMMV level of understanding.

Yup, you are right. I believe that there are no techniques that are generally applicable. There are so many variables and unknowns and differences between projects that we can’t even begin to claim in any sort of scientific way that we’ve found something that is generally applicable. All we can do is share what has worked for us and the environment we were in and hope that people are smart enough to figure out how our experience can be applied to their environment.

The two things you mention in comment #10 are very interesting. On the one hand you write

“Do whatever works for you” does not preclude sharing what has worked for you and listening and researching what has worked for others.

In order to do this, you’d need some kind of well-defined vocabulary to create a shared frame of reference so that others would understand what you were talking about when you shared what had worked for you. But…

Since “Agile” is about doing a certain set of techniques, I really don’t care about it and am not interested…

…sounds as if you lose interest as soon as someone tries to nail down what “worked for them” in any sort of formal way, so that they might actually have a chance of sharing what they had learned.

Interesting. You are the tree that doesn’t bend, whichever way the wind blows.

You also write:

The fact is that a large majority of software developers don’t use pure “Agile”…

I might add, “and they never will.” What you call “pure Agile” is an ideal to strive for. In real-world situations, it’s rarely possible to get there and it’s often counterproductive to try and force things to go that way. But it does provide a useful target for incremental process improvement.

Agile may be contrary to organizational culture, management practices, or individual preferences of the developers. It may be impractical to obtain the level of direct participation agile requires from customers, causing us to take a step back from the ideal. It may simply be the wrong approach for a particular problem based on the characteristics of the problem itself.

The truth is, agile is about finding the most effective way to deliver value in the context of each particular situation. It’s neither more nor less than the goal you claim to have, yourself. What seems hard for you to accept is the idea that some people may have already discovered techniques that are generally applicable; that they have gone past the YMMV level of understanding. So you build a strawman that you can knock down easily: The “Agile religion.”

You’re right to say that there are countless stories of success and failure in software projects involving every sort of process and methodology we could think of, and then some. All the more reason to try and distill all that experience into some kind of re-usable form.

If you become interested in that, let me know.

Some of the techniques we associate with the word “agile” are well-proven in practice

This is blantantly over generalized and false. Claiming something as ‘well-proven’ is dangerous namely because proof is a very difficult thing to find. Absolute proof is in fact impossible to find in software development, since it is impossible to create reproducible scientific experiments. That aside, if you had said “Some of the techniques associated with the word “agile” have worked out well in my experience and I’m confident in their practice” then I’d be fine with that. The fact is that a large majority of software developers don’t use pure “Agile” so the fact that you’ve got some examples (even hundreds of them) of successful Agile projects means nothing compared to the number of projects being done every day in many different ways. Proof by example is not proof. And I’ve got lots of evidence that a) Agile techniques are not required for successful software development and b) Agile techniques can really get in the way of successful development. I’m sure pretty much every developer you ask will have some sort of ‘proof’ on either side of the debate, so getting out our measuring sticks is really not going to solve anything.

I’m not interested in proving that “Agile” works or doesn’t work. I’m interest in letting people know that it may or may not work for them in their context, with their team, with their project and they should think about all that before drinking the kool-aid. But then that is not as economically valuable as a cure all solution for our software woes.

1) Your third paragraph in your last comment confirms exactly what I’m saying about a certain segment of current Agile thought. Namely, that “Agile” is not about being _agile_, but about doing a certain set of techniques. This is fine, except the name is confusing and misleading. We’d be better off calling it Foo. Since “Agile” is about doing a certain set of techniques, I really don’t care about it and am not interested in hearing how great “Agile” is. Everything anyone says in that context is suspect because there is a chance they are trying to sell me books, “Agile” products or consultant services. Now I realize that for some, “Agile” isn’t about dogmatically implementing a set of techniques and I’d love to hear from them and learn what does and doesn’t work, as long as I have some sort of idea of the context in which they develop software, so that I can then make comparisons with my own context and try techniques that make sense.

2) “Do whatever works for you” does not preclude sharing what has worked for you and listening and researching what has worked for others. That is key in figuring out what will work for me. If you tell me what works for you and give me an idea of the situation you found yourself in and what you did to solve your problem or successfully develop software, then I can take what your experience and apply it intelligently to my situation. But I’m not going to just follow blindly down a path that someone claims to have had success in when I don’t really know what issues they were facing, what their definition of success is, what kind of people they had, or what kind of software they were developing. That is what some “Agile” pushers are trying to get people to do and I’m trying to convince their potential victims not to abandon Agile, but to not fall prey to someone who is just trying to make money and will say anything to get them to adopt Agile, whether it suits them or not. pliantalliance.org comes down to “Think. Evaluate. Change” not “Follow, Follow, Follow, Pay, Pay, Pay”.

To the question, “…what percentage of people who claim to be ‘Agile’ developers actually have [applied agile practices]?” I have no answer. I have met people who call themselves agilists because they are in tune with the general idea of agility, and who have never applied agile practices. I don’t know how many such people there may be.

In my opinion one should not claim to be an agile practitioner unless one has rigorously applied a specific agile methodology, such as XP or Crystal Clear, in a disciplined way on at least one real-world project. Tinkering with various individual agile practices in isolation won’t give you a good feel for the style of work, since the effectiveness of an individual practice is influenced by all the other factors on a project. The specific practices defined by XP, for instance, are designed to complement each other such that the strengths of one practice offset the weaknesses of another. If you pull out one of the XP practices and apply it in the context of a project that has a different style of work, it may or may not add value. But doing it that way doesn’t tell you anything about whether “agile” or “XP” as such work well or not, because you haven’t actually applied “agile” or “XP” as such.

That’s not to say there are no individual practices at all that can’t add value in the context of other approaches to software development. Test-driven development is a good example of that. You can use that technique in the context of any methodology. It will have about the same cost and the same benefit in any case. It “costs” about 25% in terms of development time, and yields benefit by reducing design debt throughout the project so that you don’t end up in a death march. Exactly how TDD accomplishes that is well known. It’s not a question of guesswork. TDD was already known and used before the agile movement started, although it hasn’t been the most widely-used technique for building code.

“Do whatever works for you” is all well and good, but hard to quantify, share, or reproduce. Some of the techniques we associate with the word “agile” are well-proven in practice, and it seems a little silly to continually question their value as if we were living through a kind of Groundhog Day of IT methodologies, where every morning we wake up on Day One all over again, with no memory of what worked or didn’t work yesterday, or why it worked or didn’t work.

When something “works”, there are reasons why it works. I think there’s value in trying understand those reasons so that we can determine other circumstances when the same technique might also “work.” The phrase, “whatever works for you,” doesn’t give us even so much as a starting point to understand what might be worth a try in another organization or on another project. It’s more useful to have a clear definition of some technique, how to do it, under what conditions it delivers value, and how that value is generated. Then other people can consider whether that technique is worth a try on their own projects. That just seems more rational and practical to me.