Agile: 5 years later and you're still doing it wrong | Hacker News Reader

Agile: 5 years later and you're still doing it wrong

steve-yegge.blogspot.com

215 pointsghc77 comments

Yegge, as usual, is hyperbole and a half. Don't get me wrong, I like his writing. I liked it more when I was younger, but I still enjoy it.

I have to say though, after working the last 3.5 years in an organization that Yegge would categorize flatly in Bad Agile, first as a developer and now as a PM, that I disagree. Plainly, his hyperbole and name calling doesn't open up for a constructive debate but I'll give it a try.

We do iterations, retrospectives and kaizen, automated testing (yes, part of XP), user stories and more. A few people practice TDD or pair programming. Importantly, all of this is voluntary - after five years of experimenting with process, tools, methodology we've found a set of things that work for us and help us deliver software with high quality and on time. It just happens that the tools we use fit in the Agile and XP umbrella. And if we look back five years to the pre-agile days and start looking at delivery times, quality (in terms of defect rates, patch releases, …) and customer satisfaction, they've trended continuously upwards and in a big way.

I'm not sure what we're doing wrong and why, and I'd like to have that explained to me.

I'll offer my 6am reasoning-by-analogy commentary in a slightly inflammatory style to keep the mood. Your third paragraph, if you change all the keywords, looks like something a converted Scientologist might say! All your friends tell you it's stupid and give you reasons why you should be unhappy ("Look at how much money you're giving them!") and so forth, but by golly, you look back at your life just a few years ago and things seem so much better now! You don't feel like you're doing anything wrong, and by objective accounts if you're genuinely happier you probably aren't doing anything wrong in the grand scheme of things. Why wouldn't you feel good supporting your Church with huge sums of your income anyway?

In short, the brainwashing worked and you're under the influence of a beneficial placebo effect. Maybe the placebo effect is what explains the 10% "success stories" of not-screwed-up Agile Teams that Yegge hints at.

Or not. I don't know. I do know that for me any productivity hacks are temporary at best and ineffectual by default, and I'm wary of ones that have been actively dangerous for a good number of people; when akrasia is solved in general humanity will rejoice...

Unlike "genuine happiness", things like delivery times, defect rates, and numbers of patches seem concrete and easily measurable. (I left customer satisfaction out, but for all I know companies have objective ways to measure this as well.)

Ok but I believe the burden of proof is on you. I'll claim that adhering to some principles has given us quantifiably better results, and that the time scale is long enough that any Hawthrone Effect would've worn out by now.

Also, "productivity hack" is not a label I'd use to describe e.g. automated testing. YMMV.

My personal theory on XP, and to a lesser extent Agile, is that about 90%, if not 120%, of the benefit is in the pervasive use of automated testing, and the rest is either marginal in comparison, or even harmful but propped up by the benefit you scored by using automated testing so it all looks net positive in the end. (Hence the 120%; the benefit of just using automated testing is indeed greater than the whole package.)

I can't prove it. And I do like iterations in the sense of "produce a deliverable product every N weeks" for keeping you from wandering too far down the wrong path, though from what I've seen one of the most popular things to do with agile is just break your calender up by "iterations" then keep doing the same thing you did before. It's sort of hard to get a real sense of the utility of agile because hardly anybody really seems to really try it. (I do not necessarily think every aspect of it should be kept, but much of what it proposes is at least worth a real try. And "trying" shouldn't be a matter of smearing new words over the same procedures.)

Actually, the burden of proof should be on you. The null hypothesis is that adhering to agile principles has no positive affect on the outcome of software projects. In order to show that these principles have worth, you should disprove the null hypothesis.

I disagree. I've laid out my arguments best as I can, pointing to how we've measured and that we've seen improvements. In response to that, the commenter compares the post to scientology.

The hypothesis under discussion here isn't "these principles have value", it's "even though implementing these principles gave measurable value, they're still snake oil comparable to scientology".

