Agile is a Sham

While contrarian opinions are always valuable, this author is dangerously naive.

Hey BT, interesting thoughts. But I think his views on the business of certification and his thoughts about how some of the new methodologies basically work every one down to the lowest common denominator is an interesting thought. So what's so naive about what he's saying then?

I'm not going to say the whole agile thing is bunk, because it's not, but the commercial Agile being sold is pretty much BS. Agile is a methodology, not a process. Every time this comes up, whether online or in person, I always refer back to two key points on the Agile Manifesto (http://agilemanifesto.org/):
1. "Individuals and interactions over processes and tools"
Right there, if you're treating Agile like some sort of process, you're already doing it wrong. Having a process for sprints and when/how/where to have meetings is very much a tax, just like the author points out. It's nice that we have these 15 minute stand-up meetings, but I have stuff to do which I now have to stop doing to listen to people talk about crap that doesn't concerne me (I'm exaggerating slightly, but this is often how I feel during meetings).
2. "Responding to change over following a plan"
But, we're supposed to finish this sprint and we must have 95% test coverage before proceeding and...blah blah blah. Guess what, the customer says they now want this instead and they don't care about your unit tests. I'm not saying you can't write them, but I'm saying sticking to your plan is going to keep you from getting to your goal: shipping software.

I believe in the value of the Agile Manifesto; I try to follow it myself (when it's convenient ;-)), and the company I work for at my day job has been following it since they got started 15 years ago. The key thing is that they don't have a name for it, it's just how things get done. They didn't pay thousands of dollars for some schmuck who's never written a line of code let alone shipped a product to preach to them for a week.

So I don't think the author is dangerously naive, the arguments he's making can easily be applied to the waterfall development process. It was sold as the panacea that cures your development ailments just as Agile is being sold today.

The problem I have with it is that he's criticizing a project management methodology without acknowledging the problem space. Of course developers don't want any process imposed on them but 99% of the time that's not reality. Customers are finicky and rarely know what they actually want but they're also always right. If they never changed their minds and provided great requirements up front then there would seldom be a need for any kind of project management at all. Since that's obviously not the case, Agile is an attempt to refocus attention on the true goal of software development - delivery of a product that customers will want and use. It's absolutely being abused these days by charlatans who don't really know or care what they're talking about. That doesn't invalidate its need or its benefits.

By talking about growing processes "organically" (even if that does sounds like fluff), I think he is addressing it. I think the point he's trying to make, or at least the one I'm taking away, is that the process should mold to the developer or team, not the other way around. That's the part that is taxing and is what he seems to not like about "the management pitch" of agile as he puts it.

I will disagree with your point about the customer always being right. A team can't perpetually change the product as the wind blows, simply because that's how easily the client changes their mind. I've dealt with clients like that, and it takes a good project manager, as you've mentioned, to know when to say no as well as when to say yes. Sometimes the client knows what they want their software to do (or maybe what they want that day), but not how it can best help them do their job/serve them.

I agree with your statements about Agile's goals, I think that the author probably would too, and I think those charlatans, misguided middle management types, and the crap they shove down are throats they call agile are what he's raging against.

Really Drew, you shouldn't talk about working with me on DNK like that :-)

Ha ha, trust me Bob, I'm definitely not talking about you ;-)

Because I think in large corporations the problem is that organizational structure, individual competency, and the communications skills of both the programmers and the rest of the team play a massive factor in projects and what a nightmare they can be to be involved in.

As one of my friends said 'I did contracting work as long as I could withstand how soul sucking it was. And then I had a take a break.'

That's a good point, Bob. It brings me back to my point about the process molding to the team: I tried to get weekly code reviews going as part of our "process". Each dev would show off what they'd been working on that week and talk briefly about it. The idea being that if there were any issues with the design, or if the developer needed help, the many eyes in the room could help work out the kinks. It seemed great in theory, and the first show-and-tell came and went with only myself presenting. I could have forced the issue, and asked the team lead at the time to make them mandatory, but that would have been molding the team to the process. It would have wasted time and effort.

Drew, upon rereading the piece I think I see what you're saying. I blew past this statement near the beginning: "The management pitch is that by getting programmers to follow some process rote you will get good, predictable results out." I think the rather, erm, aggressive terminology he chooses played into my expectations of what would follow. I agree with what you've said! I'm definitely looking at this through the prism of a developer who's been on both wildly successful Agile projects and Bataan-level waterfall death marches, and I'm probably a little touchy about Agile detractors since (proper) training is a big part of our business. :)

BigTuna, cool :-)
I also respect teams who follow a well laid out Agile process and thrive as a result; like I mentioned to Bob in my story about code reviews, I wish I could bring more of those facets into our teams. The main problem with all of this is the zealotry (Agile is/is not a sham, etc). I really liked the Steve Yegge post that this article linked to, it's IMO a more refined and carefully worded version of what the author is getting at.

This article could really be pointed in the direction of any development methodology, not just specifically agile. Everyone will have a personal opinion on one life cycle to the next depending on what has worked best for them in the past. It is true, however, that depending on the team you have, your results will vary. If any one area is lacking either in skill or effort, results will be skewed regardless of how much you try to plan for it. Just because one methodology has worked for Microsoft, thus they plug it, does not make it any less useful than any other methodology.