To quote cdsmith:

To be clear, I’m not saying TDD is a bad idea. I’m saying that competent software developers ought to make rational choices, by considering the advantages and disadvantages of things for a particular purpose. This is directly opposed to the idea that we ought to stack the deck by defining away the disadvantages and pretending they are good design that we just didn’t recognize until now.

What a great quote. Just for emphasis, I’m going to point out the particularly pliant sentence in that paragraph.

I’m saying that competent software developers ought to make rational choices, by considering the advantages and disadvantages of things for a particular purpose.

Ahhh…. rational thinking….

In his concluding paragraph, Rainsberger says:

In 2007 I realized that I had spent most of the XP-era of my career inadvertently, but consistently, forgetting about the people involved. I demonstrated this attitude by pushing ideas on them, believing the promise of XP over observing how people react to trying XP, emphasizing learning the practices over introducing what the team needs most, and perhaps most notably by assuming that everyone would be happier if they delivered software more effectively.

In short, he was apparently ignoring the context in which he was working. He was ignoring the impact that XP techniques were having on the project and the people he was forcing them on. Not surprisingly this led to some project failures. And now he is talking and writing about it. There may be some hope after all.

And yet, I still don’t know if I have Agile experience because I don’t know what it is. I hope the people writing the job ads realize that they may be missing out on a good chunk of the developer population when they require ‘Agile’ experience and don’t expand on what they mean by that. Of course I’ll still apply and if it turns out they want ‘Agile as in XP/Scrum’ experience, I’ll just turn tail and run. Here’s hoping they actually want ‘Agile as in adaptable, flexible problem solver using a large set of tools and experience to deliver customer value on accelerated schedules’.

I’m not really concerned with the actual proposal, since frankly, I think it is too late to de-hijack ‘Agile’ and anything they do will be for naught. What really interests me is the fact that the Agile Alliance (by electing Marick who ran on the platform of this proposal) has recognized that things aren’t completely hunky-dory in Agile land. Marick has a bunch of Whereas statements at the beginning of the proposal, but the one that sticks out for me is the following:

Whereas the number of people new to Agile who describe their project as “the best project I’ve ever worked on” seems to be declining, and we believe work should be joyful,

I could be my typical snide and sarcastic self and say something in mock shock and awe, but I’m going to resist this time and actually applaud this important recognition. Agile isn’t all it is cracked up to be. It doesn’t always produce successful projects. It doesn’t always produce happy programmers. It doesn’t always produce delighted customers. The sooner we realize this, the sooner we can move on, or in the case of the Agile Alliance, the sooner they can attempt to patch up the beast.

This should be interesting.

From the blog:

The bottom line is that Agilism had a few good ideas and might have been the wake up call that the software industry needed to shift our thinking a bit. It’s like the 1960’s. Here come the hippies with all their craziness and feel good nonsense but with a few good ideas. By the 80’s we could see how goofy it all was and even how some things were destructive but it helped change things and release us from stagnation. That’s how I view Agilism, a little goofy but with some good ideas.

I love it when another person agrees with me and all the rest.

To quote Jonathan:

There is no manifesto. This is not an organized group - it is a phenomenon of people around the world who have some sort of Agile experience, and have independently moved on.

I said it before and I’ll say it again… I don’t know how you should build your software. No one but you can figure that out.

What Agile has become is the exact opposite and _that_ is why it appears pliancy and post-agilism are explicitly anti-Agile. We aren’t anti-Agile, we’ve just moved on.

Some people however, _still_ can’t agree on what Agile is. They still think Agile is about the Agile Manifesto, when in reality, the book sellers and conference promoters moved on from the manifesto years ago. Agile (and every other ‘process’ being hawked to unsuspecting enterprises) is about selling stuff and if you can’t see that, then I can’t help you move on. Denying a problem doesn’t actually solve it.

He goes on to tell of how when he tried to share his experience with others, he was lectured by the Agilista about how yellow sticky notes are the only true way. Of his admonishers, Cockburn says:

Not that they’ve tried it, just that they’ve locked onto the opinion that yellow post-its are superior to everything else, and therefore to be used on all occasions.

But Cockburn goes on to talk about the bigger picture and the real problem.

I wouldn’t write about this if it was just post-its vs electronic capture. It is more general than that. I see my agile colleagues throwing their personal course-curriculum at clients rather than try to solve the clients problems; throwing Scrum training at them rather than …; throwing agile-in-general at them …; throwing 2-week iterations at them …; in general not thinking about what the client is ailing from before spouting generic agile rhetoric at them and lobbying agile-fad-of-the-day would-be solutions at them.

I wonder if comments like this from people the likes of Cockburn mean post-agilism and pliancy are crossing the chasm?

Another tenet of the Pliant Alliance has been to encourage continuous learning and improvement of the processes we use through the sharing of experience with each other. This may sound contradictory to the above, but it isn’t. In order to think, evaluate and change, we must have some idea of what others have had success with. You should _never_ take other peoples experience as a guarantee of your success, but stories of success from others give us ideas of where we can improve our own process and techniques. Combine that experience with actually thinking about our own contexts and we are approaching the right trajectory towards software development goodness.

Just because we don’t want to push any one technique on you, doesn’t mean we don’t have opinions. However, those opinions live elsewhere in the blogosphere. With the expectation that you’ll take our experience with a dose of thought and evaluation, here are some blogs you _might_ learn something from.

• Sesquipedalian Spew - my personal blog with tech and software development posts mixed in with other general stuff.
• Collaborative Software Testing - Jonathan Kohl explores software testing issues
• nlg(n) - David Benoit’s “thoughts on why software development is hard, why hard things are interesting, and why easy things are boring.”
• Solve The Real Problem - Brad Spencer’s thoughts on professional software development.

Enjoy.