In the past six years or so since this was written, Greg Wilson has advocated gathering data on this and other programming related topics (watch http://vimeo.com/9270320 if you have an hour, or get a flavor for the arguments here http://blog.stackoverflow.com/2011/06/se-podcast-09/), and has compiled a book of essays (with research) on the topic: http://www.amazon.com/Making-Software-Really-Believe-ebook/d...

I haven't yet read the book, and so don't know it's conclusions, if any, on the various methodologies, but if you're curious about research in the area it would be a great start.

The other thing worth pointing out is that, while the Google Yegge describes in the essay might be different in 2012 than it was in 2006, it's still a different level of organization than even the average software development company, let alone a non-software company that happens to employ internal or contract developers. And Steve is writing about developing within Google.

Thanks, but I've seen Gregs talk and the book has been on my short list for a while. I whole heartedly agree with trying to bring some science to the table. However, in lieu of any research on the subject and given the tools at our disposal right now, we can only look at the metrics we have and draw conclusions from them.

Also, I disagree that Yegge discusses Google in particular. Sure, he blabbers on about how great Google is, but he dismisses agile methods outright. FWIW, the Googlers I know don't tell the same rosy picture about the place. What Google is seems to vary quite a bit with where you are and on what project.

As an enterprise developer (i.e. one of the guys working in the big, non-technical companies) I have been one to advocate and implement parts of agile on various projects. I will fully admit that Agile is mostly hype and that adhering closely to any methodology is mostly, if not entirely, futile.

Steve and others are missing the point, when done right it forces conversation and it gives programmers a voice. In big non-technical companies everything is top-down, date-centric and programmers are just cogs. When we did agile, we essentially had some basic sprinting (make date people happy) and a strong feedback loop (give developers a voice after each sprint) and those two simple steps produced some amazing work.

Dates will never go away in these kinds of companies, programmers will never be first class citizens, and some sort of process will always be demanded. Agile is not about how to get developers to be more efficient, it is about getting large non-technical organizations to bend (ever so slightly) to the will of the people actually producing the work.

This is exactly the environment that agile is designed for. It's oriented around getting to a state of producing results in teams with low cohesion, poor communication, and ineffectual or non-technical management. The problem is that people see agile as a one size fits all solution and try to shoehorn it into situations where it's not helpful. Even worse when people misapply the core concepts and it becomes just another excuse for micro-managing.

I think there's a lot of truth in this (though as with all opinion pieces, esp. seriously entertaining ones like Stevey's, you have to take it with several pinches of salt).

I have a suspicion that a lot of agile is a hack designed for managers who have problems within their team and don't want to deal with them properly.

It's far easier to adopt a 'proven' methodology than confront the fact that Frank in accounts has unrealistic expectations and changes their already vague spec 30 times while expecting the estimate not to change, or that Peter is driving down morale in the team by nitpicking every last mistake you make while ignoring his own, or the constant denial of the impossibility of actually consistently correctly estimating tasks which have never been done before by anyone.

Dealing with those things well takes real skill, patience + awareness as well as a willingness to accept reality and eschew politics, and that's just hard.

What I particularly dislike about agile is the unfalsifiable dogma of it - you MUST do it like this otherwise it won't work and it will be YOUR fault for not having done it properly. If it works then of course it's all agile. That's a big problem - everything you do in a team should be for reasons and open to discussion otherwise you end up with cargo cult programming and cargo cult software management.

All that said, if you take agile not as a dogma but a series of methods that people have found useful and adopt it to your needs, while not avoiding the realities of the situation, then I can see how it can provide prompts for improving a team.

The original agile manifesto was definitely not a dogma.

If someone presents it as such today, you can usually follow the money pretty easily to figure out why.

God yes - While working at a large bank I once saw an Agile consultant give a presentation to us. His words: "We find that when teams aren't succeeding with agile it is because they had only adopted some of the agile processes instead of all of it and that hadn't been trained properly by an expert "

I threw up a little.

This is PRECISELY what you hear from folks who are trying to sell you religion, or stuff like EST.

"Of course it's not working, you're not doing it right. We'd be happy to work with you some more on that."

Followed by the "ka-Ching!" as they cash your check for the consultancy.

Agile is so often turned into a micromanager's paradise that I've just stopped involving myself in it. Our team holds scrums, none of the engineers show up. It's pathetic.

You'll hear the same thing about any difficult discipline. Surgery, painting, programming, auto repair, biological experiments, chemistry, mechanical engineering, and so on.

Yeah, the "trained properly by an expert" is a bit of a giveaway, isn't it?

That said, I've worked in a scrum team and most of our issues were caused by not following the common sense stuff in scrum, things like "don't change the spec halfway through" or "have a clearly specified story".

