Agile will die, its just another fad. And yes agile evangilists are beyond smug…

Agile to me means you spend more time talking about patterns and practices than actually working, while putting project managers out of jobs. Doesnt surprise me since you are BETTER AT EVERYTHING THAN ANYONE ELSE. Including buttering hot dogs. Youre just better.

And yet, with all this agile todo tada bs, you still attack the author. Not that Im saying any blogger/twitterer writes about anything that isnt worthless crap that’s created just to get some traffic.

If you want to have a successful project, how about hiring the right people? How about not hiring the people that want to talk about what they are going to do, more than they want to work. The agilists ive come accross want to talk talk talk, and I want them to STFU. And then comes some ground breaking product (ahem) TWITTER. Seriously? If it were popular in 1995 I *might* understand.

Agile is BS. You know it is, but somehow it gives you some edge when dealing up new gigs with ignorant people with money to spend. Sooo anon software dicks…. What are you building today? A better twitter? Figures, you seem to like to follow people. There was a point that I thought software was an art, but all the artists left because they had to deal with some uptight fundamentalists. So and so said agile was good, so and so said some band was good, and someone said twitter was fantastic and will change the world. Yeh right.

Fuck 37 signals, Pair programming, TDD, XP, little bits of paper, incremental releases, and smug turdy devs…. The software industry has evolved into a bunch of pricks and I hope to never ever work with any of you righteous punks. Id rather starve or be in a shark attack. Fuck your ignorant metrics, fuck the company you work for, and… You’ll see, you fucking pompous assholes. You’ve ruined it for everyone… If i could punch you face I would, I’m so sick of this.

“I am too cowardly to admit that I have my head so far up my ass, and have kissed it so many times, that someone will point out that maybe I’m not be the greatest programmer ever.”

Most of the post is good. The bit about TDD testing the wrong things completely misunderstands anything about the practice, where it fits into software development, and how to do it right. Try posting out of something other than complete fucking ignorance next time. “I tried TDD for a day and I didn’t like it, so I gave up and decided to rip it instead.”

It just so happens that I can use the “agile” moniker (which makes it easier to talk about) and a sensible application of the practices to make it work.

> Wow, just had to point out, once again, that the waterfall process works. The banking industry runs on software created using it.

I’ve worked in the banking industry, and it is highly entertaining to see the terrible quality of the software (which as you rightly point out is mostly built using waterfall processes, or sometimes no process at all, and golf-course-ware). I’m always hearing (from other contractors) of messaging systems that died losing millions of dollars of transactions.

I’ve personally seen a craptastic analytics system that report results a few million pounds out here and there because of some obscure and complex stored procedure somewhere that grew organically without any tests to ensure that the latest feature / fix didn’t break anything.

I’ve seen agile projects in banks work fantastically well – and of course abysmally badly. But at least with the agile ones you have a test suite and well-factored code at the end of it so you have a chance of understanding and being able to change the system.

What every software project needs is a leader experienced enough in all the complex skills (technical, interpersonal etc…) who can instinctively tell what methods and tools will lead the project to success. This kind of person is hard to find – their knowledge is gained not just through training in the latest methodology but through experiencing successes and failures and the wisdom to know what causes either. They will not just stick slavishly to one process or another but know what to choose from what works from previous projects.

We must acknowledge that software projects are complicated and no process/methodology can really reduce that complexity. Only skilled and experienced project leaders applying their knowledge wisely can make a successful software project but then that isn’t always guaranteed. This is a fact of life.

I know, of course, that many software teams are stuck with the people they have, whether they are skilled and experienced or not, but that is always going to be the nature of the problem and the one that we need to address.

What these various methodologies can bring into play is that where experience and skill is lacking they can *suggest* ways forward that may not have previously been considered, but thinking that implementing any one slavishly will remove all problems is nearly always going to end in disappointment.

To summarise: Don’t slavishly focus on one methodology – study them all. All methodologies have something to offer, what is required is the skill and experience to know which parts of which methodology to apply at which time and how to apply them.

Other than that the other reasons say something along with lines of I don’t like this aspect of the agile approach or that. Well just don’t use that aspect. If you don’t like pairing don’t pair, don’t like index cards, don’t use them! Just because agilers say you either do everything or your not agile doesn’t mean you must do everything.

The agile unified process states that during the inception phase of sdlc you produce little documentation. I don’t agree with this and so during the inception phase I prefer to create detailed documentation of the domain model. Does this mean I don’t practice agile? Who really cares.

