The death of Agile
It’s a little disturbing seeing the agile crowd at work. In a relatively short period of time, an energetic group with potentially something new to offer has quickly sunk into a oft-derided group of greedy consultant used car salesman types.
I’ve spoken to a lot of people about this, I have yet to meet a single person who thinks agile, as sold by the agile crowd, is a good idea. I’ve ensured that everyone I spoke to had at least tried it, in some form or another. Pair programming, TDD, XP, little bits of paper, incremental releases, smug turdy devs, all experimented with and eventually discarded like a used tampon. Pair programming is inefficient and wasteful when compared to individuals who don’t slack off, the little cards more often than not end up with the wrong things scribbled on them, the incremental updates result in a big badly thought out ball of mud with no coherence, and the tests end up testing the wrong thing more often than not.
Is it possible to fix all that? Sure, but agile isn’t the way to do it, because the practices it espouses do not lend themselves to easy adoption. It’s a high barrier that continues to punish, and never rewards its participants beyond that air of smugness and that perplexing ‘I just shoved a big dildo up all my orifices and its strangely alluring’ look.
The reason for this disillusionment isn’t that hard to find. As many have noted, it’s rooted in the feeling of incredible disappointment when you realise that no time has been saved, your love life has not improved, and your customers are no happier when you follow this crap.
Genuine techies don’t react well to religion, usually. The agile crowd has committed the cardinal sin of stepping over the pragmatism line into the realm of faith. We’re surrounded now by the debris and detritus of less than successful agile projects. Instead of questioning the agile practices that might have contributed to the failure, agilists will instead scream out that the flaw is in the implementation, not the principles. Whatever happened to the scientific method? Why are the principles now held to be sacrosanct?
It’s that sort of attitude that makes normal people think that agilists are, on the whole, a bunch of greedy fuckheaded navelgazers more intent on group teenmasturbation than concern for fellow man. The irony of their very name is becoming apparent to all; there’s nothing agile about their thought processes or acceptance of external input. Either you’re with us, or you’re not doing agile ‘properly’, and you can hire us or attend our seminars for the cheap price of a few thousand dollars.
Just say no to agile. Say yes to sane practices that work for your particular need. In the real world, it’s not about doing either waterfall or agile, both are silly extremes that in practice never happen. The agilists initial point is well made, one should adapt and be prepared to think outside the box. Taking that advice in earnest involves discarding the modern day agilists and their newly discovered snake oil.
September 27th, 2006 at 4:00 pm
First!
September 27th, 2006 at 4:05 pm
Married life must not agree with you. This is a lame bile. Does she (he? – not that there’s anything wrong with that) not allow you to use too many “yucky” words/phrases anymore?
September 27th, 2006 at 4:33 pm
Seriously…the “death” of agile?
I can’t think of a time where agile software development has been more adopted successfully than now. Ever heard of “getting real” from 37 signals?
Ever since about 2001, agile practices have become pretty well accepted. You’re right on one thing though. We need fewer “ideologies” and more pragmatic implementation of “every” sofware development process.
I look forward to a more traditional “bile” entry next time…
September 27th, 2006 at 5:47 pm
this was not entertaining like other biles…:(
September 27th, 2006 at 7:00 pm
< < Genuine techies don't react well to religion, usually.>>
<>
So dead on target that … that … I can’t even drum up the hate to write something sarcastic. Kudos to the Bilemaster.
Ryan, it isn’t ‘ever since 2001′. It may be ‘ever since 1968′, when paired professionals desk-checked output at IBM, for instance. More likely, it’s ‘ever since we stopped eating the other ape-men’.
I think Hani has the clear vision this time. I too sense that we are seeing the crest of the little marketing ripple that sells Fragile nonsense. We could get some interest when we talked about Fragile for a while, but now nobody wants to spend valuable interview time on it.
Managers, unlike techies, DO appreciate religion – but there’s always a new one around the corner, and the old ones without much substance lose their interest after a while.
Onward and upward, and there’s much much more to sell before the old career comes to its disgraceful end …
Say, buddy, how’s the Grid coming in your neighborhood ?
September 27th, 2006 at 7:30 pm
While I’m normally aside you Hani poking fun at the ADD children (hiya Tirsen) and their magpie like attention span (oooh, bright shiny object), I’ll have to disagree.
While “A”gile is about as useful as “W”aterfall, a minor adjustment to “agile” gives much better benefits than I’ve ever seen before.
I’m working in a bank as a change agent, and managed to get a bunch of people writing high quality software applications using “sane practices that work”, leaving behind their craptastic previous efforts.
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.
Is this religion – no. Is this adoption of better more sane practices – yes. Is this “agile” – yes.
Is this “A”gile – no.
Take of this what you will.
September 27th, 2006 at 7:50 pm
I just come off a death march agile project that was just as Hani describes. The decision was made in the adminisphere that we would be AGILE. A consultant was brought in to make it happen. There could be no sensible variation to accomidate realities surrounding the project. There could be no sensible variation from agile even when it was desired by both the developers and the customers. The bottom line was that agile succeeded in making everything the fault of the developer. There are a lot of nice ideas in agile, and all of them are useful in the right environment, but blindly enforcing them all for the sake of being more agile than thou is to doom a project.
September 27th, 2006 at 8:37 pm
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!
You seem to be shitting on the methodology but present no conclusive evidence of how you come to this conclusion?!?
Why the heck are people using the words ‘enforce’ and ‘agile’ in the same sentence? If anything agile should be about getting something done using the right tool! If pair programming is the right tool use it, if TDD is the one to go then practice it, if model storming on a whiteboard is right for the situation then do that otherwise use rational rose or a piece of paper…
My favourite disillusion thus far regarding pair programming is, its inefficient! Oddly enough it only comes out of developer who feel they are too good!
September 27th, 2006 at 8:44 pm
Sorry a premature post… The one thing I agree with is “Say yes to sane practices that work for your particular need”. But in my experiences a huge amount of practices as defined by the agile methodologies (be it XP, SCRUM or what ever) are sane!
September 27th, 2006 at 8:49 pm
“There are a lot of nice ideas in agile, and all of them are useful in the right environment, but blindly enforcing them all for the sake of being more agile than thou is to doom a project.”
I’ve been reading lots about agile development lately. Ironically, the two books I like the most are “Balancing Agility and Discipline” and “Crystal Clear”. Both of them advocate a agile approach to agile processes, so you try one practice, see if it works, try another, see if that works with the first one, etc. And both talk about real and practical concerns, instead of idealistic fantasy projects.
Ultimately, I think there is no agile “process”, only agile people. You can follow any process you like and the magic ingredient is always going to be yourself and your coworkers.
September 27th, 2006 at 9:51 pm
Thank you Hani. The only thing to be religious about is religion, not development methodology.
September 27th, 2006 at 10:15 pm
A very brave posting!
The actual “agile” approach to development may very well be good, and it may have been rooted in good intentions, but it – like many other religions – has been warped and turned into a weapon to beat people with that defies all logic and argument. That has been proven in the comments already present in this very posting :)
I half expected someone to say you must be a terrorist because you don’t like agile, but luckily even soft developers aren’t that gullible..(mostly..)
Oh how comforting it must be to finally have a tangible thing to point at and say “this is how things should be for that which I don’t understand”. I don’t think it’ll ever change.
Thank you for being brave enough to say it. (it’s certainly easier than being mean to people individually )
September 27th, 2006 at 11:53 pm
Is something broken? I clicked on the Permalink and got a page with only comments, no original article. WTF?
September 27th, 2006 at 11:55 pm
Hm. So when I submitted that comment the correct page (article *plus* comments) came up and now the Permalink does the right thing. Weird.
September 28th, 2006 at 12:05 am
Speaking of bile, the mechanics of this site have already annoyed me twice more. First, the article has no link to the blog’s main page (hint: the very top, where it says “THE BILEBLOG”, would be a good place for such a link). Second, when I tried to go to the main page manually and incorrectly went to http://jroller.com/page, I got “Cannot Load Address Stopped loading: bad server response”. You call this an error page?
Anyway, (a) the content looks enjoyably bilious, so I’ve added it to my RSS feeds, and (b) I’ll shut up now.
September 28th, 2006 at 12:34 am
See also:
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
September 28th, 2006 at 1:40 am
Holy shit, thanks for the link Jason. That was an awesome read. I was already recently about reminiscing about missing similar experiences (but nothing near) to what he was talking about at an old company ….
I’m glad. I was beginning to think google was getting filled with zealot idiots when I saw the words “agile” in some of their job listings…Any notions I had of ever working there were pretty much permanently shattered until reading the posting you pointed out :)
September 28th, 2006 at 5:06 am
Weak bile. On the other hand, you’re clearly getting some. Congrats, if belated, on your marriage :)
September 28th, 2006 at 8:08 am
What a fuckwitted statement. Agile practices aren’t magic. They describe the findings and wisdom we have gathered during the last 40 years or so. Agile practices are nothing new – they have been tested in thousands of projects.
You just don’t understand what software development is all about.
And please don’t tell me good old waterfall is your way of working.
September 28th, 2006 at 10:37 am
Like your stuff Hani but, your off the mark here mate. One thing that separates agile from processes is just that – agile is a set of techniques borne out of the leftovers of what works in traditional methodologies. Anyone with waterfall process knowledge (most dev folks) would appreciate the freedom with which you can adopt/drop things with a simple metric ‘does it add value’? Even having daily standups versus weekly project meetings where information is a one-way diatribe anyway is a key part of agile ethos. Many of the agile tomes out there are testament to documenting approaches to delivering software that have at least worked in some context before. I can particularly recommend Crystal Clear in this respect which draws on the sucess (and failures) of agile techniques applied to a variety of projects and contains testamonials from different project staff members. 3 things hold true for me: access to SME’s, colocation and delivering software frequently. Simple enough but, how often do all three of these occur and projects succeed?
September 28th, 2006 at 11:40 am
Hani, how truely unoriginal as you so gallantly jump on the anti-agile bandwagon that’s been touring the blogosphere lately. Did you have a little circle-jerk with Cedric lately and get contaminated with his anti-agile germs?
Oh, and Mr. Scientific Method, where’s the research to prove that your (I Make The Shit Up As I Go) methodology works? You don’t fucking have any so stfu about that shit. Not to mention that testing methodologies using the scientific method is pretty much impossible (think on it for a moment with your pea-brain and you will understand).
Please give me a real reason why Agile sucks. Not some annecdotal BS story you heard from a guy who knows a guy who knows the guy who’s been butt-fucking your sister for the last year, but something from the Agile Manifesto that’s bad. Until then, shut your fucking ignorant pie hole.
September 28th, 2006 at 2:16 pm
Hani, you seem uncharacteristically dispassionate in this blog. Are you not feeling well? Perhaps an agilist put a drop of Kool-Ade in your Jolt when you weren’t looking? Maybe an agile jihadist is holding you at knife-point, threatening to disable the caplock key on your keyboard if you don’t take back the comment about navelgazing? What gives?
September 28th, 2006 at 4:12 pm
Agilists do have a knack for making money without really providing an answer. Hani++.
September 28th, 2006 at 9:36 pm
I’ve started pair tying-my-shoes also. It kicks ass.
September 28th, 2006 at 10:38 pm
lets face it – agile methodologies have been and always will be about consultants and money. big heaping gobs of money which big dumb companies pay to these agile consultants because big dump CIO’s and their minions think that the people who work for them are too retarded to figure it out themselves. The names change but the basic equation is always the same: big dumb companies hell-bent on mediocrity, and greedy self-promoting consultants waiting to suck them off.
September 29th, 2006 at 11:58 am
This bile so lame! Hani, you received death threats are what?
Agile? I can’t agree with you more! The agile crowd goes pretty much inline with other turd sellers like Spring, IoC containers, Pico Containers, AOP (or AO for JShit crowd).
Pair programming to increase productivity? My ass!
September 29th, 2006 at 3:04 pm
FUCK SHIT PISS!
September 29th, 2006 at 3:14 pm
With every new post Hani demonstrates he is of no value to the software community.
September 30th, 2006 at 4:45 am
<>
I wish I could agree with that. But unless you want to debate about what ‘Genuine’ means, I’d argue that many techies easily get hooked up on religion. Whether it’s SOA, IOC or Agile.
The problem with Agile is that it consists of a bunch of useful techniques, but that their usefulness depends on the context they are used in. In other words, they are good when used pragmatically. Sometimes they work, sometimes they don’t. Unfortunately, like Hani states, there are no such grey areas in the vocal part of the Agile community. You’re either Agile or you’re dumb dinosaur.
October 1st, 2006 at 3:54 pm
Judging and condamning Agile because of its zealots and greedy consultants is as stupid as judging the quality of a product by an add in a newspaper.
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…
October 2nd, 2006 at 2:59 am
Meaning of the word Agile
1. Characterized by quickness, lightness, and ease of movement; nimble.
2. Mentally quick or alert: an agile mind.
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.
October 2nd, 2006 at 12:05 pm
Problem I have seen over-and-over again when people “pragmatically” adopting any agile process is they are not skilled enough to understand the the consequences of their decisions on what they choose to include and what they choose to leave out. IME, all agile processes are highly sensitive to communication and feedback and most “pragmatic” adoptions of Agile processes almost always reduce communication and feedback. Without the levels of communication and feedback advocated by Agile processes, what you really have is just the status quo without the rigor of a design document, peer reviews, requirements analysis and structured testing. Basically, you have a big fucking mess.
October 2nd, 2006 at 3:43 pm
>> 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!
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.”
October 2nd, 2006 at 5:10 pm
Wow, just had to point out, once again, that the waterfall process works. The banking industry runs on software created using it.
>> 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 ?
October 3rd, 2006 at 2:03 pm
Right on the money. But it needs little more history and pshychological motivation;
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.
October 3rd, 2006 at 7:30 pm
So far the only really valid reason not to practice agile in any organisation discussed so far was “Problem is that most bosses don’t really accept the concept of agile”. I also agree with “Problem I have seen over-and-over again when people “pragmatically” adopting any agile process is they are not skilled enough to understand the the consequences of their decisions on what they choose to include and what they choose to leave out”.
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!
October 3rd, 2006 at 10:46 pm
What’s missing with all this “use this method” or “use that process” is that any methodology or process implemented by an inexperienced team will probably have problems. The focus on following a methodology is wrong. The focus should be on finding or developing people with the experience to manage a project.
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.
October 5th, 2006 at 11:10 pm
If only someone would drive a steak through the heart of Draxmla. Same tribe.
October 11th, 2006 at 4:13 pm
>his was not entertaining like other biles…:(
why, because he laugh about you?
October 12th, 2006 at 12:50 am
x
October 14th, 2006 at 7:55 am
Why the heck are people using the words ‘enforce’ and ‘agile’ in the same sentence? If anything agile should be about getting something done using the right tool! If pair programming is the right tool use it, if TDD is the one to go then practice it, if model storming on a whiteboard is right for the situation then do that otherwise use rational rose or a piece of paper…
October 19th, 2006 at 10:11 am
Ever since about 2001, agile practices have become pretty well accepted. You’re right on one thing though. We need fewer “ideologies” and more pragmatic implementation of “every” sofware development process…
October 19th, 2006 at 12:31 pm
To reply to Uncle Wiggly:
> 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.
October 20th, 2006 at 3:16 pm
I’m working in a bank as a change agent, and managed to get a bunch of people writing high quality software applications using “sane practices that work”, leaving behind their craptastic previous efforts.
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.
October 26th, 2006 at 2:44 pm
If we had JBoss and Geroimo as project managers we wouldn’t need methodogies. And then maybe those people at IBM DeveloperWorks woold publsih my articles. And possibly get the Indy Domain Name speculators to pay me adn corrrect oversttaed 1099s. But mainly getting Tomcat 6 running no Deian this weekend would help.
October 26th, 2007 at 12:41 pm
Agile does indeed suck, and so do all the cuntlicking consultants who sell it (I should know–I’m one of them). But what also sucks is people who say, “I already know everything about how to build software, and no one’s going to tell me that there might be a better way of doing things.” Software developers are an arrogant bunch, and posts like this one have are in some part written out of fear. I know it, I’ve seen it.
“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.”
April 15th, 2008 at 5:17 pm
It is interesting to see the the full time Agile Scrum PR consultants working over this blogg. I know them only to well :) I am not sure a pro 9 /11 blog would equal the level of blog commenting /vitriol featured on this blog. Keep the commonsense rolling on this Agile /Scrum rubbish. My issue with all this is not the fact that these PR consultants are earning fees or Agile signatories milk this crazy /sect for all it worth (I am consultant myself and we all want a new cardon’t we) its just the fact that this is a diversionary subject. We have 70 to 90 percent project failure rates thorughout the world which waste billions of dollars each year. Agile and Scrum is not the answer to this problem and is a small scale /small town attempt to make projects successful. The terrible truth is that we need to take lessons from the construction and engineering industry which has failure rates of 10% or less. Its not rocket science and certainly does not need a bunch of fee earning revolutionaires reinventing the wheel. Better stakeholder managment /project managment and structured planning and risk management might by part of the answer. Just ask a construction project manager.
March 31st, 2009 at 11:24 pm
Hi Agile fags. Agile is for suckers. Can i not go to work and wake up a moment before I SCRUM at 8am? FUUUUUUUUU….
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.
April 30th, 2009 at 9:41 am
Problem I think is ignorant twunts jumping on the agile bandwagon without any knowledge of what the fuck they are doing. Every time I ask for details on what the fuck we are meant to be building I get shown some ill-thought out system architecture diagram without any details. When I ask for clarification I get told ‘We are being agile, we will clarify that when we get to it’. When agile is being thrown around as an excuse not to have any idea on what the fuck we are meant to be building, how we are going to build it or even why we are building it you get the massive clusterfucks that pass for IT projects.
When ignorant pricks throw the word agile around to cover their own inadequacies and ignorance then agile methodlogy will be tarnished. In fact the methodology is n’t the issue it’s the fact that software development seems to be a magnet for small-minded, insecure little men who like to get their rocks off by sending emails with technical terms in to make themselves sound clever. When they actually face an issue in the real world or have to deliver something they shit their pants and start blaming processes and methologies to cover themselves.
You could give these fuckwits some beans and a tin-opener and they would starve to death while they argued about marshalling and unmarshalling their beans, synchronous vs asynchronous tin-opening work flows and the domain model of a bean.
Shit people build shit software whatever the methodology.