Exactly. In it's original form, there is essentially nothing dogmatic about Agile. That was basically the very point behind it... to focus on core principles, not dogmatic allegiance to certain procedures and processes.

Very true. However, if you are going to pick and choose. Please, please, please, start with communication. Unsurprisingly, I don't know what to build for you if you can't tell me what you need. Face to face communication is the cheapest, most efficient form. Documentation, the most wasteful and expensive.

This isn't about agile. This isn't about methodologies. It's about one basic principle that's true in every industry, for any and every management system:

PROCESS IS NOT A SUBSTITUTE FOR LEADERSHIP.

No set of rules can compensate for bad management and employees. Rules usually empower bad managers and disguise bad employees. No methodology -- agile or otherwise -- can stand up to bad execs, bad project leads and/or bad coders.

It starts with hiring. That's how Google gets away with loose rules -- they prioritize hiring "Google-level" coders and managers. All else is details.

> PROCESS IS NOT A SUBSTITUTE FOR LEADERSHIP.

Choice quote, though you're quoting yourself. :) Your original write up "enough with the meetings are toxic" was a nice read from 2006 too! http://goo.gl/U9Ysi

WOW, I had NO IDEA that was still out there. I guess nothing ever dies on the internet.

TL;DR Google is awesome. Agile is bad and stupid and for stupid people, but when Google does it it's great, because Google can do no wrong and is NOT EVIL and did I mention awesome?

I agree that "Methodologies" with a capital M are probably a scam, and that Google is probably full of super-smart developers that do fantastic work when left to their own devices — but I knew that already...

I think that's the key piece. Yes, Google can operate the way they do because they have world class talent. Literally some of the best developers in the world. If you find yourself in that situation, then yes, you too can do things the way Google does.

Being a contractor and working in the bowels of Fortune 500 software divisions has taught me that this is a pipe dream for almost every other company. The methodologies (Agile, Waterfall, whatever) were no doubt created in order to help teams of poor to middling developers actually accomplish something while fighting through the corporate red tape and their own stagnation.

I've seen the kind of "Bad Agile" he talks about work at big inflexible organizations, and I've seen the "let everyone work on what they want" style of development go catastrophically wrong. Yegge's post seems to be more about him congratulating himself on how awesome he is for working at Google.

It's not just about the level of talent but about what Google can afford to do. Google banks so much cash from search advertising that it can bankroll all of these other internal projects that might not impact revenue at all, and their cashflow and stock price is so high that no one is stressed about costs or deadlines. As Mel Brooks's said, it's good to be the king. If Google was pressured by competitors and falling stock prices you would quickly see the whole picture revert to the traditional management-says-get-this-shit-done-now project management.

TL;DR If you have billions in cash in the bank you can pay armies of engineers to work on whatever fancies them and deliver it whenever they feel like it. Who needs Agile? Burn your calendar. Party on.

As the article touches on, Agile discussions seem to often rely on the "No True Scotsman" fallacy -- if it doesn't work, it wasn't really Agile, so the definition becomes slippery enough to evade a lot of criticism.

I think that, because of this, trying to push the umbrella term "Agile" makes it more difficult to evaluate the sum of the ideas than if you were to evaluate each idea on its own merit. Each person can claim some permutation of the sum parts (and even add some more), and assign them the title of "true Agile".

It's something I saw when I was going through SOA training for work as well. There's those that swear that heavy contracts are required for "true" SOA, and REST can't provide those. And there's those who swear the focus should be on the "service oriented" aspect without all the SOAP overhead, and that core is the "true" SOA. Personally, I try to avoid using the term "SOA" now and just stick to the technical description of what I'm talking about.. hell, I'm almost afraid to put it on my resume.

This is how my previous company (a great bunch) implemented SCRUM. My CEO came to me and asked me this:

"Thomas, we want to increase our revenue so we need to differenciate ourselves from other consulting firms. We need our services to be top-notch. Our customers don't know anything about Agility and processes such as SCRUM but I think I can sell them that. What can you guys do to help sell this?"

To which I suggested: "we can pretend we're doing a variant of SCRUM and label it '{{nameofcompany}}scrum'. I think a board in the middle of the openspace with neatly arranged coloured post-its will do the trick."

He said: "Great, thanks", then proceeded to increase our average daily rate by 20%.

Once a cowboy, always a cowboy... Oh and by the way, it worked.

