pliantalliance.org

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.

I love it when luminaries in the industry start questioning things. JK passed this one on to me this morning. In the post, Alistair Cockburn describes how he facilitated a work session without yellow sticky notes *gasp*. He used mind-map software instead and apparently it worked great.

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?

It has been the policy of the Pliant Alliance to not recommend (or decry) any one particular technique or process to the world. We can’t possibly know enough about what others are doing, how they are doing it, the projects they are working on, the people they are working with or the company and clients they are working for to get anywhere near a useful recommendation. We do point out techniques that people are claiming to be the snake oil of the 21st century and usually attempt to discuss when/where those techniques may or may not work. We do get into arguments about recommending processes without much evidence. But most of all we attempt to encourage people to think, evaluate and change.

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.

This little quiz designed to measure your company’s agility just makes me cringe. It reduces the idea of ‘Agile’ to a few soundbites and gives the impression (once again) that there is a formula for ‘doing Agile’.

It’s like when your partner comes over with her copy of Cosmo and asks you to take a ‘relationship quiz’. You know only bad things can come out of it and no matter what you say, the quiz will get you into trouble. For the record, I am lucky enough to have a psychologist for a wife, and she recognizes that those Cosmo quizes are just pop-psych drivel. She doesn’t waste her own time on them, let alone mine. They don’t take into account the people involved in the relationship. They generalize issues (often poorly and based on popular myths in society) that couples may have and attempt to provide advice without the slightest bit of information about the people in the relationship, the current state of the relationship and the history of the relationship. So the ‘results’ of the quiz, if you can call them that, are utterly useless and insignificant if you are actually trying to improve your relationship.

There are no checklists, quizzes, formulas, blog posts, websites, books, seminars, pamphlets, conferences or anything else that can guarantee you success in software development. They all provide interesting ideas and give some ways that _may_ help, but they should all be taken with a giant grain of salt and a giant vat of analysis and thinking (the vat I believe is the standard international unit for analysis and thinking). There are _never_ any guarantees.