For the record, I don’t personally agree with everything they have decided on doing. For example, I’m still a big holdout on universal pair-programming. But my opinion doesn’t really matter. I’m not on their team. I really agree with some other things they are doing, like really emphasizing communication and knowledge transfer. But again, my agreement doesn’t really matter either. The point is, they’ve taken what the books said, spun in their own experience, mixed in their own current environment and voila…successful software development. It isn’t that hard.

Agile processes and tools have become very popular over the past few years. They promise success where many organizations have had failures. Concerned over struggles to “be agile” and worried that they are not doing everything that every agile consultant says they must, some organizations are worrying whether their projects are really agile or not. Is worrying about whether or not we are really agile the point? Are we, in our rush to be “agile,” losing sight of what’s really important? Shouldn’t our question be, “Are we creating software our customers value?” Jonathan Kohl focuses on understanding why we are developing software, for whom, and what our end users and team members value. It’s easy to get caught up with the newest trends and tools and measure our success based on their adoption, while forgetting about the basics. Jonathan helps you determine whether your tools and processes are helping you create value or if they are distracting you. Furthermore, if your processes and tools are helping you deliver software that your customers value, does it matter how “agile” you are?

Remember, it isn’t about how well you are doing a process. It is about how well your process is helping you build valuable software.

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.

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.

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.