Agility, as in the Agile Manifesto, simply works on its own. It might not define good practices, but at least it defines a set of good intentions and it's a working strategy that's simple to explain to team members. Everything around is nothing but ways to make more money, not ways to make projects work. My philosophy would be to sign the Manifesto (because it's good) and pretend to implement one of those methodologies (because it's cash), while you keep doing your job well in the way that best suits you (because that's what makes you happy).

A detail: Scrum is not an acronym but a name derived from a rugby term, it should not be written SCRUM but just Scrum.

(Great story otherwise)

From my experience with Agile, I believe that most companies do it wrong. I know my company does. But it helped us dig 2 projects out of the never-ending abyss of scope creep and constant end-user changes when we converted to Scrum. So when I hear "you're doing Agile wrong" it makes no sense to me. You make what you can out of it. You mold it to fit your practices. It will most likely never work for you out of the box and it takes time... it just does.

Honestly, I didn't even get to the end of the article and stopped soon the author started glamorizing Googlers. I was more offended with "Google does it right and you're wrong" and calling everyone in the world stupid than by the author rendering the whole Agile practice useless.

Amen to what Steve says about a work queue. I've been in environments where, more than once, a dialogue with my manager would go like this:

Me: "My to-do list is empty."

Manager: "Oh, umm, let's have a meeting to talk about that... [consults calendar...] the day after tomorrow." Or even: "Yeah, I know, I'm still looking for something for you to do."

Now, if I had cast-iron balls, or an amulet that gave me a +5 bonus on my saving throw versus layoffs, I would respond to that with "OK, I'll just stay home tomorrow and check email on my laptop every few hours, just in case something comes up." But that's not how the game is played, of course.

Since late October (end of previous release) I've been mostly doing make-work: test scripts, some individual investigation, reading up on standards. Why? Because upper management haven't decided what is going into the next release. I've finally given up trying to get answers and I've made the decision myself. Any direction is better than no direction.

And the bizarre thing is they are totally obsessed with "keeping the sales pipeline full" but can't see that the same can apply to development. No doubt someone will make a decision in a while and we'll be under severe pressure to catch up on the lost months.

Do you have enough maneuvering room to implement your own idea? For example, if "keeping the sales pipeline full" is priority one at your company, can you interview some salespeople and apply your software skills to removing a sales pipeline constraint? If you could solve one bottleneck (see Theory of Constraints, The Goal, etc.), possibly just a small piece of work for you, it might have great leverage to the sales department, and then you would have much more freedom and respect in The Enterprise.

Yeah, and maybe you could get a pony.

If you consider writing test scripts "make work" you're really wasting an opportunity.

I wasn't very clear: the test scripts were to see if I could provide a unit test framework for the internal scripting language (not actual product tests which are obviously a productive part of development). It's interesting to me (which is why I did it) but since it won't ever reach a customer it's basically just to fill my time

First, this is a five-year-old article. And a dupe.

Second, let's get definitions straight. Agile is best practices around iterative and incremental development. The word is a marketing term and can cover all sorts of different (and contradictory) concepts. Scrum is a certified way to manage Agile projects. You write a check, there's a board, a class, and a nice little certificate you get.

So it's really hard to jump up and down and yell too much about "Agile" -- the term is just too slippery. (I note he includes a picture of a ScrumMaster class) Or to put another way: ten years ago companies hired me because I was really good at running iterative and incremental projects and could not only do it well, but help train project managers and teams. Now the same companies hire me for the same reasons, but the word "Agile" is attached. If you want to slam all external consulting as being a waste of money, that's fine, but let's be clear what you're ranting about.

Second, because it's best practices, not all of them are going to work for you. And as you grow, you'll find out how to use some (and ignore others). Hell, I'm still struggling with TDD. But I grok pair-programming: it's the same kind of coding you did in college where a couple of people would sit around figuring out a problem. It combines the code review and the code creation into one step -- brings the review as far forward as possible, so there's no wait. Would I do pair programming all the time? Shit no, but does that mean I should make fun of it? Not unless I want to sound like an idiot in ten year's time.

The biggest point to be made here is that Agile adoption is not the same as Agile principles. Agile adoption sucks -- it's full of zealots, religious wars, highly-priced seminars, and feel-good happy talk. It can be just another way for management to micro-manage your project. The terms can mean different things to different people. Consultants make lots of money and provide very little value. And so on. Trust me, I know this: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-...

But all of that is just a study in how screwed up most organizations and movements are. Agile as a set of best practices is awesome. If I want to learn about data modeling, I'm buying some kind of book with a title like "Agile data modeling" because I know it's going to have an incremental and iterative context -- I won't have to do as much mental gymnastics to fit it into what I'm doing. (Disclaimer/shameless plug: I just published the first in a series of e-books to try to teach people without them having to pay so much for consulting. http://tiny-giant-books.com/scrummaster.htm)

Agile adoption has generated a lot of hate. That's a shame, because as Steve points out, there's good in there too. (Although he's not hitting on a lot here, the article is nicely done)

" "Agile" -- the term is just too slippery".

Well you can point to the manifesto. A statement of 4 core values. That is all it really is.

I agree with you on the "Agile adoption sucks" bit. I think the coders and even managers have abandoned that crowd long ago, leaving the conferences full of coaches and consultants free to waffle on about fluffy ways to communicate and argue about whether the complexity model is better than the systems model or something.

It has been hijacked, and it is now a racket.

> First, this is a five-year-old article. And a dupe.

I believe this is why the title is "...5 years later and you're still doing it wrong". It's probably worth discussing why things haven't really changed in the past 5 years regarding this.

The article is dated 2006. I doubt there are many relevant lessons to take away from a discussion of Agile circa 2002-2006.

edit: relevant for historical reasons, but less so for 2012, which is what I thought when I read it. [2006] on the title would be helpful.

The title was confusing. I thought it was a new article, looking back over 5 years, not a 5 year old article.

oh no it's not worth discussing. The discussion is pointless including Yegge's diatribe. Great software is written by great software engineers. (period) end of story. And there is no amount of management that can be thrown in that can make sucky programmers better at their job.

Disclaimer/shameless plug: I just published the first in a series of e-books to try to teach people without them having to pay so much for consulting

Interesting testimonials. :)

http://tiny-giant-books.com/agile-adoption.htm#testimonials

We get a lot of Romans. Who knew the Romans were so into Agile? :)

It's a year-long project. One book down, several to go. Wasn't really sure what to do with the other pages.

YAGNI :)

