11 ms·

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

215 points by ghc 15y ago

wisty 15y ago
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?
- crntaylor 15y ago
  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.
  - RyanMcGreal 15y ago
    > 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.
    - amouat 15y ago
      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).
  - wisty 15y ago
    How about internal tools? Should tool makers charge for use (which creates friction, losing the benefit of working in a large org)?
marcusf 15y ago
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.
- Jach 15y ago
  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...
  - jmilloy 15y ago
bambax 15y ago
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...
- dos1 15y ago
  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.
  - snorkel 15y ago
    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.
- snorkel 15y ago
  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.
vonmoltke 15y ago
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".
singular 15y ago
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.
- rsanheim 15y ago
  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.
  - andy_boot 15y ago
    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.
    - 15y ago
chmike 15y ago
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 ?
- plainOldText 15y ago
  Not much of a biggie, but is engineers not ingeneers. :)
  - chmike 15y ago
    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.
DanielBMarkham 15y ago
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-my.php 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 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)
mark_l_watson 15y ago
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.
gearoidoc 15y ago
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.
- KiwiCoder 15y ago
  ++ for free time over pizza
funkah 15y ago
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.
Drbble 15y ago
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.
brd 15y ago
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.
- InclinedPlane 15y ago
  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.
bh42222 15y ago
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.
- wr1472 15y ago
sakopov 15y ago
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.
deleted 15y ago
[deleted]
battaile 15y ago
"I love google and don't understand how cholesterol works." Interesting.
sethg 15y ago
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.
- hopeless 15y ago
  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.
  - lesterbuck 15y ago
    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.
  - MartinCron 15y ago
    If you consider writing test scripts "make work" you're really wasting an opportunity.
wpeterson 15y ago
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.
duwease 15y ago
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.
megamark16 15y ago
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 http://www.confreaks.com/videos/770-rubymidwest2011-keynote
jgarmon 15y ago
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.
- velshin 15y ago
  > 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 http://goo.gl/U9Ysi
  - jgarmon 15y ago
    WOW, I had NO IDEA that was still out there. I guess nothing ever dies on the internet.
babebridou 15y ago
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).
- agravier 15y ago
  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)
vacri 15y ago
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.
huherto 15y ago
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.
michaelochurch 15y ago
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.)
jebblue 15y ago
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?
Estragon 15y ago
> 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?
dave_sullivan 15y ago
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.
- jpendry 15y ago
  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.
Gman32 15y ago
You are not true Agile if you know what you are talking about more than 50% of the time.
readymade 15y ago
5 years later and Steve Yegge still reads like a teenager.

215 points by ghc 15y ago

wisty 15y ago

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?

crntaylor 15y ago
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.
- RyanMcGreal 15y ago
  > 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.
  - amouat 15y ago
    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).
- wisty 15y ago
  How about internal tools? Should tool makers charge for use (which creates friction, losing the benefit of working in a large org)?

marcusf 15y ago

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.

Jach 15y ago
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...
- jmilloy 15y ago

bambax 15y ago

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...

dos1 15y ago
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.
- snorkel 15y ago
  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.
snorkel 15y ago
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.

vonmoltke 15y ago

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".

singular 15y ago

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.

rsanheim 15y ago
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.
- andy_boot 15y ago
  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.
  - 15y ago

chmike 15y ago

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 ?

plainOldText 15y ago
Not much of a biggie, but is engineers not ingeneers. :)
- chmike 15y ago
  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.

DanielBMarkham 15y ago

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-my.php 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 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)

mark_l_watson 15y ago

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.

gearoidoc 15y ago

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.

KiwiCoder 15y ago
++ for free time over pizza

funkah 15y ago

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.

Drbble 15y ago

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.

brd 15y ago

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.

InclinedPlane 15y ago
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.

bh42222 15y ago

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.

wr1472 15y ago

sakopov 15y ago

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.

deleted 15y ago

[deleted]

battaile 15y ago

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

sethg 15y ago

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.

hopeless 15y ago
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.
- lesterbuck 15y ago
  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.
- MartinCron 15y ago
  If you consider writing test scripts "make work" you're really wasting an opportunity.

wpeterson 15y ago

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.

duwease 15y ago

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.

megamark16 15y ago

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 http://www.confreaks.com/videos/770-rubymidwest2011-keynote

jgarmon 15y ago

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.

velshin 15y ago
> 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 http://goo.gl/U9Ysi
- jgarmon 15y ago
  WOW, I had NO IDEA that was still out there. I guess nothing ever dies on the internet.

babebridou 15y ago

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).

agravier 15y ago
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)

vacri 15y ago

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.

huherto 15y ago

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.

michaelochurch 15y ago

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.)

jebblue 15y ago

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?

Estragon 15y ago

> 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?

dave_sullivan 15y ago

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.

jpendry 15y ago
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.

Gman32 15y ago

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

readymade 15y ago

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