One post states their is no measure on the results of agile. There is a study on the benefits of pair programming (look for benefits of pair programming on the agile alliance website), which demonstrates how pairing can improve code – if you don’t believe it I don’t want to hear it JUST DON’T USE IT! Alternatively if you want a quantative measure of the agile process then simply incorporate something like the Six Sigma methodology into your business process this will measure results and you don’t have to wait for 10yrs to determine if you are successful. There is a article regarding the integration of six sigma with XP (www.sei.cmu.edu/cmmi/adoption/pdf/jarvis-gristock.pdf ). The way I see it is that you can use six sigma to measure the effectiveness of say pairing two individuals (measure the defect rates of two individuals). If these two particulary work poorly together then six sigma should pick this up and you should not allow it, althernatively if they work good together then pair them more frequently.

I’m just saying use what makes sense and don’t use what doesn’t!

The starting point of agile was that about %50 of IT projects were going bust as of 2001. The thought was something had to be changed, and that, according to Agilers, could only be through a MAJOR change. They figured customer/programmer relation was wrong. They figured we were coding all wrong. And here comes the new way of doing things. THE SOLUTION. The holy fucking grail. Take it or leave it, because we are all in a bad juju here. We’ve got to do something.

What we know now, we were not doing our old tried and true stuff RIGHT, but it took all the Agile hoopla for us to figure that out. Unit tests are fine, not in the amount Agilers want, but necessary nonetheless, but integration tests are more important. No little fucking cards, thank you, but let’s write this one nice document where everything is clearly stated.

In some ways, Agile buzz was great help. Agile did not put the emphasis integration tests, but it gave an emphasis on the word “testing”, so people are more focused on it now. They didn’t reach the right place, but they created an energy in some general direction.

They really put emphasis on “customers cannot decide on technical shit, and techies cannot decide about business shit” comment. This might come like no surprise to you, but imagine some shy, antisocial techie dude who somehow finds himeself in “customer interaction” mode where he has to contribute “definining requirements which effect technical requirements/technology” and is in a tight spot, with pressing deadline, and has a team to lead. Trust me, you want this guy to have heard some of the rules of thumbs that Beck talked about. XP, even deadly wrong on all aspects, was exactly right on mood, which in effect said a big FUCK YOU to all project management style that has defined the last 20 years. People do breathe down the necks of techies who don’t know how to say FUCK YOU like Beck did.

No I don’t like the little cards. No I don’t have an integration machine in my projects. But I do push people for more unit tests, and people do write them, thanks to the buzz that gave us TestNG (after crappy JUnit). I certainly do not write tests first, because my interfaces change as I write them, and I don’t want to waste valuable fucking typing time on things that do not offer functional code. Plus I am at a level where I can feel my way through the code without testing a function that has “one indentation level”, if you know what I mean… No I don’t mock. No I don’t pair-program, because if I liked people that much, I would be a fucking salesman. But it was good to hear communication is important, so I push people for more e-mail messages now, after every commit especially.

So, yes, I think the religion must die. But let’s not forget on the little goodies we got out of it, and the spirit.

>> CRAP CRAP CRAP! If you’ve tried to be agile in any project and come away thinking agile is not the way to go then plan and simple you implemented the agile methodology incorrectly in your project!

Right – prayer works, and if it does not work in your personal experience, then you must be praying in the wrong way.

Now, see, here IS a good idea : perhaps we can get the customer to blame himself for product failure. It works for the Pope, and it can work for software developers !

Rationality aside, the case for or against practice X can only be made to business with long-term financial results. We don’t have results for Fragile. (No, we don’t. I can counter each of your happy stories with a sad story. It’s like selling cars, isn’t it ?)

That’s not surprising : we don’t have really convincing financial results for anything else, either. I’m not even sure it is POSSIBLE to compare two approaches to software development – how can we account for the difference in teams, project, management, weather at the time of year the work was done, and so on ? All we can really do is wait for a decade or so and get an overall impression of an approach applied over many domains. So after a while we will get some idea of whether Fragile hoohah is really worthwhile … which we don’t have now.

Bu the way, for all you copcut artists outthere who want to say ‘it’s all just common sense !’ : cool. Call it common sense, then, stop trying to brand the communal common sense. Then I personally will hate you less.

And if that isn’t worth altering your world view and abandoning your self-interest, what is ?

Problem is that most bosses don’t really accept the concept of agile – meaning, ‘change your environment to one that works’, and instead like to point to things they see in books, websites etc, and say, see! we do that too. Agile to me means, “we’re holding you responsible because we’re giving you control, until we decide we don’t like what your decisions are, and then will arbitrarily change the rules.”

Hani I think there is some truth in what you say and some bullshit. Agile is horses for courses. Your arguments seem to be always all or nothing reminding me of George W.

Have a look around, nothing is good or bad in reality. Everything has a percentage of each – except in religion.

What is Agile about? See the Agile Manifesto! If this is dead – then Agile is dead and we should look for a different job – or do we want to waterfall again, for ever have clever managers force their headless goals/processes on us etc. etc.?

I’m certainly not interested in having management and consultants confiscate Agile – but calling it dead is abandoning them the field…