When I hear the term "Agile" I think of no more or less than the principles from the Agile Manifesto. http://agilemanifesto.org/

I know some people translate "Agile" to a specific instance of Agile (Scrum, XP, Crystal, what-have-you) but I feel like that's a mistake. If somebody wants to criticize Scrum, I wish they'd criticize Scrum directly, not "Agile." Same for Crystal or XP or whatever.

Would I do pair programming all the time? Shit no, but does that mean I should make fun of it? Not unless I want to sound like an idiot in ten year's time.

Or, if you're anything like Steve Yegge, if you like engaging a lot of hyperbole to "stir the pot" and elicit discussion, or to make a point. I don't know if you read a lot of Steve's stuff or not, but his writing style is often loaded with hyperbole and is somewhat inflammatory.

Agile adoption has generated a lot of hate. That's a shame, because as Steve points out, there's good in there too. (Although he's not hitting on a lot here, the article is nicely done)

The thing with Steve is, you have to look beyond a lot of the specific things he says, and try to generalize to the overall point. That's not always easy and not everybody gets it. I know this well, as I tend to use a lot of hyperbole as well, and I often find people get hung up on the details and skip the more abstract bits. Whether using that style or not is a Good Thing is an exercise left for the reader. :~)

> Second, let's get definitions straight. Agile is best practices around iterative and incremental development.

When I read this, I thought, "this guy is selling something".

> It combines the code review and the code creation into one step -- brings the review as far forward as possible, so there's no wait.

The only programmers I know who half-heartedly believe that are trying to convince themselves of it in order to sell pairing to pointy-haired bosses. Two things cannot become one thing, if they are meaningful. If you make them one thing, it's because they aren't meaningful to you. In this case it's peer review, and I don't want what you're selling.

Two things cannot become one thing, if they are meaningful.

My understanding of it is that the intention isn't to combine the two things, it is to interlace them so the feedback loop between them is as tight and short as possible.

Note: I don't really care for pair programming except in short bursts.

This reminded me of the keynote Andy Hunt gave at Ruby Midwest last year entitled "Agility Undefined - Becoming Uncomfortable with Agile". Here's a video of it, for those who missed this awesome conference:

http://www.confreaks.com/videos/770-rubymidwest2011-keynote

Back in Ye Olden Dayes, most companies approached software development as follows:
- hire a bunch of engineers, then hire more. - dream up a project. - set a date for when they want it launched. - put some engineers on it. - whip them until they're either dead or it's launched. or both. - throw a cheap-ass pathetic little party, maybe. This step is optional. - then start over.

Thank goodness that doesn't happen at your company, eh now? Whew!

Actually, that describes my company to a T. I think its more to do with working for a manufacturer, since my company is technical, and working in defense.

Oh, and in our case, "start over" means "find something we did in the past that is kinda sorta like what we need to do now and force fit it to the problem as quickly as possible".

Agile techniques make good teams perform better. Scrum makes it impossible to hide from problems for more than a month. It doesn't solve the problems for you. Scrum makes failures faster so that errors are minor mistakes instead of yearlong catastrophes. Scrum is not micromanaging, it explicitly empowers the contributing team members to manage themselves and each other. No one ever sold agile as a way to make bad teams perform well. I have seen Scrum (as practiced by a team that read a short book and sat in a one day training and bought in to it with an open mind) make made my team deliver better work in a more satisfying way.

Cool article but I'd just like to know why stand-ups have to be in the morning when I'm still getting into the groove of things. Why not end of day, all day you're waking up and building to that brief stand-up and it's either hey I need help or hey look what I/we got done.

For that matter what if people have a good medical reason for not standing, does that mean stand-ups are an implicit form of discrimination against older coders?

I like the part about modeling work tasking on priority queues. I use org-mode a lot and having a few org-mode (Emacs package) files like priority1 and priority2 and manually keep the most important stuff at the top would work well. That said, right now, in addition to project specific org-files, I keep one special org-mode file that are my 4 or 5 top priorities and for a one-man consulting shop that is enough process :-)

