pliantalliance.org

cdsmith has a good post on TDD specifically and any software technique/process where he discusses the tendency for some to convince themselves and others that a particularly popular technique/process is worth the effort (even though it may not be) by changing company policy to indicate they should have been doing things the hard way all along. That is, find a TLA (a three letter acronym) you like and change your environment so that the TLA makes sense even if that means it takes more effort because your environment truly doesn’t quite fit the TLA.

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….

I was pointed towards this talk given by Joe Rainsberger at the Agile 2007 conference a few weeks ago. The handout sums it up pretty well. Rainsberger is an experienced Agile coach and admitted Agile zealot. Given his good list of mistake examples, one is left wondering if he has ever been on a successful Agile project. And further, Rainsberger is a leader in the Agile movement and even he had trouble. What about the average Agile practitioner? Surely they must be having some problems too.

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.

I’m currently looking for a new contract and every time I see a job ad with the word “Agile” in it, I’m faced with a conundrum. I don’t really know what it means and as a result I’m not sure if I actually have Agile experience. I certainly have _agile_ experience and I’ve done lots of the things that make up what they call Agile development. Stuff like iterative development, TDD, pair programming, refactoring, continuous integration, working with user stories and backlogs, working with and developing coding standards, participating in stand-up meetings and retrospectives, being on self-organizing teams (with mixed results) and dealing with highly volatile requirements (not to mention customers). I have actually only been on one project that was a ‘by-the-book’ Scrum project, but that was only about 9 months of my 8 year career and for a good chunk of those 9 months I was on a team of 1 which seems to go against the whole idea of ‘Agile’. I’ve never been on a real XP project, though I’ve interviewed with a couple and had many second-hand conversations with people who have. I’ve read alot about Agile development and obviously written a bunch about it on this blog.

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’.

Brian Marick has been elected chair of the Agile Alliance and has an interesting proposal.

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.

What a great post, by an as yet unnamed (I couldn’t locate a name on the blog) software developer realizing that there are people moving on from Agile and he or she is not alone in identifying the “dogma drenched blather of Agilism”.

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.

JK has written a post-agilism faq which explains well all the things those of us moving past Agile have been talking about over the last couple of years. Post-agilism to me is the more general description for what I did in founding the pliantalliance.org. I moved past Agile and started to think about what was good about it and what wasn’t. I started encouraging others to do the same. It turns out that I wasn’t the only one doing this and Jonathan came along and coined the term ‘post-agilism’ to describe what we all were doing.

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’m not sure everyone actually gets the point of view those of us talking about pliant software development and post-agilism and the like are coming from. We aren’t starting a movement, we are describing one. We aren’t trying to change peoples’ minds, we are trying to get people to think about what they are doing and not just blindly accept what the latest “consultant” hired by head office to ‘revolutionize our software process’ is saying.

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.

Now that the March issue of Better Software Magazine is long out the door, I can post the pdf of the article I wrote for that issue.. The content was heavily based on some posts on this blog and the opportunity was a direct result of JK finding this site. So thanks goes out to him and +1 for blogging. I’ll probably blog more about the overall experience on my other blog at some point.