Seven Things I Hate About Agile

I usually vote up Agile attacks, because I love to hear developers talk about the difference between good and bad Agile.<p>But it's getting a little old. It seems the world is full of cranky, half-informed folks who get a little coffee in them and suddenly are ready to make grand pronouncements about the entire state of things (Love the self-recursion here)<p>Seriously, one last time. Agile is best practices around iterative and incremental development. It's not a standard, it's a marketing term. Because it's not a standard, criticizing it is like criticizing "good ice cream". What's good ice cream? Any damn thing you'd like it to be. Perhaps the author has a larger criticism of how stupid we all can be when implementing change. If so, get in line. There are a lot of us.<p>Scrum is a standard, and it's not changing anytime soon. You can call that a good or bad thing, but it's a very small subset of Agile, so it sounds more like a separate topic to me than the entire world of Agile.<p>I hate the way we implement change in technology organizations. Part of the problem we have, unfortunately, is that everybody feels themselves an expert on stuff they read about in a book and maybe saw it done badly a couple of times.<p>The more I think about this article, the more I feel like it's 95% marketing and 5% fluff. Apologies to the author if they are serious, but something is a bit off here. Not worth flagging by any means, but I'm not upvoting it.<p>ADD: Bit of a meta-note. Just this morning I wrote a story on some ideas about how to handle Subject Matter Experts in Agile teams. (shameless plug: <a href="http://www.whattofix.com/blog/archives/2012/08/who-moved-my-sm.php" rel="nofollow">http://www.whattofix.com/blog/archives/2012/08/who-moved-my-...</a> ) The use of the word "Agile" in my article was very useful: it identified the topic as best practices around SMEs in iterative and incremental work. It is a dry topic, and I didn't claim to have all the answers, and it was more narrowly-targeted, so it didn't get a lot of traction. That's understandable.<p>But what I see happen over and over again is that wild hand-waving criticisms get a lot of traction on place like this because they can emotionally engage a larger audience. Practical targeted stuff? Not so much. So for the average developer who's just out of school and never has worked on an Agile team? I'm not sure they're receiving a very balanced look at things if all they read are from places where things are voted up or down based on emotional impact. It's another interesting and counter-intuitive side-effect of the voting/ranking system.

&#62; Pair programming is like those girls that go to the restaurant bathroom together. What are they doing?<p>Why don't you ask somebody who pairs, rather than writing an uninformed rant against it?<p>&#62; If you are customer, you pay twice as much and you get churn.<p>Oh I get it, you're approaching and commenting on all of Agile from your software-as-contract-work perspective. Let me enlighten you: most software isn't sponsored by a single customer on a per-diem basis. But while we're here, let me say this: if you truly think you get half the productivity from a pair, then you fundamentally misunderstand the gains of pairing.<p>&#62; I recommend a more efficient alternative – review pairs. Person A and person B use a code review system to review each other’s code before release. You get the same benefit without the neck cramp and the BS.<p>There is more to benefit from pairing than just on-the-go reviewing. There is also the fact that you retain your focus much easier, you spread technical knowledge when you shuffle your pairs, etc.<p>But on the subject of reviews, your reviews are also much better because they benefit from FULL context, and the suggestions and modifications are made EARLIER (which is much less expensive than getting to the point of being ready to commit and having to refactor everything).<p>Oh and about the neck cramp remark: do you really expect your devs to pair without having mirrored monitors, two keyboards, etc?

So who the hell are Assembla and why should anybody care what they have to say? All I'm seeing here is a lot of misinformed ranting. Sure, there's a kernel or two of truth hidden away in there, but most good rants have that. I don't see that TFA makes any sort of interesting point or arrives at any real conclusion that's helping anybody make a decision though.<p>Oh wait, I'm almost 40, so I guess I'm too busy decaying into compost to know anything about this stuff. Never mind me..

I'm not a big fan of agile either but "over 40" == "the smell of death"? Seriously? Not a convincing, or classy, opening line. And this was posted by the <i>CEO</i> of Assembla.

Pair programming was invented and evangelized by developers, and are its most ardent defenders at every vendor I know that offers Agile services. ThoughtWorks' sales folks hate selling pairs, for the obvious reason that most clients don't love the idea of buying them.

I like how the opening point is ageism. Really classy.

I agree with there being lots of old people in the community of agile-enthusiasts. My theory is that this is because most young people have never worked for a large company with lots of top-down processes and agile is just the default/what comes naturally.<p>This is somewhat similar to the issue of the Cathedral and the Bazaar in software engineering. Most young people have never even seen a Cathedral and just consider the Bazaar model the default.<p>Edit: No offense to anyone in that demographic btw. I have great respect for everyone involved in that community, I just don't think it is very interesting for kids that never knew anything else

Statistically speaking, the "young" startup founder is a complete stereotype. The over-50 crowd which this article refers to as "having the stench of death" actually starts and runs more successful startups than the under-30 crowd. So, to be fair, those "hot" startups you love, that have a business plan worth more than just "build it and they will come" in it, are most likely run by someone over 40.<p>Also, anyone that knocks "Agile" has not had much experience in the enterprise sector. Yes, it has overhead - but in a larger (500+ employees) company that overhead is absolutely crucial to maintaining uniformity amongst all divisions and ensuring all "players" in the game are on the same page.

I cant decide if this article is sarcasm or not. It makes me think about how there is no methodology that is the savior of developers everywhere. You may be able to find some operational efficiency choosing one methodology over another, but at the end of the day you either have developers that can write the code, or not.

"Old People"<p>I find an interesting contrast between his conclusion on Agile conferences versus my 42 year old self. He sees a lot of old people and concludes this must not be a good thing. I see a lot of "old" people and conclude my elders might have learned something over their careers which I might get a leg up on by listening to what they value.<p>I wonder how many lessons older programmers learned in the resource constrained 8-bit or mini-computer days could have help some of the youngster programming these smart phones?<p>// for a comedic take on youth <a href="http://www.youtube.com/watch?v=UKUZ42T9diU" rel="nofollow">http://www.youtube.com/watch?v=UKUZ42T9diU</a>

The thing that doesn't work for me in Agile: being treated like a baby and spoon fed little bits of work with little room for responsibility, initiative, creativity and a personal touch. Agile is great if you are a mediocre manager and you want to run a place full of replaceable cogs, but not so great if you want a place that pushes the boundaries and consistently goes the extra mile

I dislike agile and scrum not because I think they're bad ideas - in fact, there are some good ones in there. The problem is they're so doctrinaire. A "manifesto", scrum masters, agile consultants, etc are all there to enforce processes that don't always make sense for any given team or organization, and they detach you from the reality of actual productivity. Didn't assign the right number of points to your scrum story? Didn't break things down into tasks properly? Velocity fail? If these are your problems, then you're focusing on the wrong things.

Anyone care to explain what the author mean by: "Pair programming is like those girls that go to the restaurant bathroom together."? It sounds like a funny analogy but it's just pure gibberish. The point of the article seem to be to get reactions, not tell you anything about Agile.

<i>What do [Scrum Masters] do?</i><p>I'm sorry, but if you don't know the answer to this question, you're not familiar enough with agile to write intelligently about it. If you're going to write about a technique, you should at least know the basic concepts, whether you agree with them or not. And pretending ignorance for effect doesn't add much to the discussion.

"I don’t think values have anything to do with productivity or collaboration."<p>That is possibly the dumbest thing I have ever read. I have never seen a tight, productive team that didn't have certain values in common. It need not be explicit. (Indeed, being explicit about it is often a sign of problems.) But it has to be there.<p>His counter-example, supply chains, are notoriously difficult to manage. The people who are best at that, like Toyota, often work very hard to encourage shared thinking and shared values across company boundaries. And the notion that in-team relationships should look to the US-Russia relationship as a model is redonkulous.<p>Updated to add:<p>That line strikes me as a classic example of "I don't notice X in action, therefore X is {stupid|unimportant|useless}." Which I've certainly done in the past, but as an old fogy I've taken my lumps enough to learn a little caution.

I totally agree about the scrum master role. I have never understood the need for a scrum master when there are product managers and tech leads. Scrum masters usually don't have technical or product experience. I think some product managers just hire scrum masters to do their grunt work.

At its core agile leads to being able to ship at small intervals and be... uhm... agile enough to adapt to market/business changes. What's not to like?

I genuinely agree. In a former life I was promoted from software developer to lead dev/scrum master, and I can tell you the dev part of the job moved completely to the background, making room for something more of a secretary job: planning poker roundups, doing the scrum board task dance, doing the numbers game on estimated and effective man-hours, etc. Overhead.<p>I don't say agile development is a bad thing. But some managers tend to be led by cool buzz words and obey the manifesto way to strictly.<p>Agile development is different for every team and situation, not a one-stop-shop everyone should adhere to.

<i>&#62; Old people: Agile has the smell of death on it. If you go to an “agile” event you will see few people under the age of 40 and many over 50.</i><p>This has the smell of ad-hominem on it. How about a little evaluation of the <i>ideas</i>?<p><i>&#62; Most organizations which use the word "agile" are using the word precisely because they are NOT agile, and want to be more agile.</i><p>Again, this is basically just saying, "It can't be cool because the cool kids aren't in on it." How about an evaluation of the ideas, not the marketing?<p><i>&#62; I don’t think values have anything to do with productivity or collaboration. The Americans and the Russians didn’t share many values, but they teamed up into a mighty fighting force during WWII because they shared a goal.</i><p>I abhor this attitude. You meet people who are all about "making use of you" at "startup weekend" type events. Values aren't so necessary for productivity in general, but shared values are necessary for productivity in areas where quality and attention to detail are paramount.<p><i>&#62; If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time</i><p>So you are evaluating a practice by the scummiest abuse of the practice? I think this reveals something, but not so much about the practice.

Interesting to see that comments of these articles are full of "no true scotsman" arguments.

The title is provocative (it's a numbered list, and a rant!) but the author would have been better served with "Seven Ways to Make Agile Better", for no other reason than taking a positive slant. Agile can be built on, its not necessary to tear it down to the foundations first. The article wasn't helpful or illuminating and full of strawmen -- the author is attacking their own definitions of Agile.<p>Full disclosure, I'm well in to my forties. I can pass for thirtysomething (a reference probably only fortysomethings will get) and once was mistaken for latetwentysomething by someone who was bad at guessing ages, good at flattery, or some of both. But please read the following with full consideration of the biases of age, from which youth is wonderfully immune.<p>Agile is essentially about shortening feedback cycles. The problem with waterfall was that work products were reviewed when 'complete', when change costs were high and commitments large. Decompose the work products into smaller chunks (backlog items and tasks) and review more frequently -- Sprints (every N weeks), standups (daily), pair programming (realtime). Every work product in a waterfall cycle, not just code, can be decomposed into smaller tasks -- design documents etc. can be constructed iteratively and incrementally, in parallel or sequentially (the latter meaning you can overlay Agile on top of waterfall) with tight and layered feedback cycles.<p>There are many artifacts, but dwelling on their structure and nature without reference to their essential role leads to superficial criticisms.<p>When something is broken in Agile always return to the fundamental question of how well the feedback cycle is working and how to fix it. Sprint reviews not providing value? Are they being used for feedback or have they become demo days? Has the standup become a daily status report?

Most of these complaints apply to any workplace or group that advertises itself to follow a certain methodology.<p>Half the problem with places calling themselves "Agile" is the need to advertise to the world the process you use to do what you do.

Andy has observed that people under the age of 40 don't talk about "Agile" as much as people over it. I have NOT made this same observation, but I have a theory about a possible reason that Andy has observed it.<p>People over 40 call it "agile development". People under 40 call it "programming". The people over 40 remember doing it differently -- we remember the nine month efforts to write requirements documents that then must not be deviated from even if it is necessary to save the project from failure.

Agile is the corporate gobbledygook for convoluted process and making sure people work day in and day out even though there is no long term goal. Suits them!

I am biased, but it is hard to take someone who is talking about stagnation seriously when his blog ends in aspx.

Oh yeah, I remember all those Morning Stand-Up Comedy Meetings at Salesforce.