I also liked the opening SCRUM quote from wikipedia. I have experienced "over-SCRUMing" first hand at one of my customers. Daily SCRUM meetings may seem like a good idea, but if not tightly controlled they can take up a lot of time.

So Google is an engineer's dream and everyone is so nice and there are huge incentives and all that, ok... but if that works so well, why have they failed to come out with another product that is unquestionably as successful/profitable as their advertising platform has been? (the core of which they didn't invent, they stole it from Overture)

Just saying, if you take Google and you remove that particular aspect of their business, there would be no business. So like, 90% of the engineers' efforts account for what, like 5% of the profits? Hardly an approach worth emulating unless your startup happens to have a golden egg laying goose like Google.

Jobs created the Mac, and the iPhone. I just recently went back and re-watched the original iPhone keynote, and I believe this is very much a theme of what he was saying on stage.

Making something new, at world class quality, is incredibly difficult.

I've been promoting of Agile practices for many years. But, lately I have seen several cases of non-technical people hijacking Agile. Suddenly they become "Agile experts", they don't care/understand about continuous integration, regression testing, technical excellence, etc. Agile was a developer flag, but now it is being used to beat developers by the same people that never understood the nature of software development.

I'm just wondering how they manage those bonuses. Wouldn't it get kind of political? Or do they have some kind of arms-length system?

I can tell you how I would do it, which would be to have as strong a tie as possible between 'Project X' and 'Revenue generated by Project X'. If it's true that most projects that get launched are launched by small teams, then the problem isn't much more complicated than that (divide the bonus equally between the members of the team, or in proportion to how long they worked on the project). If the teams are larger, you need to allocate bonus pools for the managers/tech leads to divide amongst their team - and that could get political.

> to have as strong a tie as possible between 'Project X' and 'Revenue generated by Project X'.

At Google, that would mean the only teams to get bonuses would be teams working on Adwords.

Yeah, it's a pretty bad suggestion. Many projects don't directly generate revenue. It ignores practically all support projects that help people to do their job (i.e. improving the bugtracker, sales software, test software etc).

How about internal tools? Should tool makers charge for use (which creates friction, losing the benefit of working in a large org)?

A parameter the author is not mentionning is the "smartness" of the ingeneers. When you have smart ingeneers they can mange their own work themselves, identify good idea from bad one, etc.

But I have heard rumors that what is described in this article about google way of running things is not true anymore. Can anybody say something about this ?

Not much of a biggie, but is engineers not ingeneers. :)

