pliantalliance.org

The Register has named “Agile” one of the most overused phrases of 2008. Along with “the cloud”, “web 2.0″ and others, “Agile” was deemed to have been “so overused and misapplied during the last 12 months that they began to lose their meaning”.

Here’s the excerpt on “Agile”:

Agile software development methodologies are finally gaining the purchase they deserve in enterprise development shops, but the term “agile” was so overused that the agilistos were all but driven to capitalize references to Agile methods. “Agile modeling” is a legitimate expansion of the term, to be sure, but how about “agile enterprise management” and “agile project management?” It seems as though every business application now guarantees to create an “agile enterprise.” Online advertisers are encouraged to practice “agile marketing.” We now have “agile infrastructures” and “agile service oriented architectures”, “agile platforms” and “agile consulting” ,”agile testing” and even “agile IT”. What we need is an agile editor with an agile red pen.

First of all, yes, it has been over a year since I posted here. The main reason is that I had more important things to adjust to, namely, having a toddler running around the house and moving my family 1000km into the cold of southern Manitoba. Aside from that, I basically just stopped caring about the debate. It just didn’t/doesn’t matter to me anymore. The people who would get and appreciate my point of view had gotten it and everyone else was too mired in their dogma to understand what we were saying. Essentially, I moved on.

So what, you might ask, has brought me out of my pliant slumber? What could possibly make me care, now more than a year after I stopped caring and especially now that I’ve transitioned, (dare I say, “adjusted”) to part-time software developer? The answer is Luke Halliwell.

Luke Halliwell is my new hero. In one post he manages to sum up what I and others have been saying about the Agile movement all along. Namely, that it is all hype and common sense. And he does it with better, more entertaining writing then I ever did.

The whole post is, as my colleague put it, “SOLID GOLD”. But here are a few particularly golden points:

On Agile:

I’m sick of it. I can’t wait for the day when everyone realises how much of a fad-diet, religious-cult-inspired, money-making exercise it is for a group of consultants.

On methodology:

Firstly, beware following any kind of methodology. All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality. But in software, they’re fundamentally designed for mediocre developers who can’t think for themselves.

On people:

“Individuals and interactions over processes and tools” I couldn’t agree more with, but strangely, Agile is all about following processes and rarely mentions that having top people is the best thing you can ever do for a project (you could say your hiring process is more important than your development process!)

On hype:

The hype really annoys me! There are decent parts to Agile, but they’re just common sense. They don’t need a movement or a manifesto behind them, and they don’t need stupid terminology. I don’t see why I should have to call a colleague a “Scrum Master” and keep a straight face.

On daily stand-ups:

Having daily stand-up meetings is ludicrous; it exists simply to protect against the dysfunction of team members that never talk to one another. The Scrum literature goes on about how great it is that people can’t be blocked by anything for more than a day because of these meetings. In anything resembling a normal, common-sense team, people will surely raise blockages with their manager as soon as they occur and not need to wait for a daily meeting!

On scrum:

There is literally nothing here of any interest to me. It’s a bunch of common sense (sometimes bordering on banal) stuff, with some very arbitrary decisions made for you on things like meeting frequencies, and some really stupid terminology. I don’t see how it benefits anyone but the worst of teams, and they have bigger problems.

Gold, gold, gold, gold, gold and gold. Luke has hit the nail on the head and hopefully the games industry will be better for it. At least, I’m sure, his company will be better for it.

I’m not sure if Luke’s post will get me off my duff and make me post more here. I may as well just redirect pliantalliance.org to Luke’s article and be done with it.

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.