Sorry, my bad. I'm French and mixed-up spellings (ingenieurs in French). I can't edit the comment. It is good to point it out so that people don't make the same mistake.

  > developers are strongly encouraged to spend 20% of their time
  > working on whatever they want, as long as it's not their main
  > project.

Did the 20%-whatever-you-want benefit survive the "more wood behind fewer arrows" policy?

Great article until he mentioned Google as a shining beacon of developer fulfillment. I know a few developers in Google (Ireland) and they're made to work huge hours. I'd rather have free time than free pizza.

++ for free time over pizza

Sadly Agile has indeed jumped the shark.

I have always seen Agile as a way to fight the Waterfall process. Another way to see it is to add professionalism and discipline to companies who don't have things like unit testing, code reviews, etc.

In his long write up Steve made two points which I think are the most important:

1. Waterfall is known to be bad; I hope we can just that as an axiom today.

I added the emphasis on 'hope'. I hope so too, but I'm afraid the end of Agile might mean the triumphant return of Waterfall.

2. Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places.

Google sounds like an exceptionally disciplined software-engineering company indeed! This to me implies they do NOT need Agile.

Why would you introduce something designed to professionalize software-engineering to a company which is super disciplined and professional? You wouldn't! The only thing you can introduce is bullshit like 8:00 AM meetings. No wonder Steve hates Agile so much.

But again, everything he says about it being an infomercial and aimed at stupid people is true. But it is still a God send if this meme virus infects a death march plagued Waterfall process which does not use unit testing or even has source control.

Now why would a good developer be suck in such a place? Well maybe you live in an area where there is not a lot of tech. industry and jobs. Maybe you live there because all your family and friends are from there. Maybe your child has severe asthma and you can't afford to leave the gold plated health insurance plan from your corporate job in a non-software company that's big enough to have a software department.

I can't quite imagine how Agile could help a company like Google. But I know how it can be a great benefit to much less disciplined companies.

And I really do fear that the end of Agile means the return of Waterfall. Because Waterfall intuitively makes sense to people who don't understand software engineering. And there are a lot of them outside of silicon valley.

And Waterfall doesn't just plague obscure places with no tradition of technology. The US north east, home to MIT, IBM and formerly DEC, Waterfall has always been big out here too, and it's not because we're not smart.

> Google sounds like an exceptionally disciplined software-engineering company indeed! This to me implies they do NOT need Agile.

This implies discipline and Agile (big 'A') are mutually exclusive. From my experience you have to be very disciplined to do Good Agile (and I have experience of Bad Agile too).

This implies discipline and Agile (big 'A') are mutually exclusive.

No, I would say big 'A' brings discipline, but if you already have tons of discipline, it can't add any more.

Agile and waterfall aren't the only two options. There are other methodologies, like spiral and RUP.

I don't think the death of the "Agile" brand will do much. Sensible people adapt the process to suit their needs anyway, and "good agile" isn't too far from what you'd do if you just tried to get your work done without all these methodology salesmen knocking on your door.

You are not true Agile if you know what you are talking about more than 50% of the time.

5 years later and Steve Yegge still reads like a teenager.

"I love google and don't understand how cholesterol works."

Interesting.

Fat, bad. Cholesterol bad. Salt, bad. Everything, bad. Nowadays, though, they differentiate between "good" cholesterol and "bad" cholesterol, as if we're supposed to be able to distinguish them somehow.

Screw this guy and this kind of anti-intellectualism that makes it cool not to learn about stuff. "Why should I have to know anything about biology?". I don't care that it's only part of the intro, this kind of thing reinforces the kind of self-important "customer-is-ALWAYS-right" righteousness that glorifies ignorance. It makes me angry that people get away with shit like this.

That is the lamest takedown of pair programming I've ever seen. I don't even do it, I don't even like doing it, but I know that the justification for it was never "more is better", and so does Steve.

It's really sad to read this and see what Google used to be, and to compare that to what it has become (although it's possibly still that way if you're in Mountain View and Staff SWE or higher.)

Disappointing Steve Yegge rant on Agile. TLDR: Agile sucks, but I've never done it, now I did it, it's pretty good.

Google does Agile OK, but I wish Steve Yegge could see Agile @patientslikeme - no BS, lots to love - it'd be a very different blog entry.

Reply on news.ycombinator.com