≡ Menu

Programmers: The Top Ten Things Management Hates About Agile

Damon Poole just did a post on the Top Ten Things Programmers Hate About Agile. But it’s not just programmers who dislike agile methods. I’ve come across many managers who feel many of the same things that are on Damon’s list. So without further ado, the top ten things management hates about agile:

#10 Agile is Snake Oil sold by Snake Oil Salespeople

Damon refers to Snake Oil salesman who pollute the name of agile with insane rules, crazy methodologies, and generally things that don’t focus on the value. On the flip side, managers see agile as an excuse for Jerry and I to pair on reading Slashdot, cutting our productivity in half. Suddenly documentation isn’t allowed, coding standards are rejected, and the team dissolves into chaos – all under the name of “Agile”. Snake Oil indeed.

#9 Agile Has Too Much Jargon

Imagine you are a manager who has been dutifully reporting your team’s status to upper management using Gantt charts. They know it’s a lie, you know it’s a lie, but the pretty boxes line up to the pretty date at the end, and it looks like stuff has been filled in. All of a sudden I’m supposed to report to an executive team with “burndown charts” measured in “Graham Cracker Cookies” which show that we’ll miss our date – by about two years. And why the heck are my developers testing? At least, I think that’s what they are saying. Something about TDD. Or BDD? Maybe it was ATDD. Or FDD. No, I saw a book on DDD on one of their desks….

#8 Agile Means The End of Control

What’s a manager to do when the boxes on the Gantt chart don’t line up? Hold a retrospective! And by retrospective, I mean calling the team to an emergency meeting, scowling at them and reflecting on what they’ve done by asking, “What the hell is wrong with you all?” And it works – they all scramble like mad men, working overtime, pushing the bits, and making the boxes line up. And now you want to tell me that they are supposed to “self-organize” and “select their own work” and “know what’s best for them”? Please. They’d be nowhere without me!

#7 The Developers Just Want Me to Have an Ulcer

Sure, it seems innocent enough, this “onsite customer” crud. Next they’ll be wanting to sit in on the executive planning groups, offering “feedback”, and then wanting to just talk to anyone! The other groups are far too busy to let them start changing this organization like that. It is *vital* they fill out the proper request form so we can track this! (Although track it why is never said…)

#6 The Agile Consultant Will be A Pain in The Neck

So, you want me to pay $20k for some agile “consultant” to come in and tell my team, “Change your organization or change your organization” and then tell me that *I* need to be prepared and have these stories broken down? That’s not my job! I’m the manager, dang it! I guess I’m doing all this work so they can just go off and play World of Watercraft or whatever that is.

#5 Pair Programming!

Oh! Yeah! Play World of WaterCraft in pairs, so that we take twice as long to get half as much stuff done. I mean, the corporate standard won’t let us tear down these cubicles. Working at pair stations – I know they’ll hate it. They may think they won’t, but I know they will, so best to nip that sucker in the bud.

#4 Stand Up Meetings, Planning Games, It’s Meeting Hell!

At least they are sensible enough to put in a “Standup meeting” so I can find out what this team of lackeys is doing. But what’s with this other stuff? Scrum of Scrums? Planning Games? Break down the tasks right there? How are we supposed to get any work done if we are spending 4 hours every two weeks going through a “backlog”? Code, Code Monkey, Code!

#3 Drive-by Agile Transition

I know this is just a fad. Like that 4GL stuff. And wasn’t VB supposed to make everything better? They just think they’ll do this, then it will blow over like everything else. Why waste all that money?

#2 Just Whiners Asking For Stuff

I don’t get this. They all have a 17″ flat panel monitor, and a mid-grade development machine. Now, because of “Agile” they want two monitors, two keyboards, a build machine, some continuous integration thing, some “refactoring” tool, conferences, trainings – money! I see their little ruse. Besides, I know that if they get this, they are just going to jump ship. It’s never enough for those whiners.

#1 Do Less With More

This agile thing is just a chance for them to make me look stupid. Like I’m going to go to our management and tell them that, “Yes Sir, we’ve been working in pairs! And now we know we are going to be 2 years late!”. I don’t get why they can’t see the math. 2 Developers + 2 Computers = 2*Productivity. 2 Developers + 1 Computer = 1*Productivity. Half. I’m throwing away half my money. Just to me told that our chart says that we aren’t working fast enough. If we’d quit focusing on these “fads” and just work faster, maybe we could actually ship something for a change.

Of course I don’t buy into that. Transitioning to agile methods *is* hard, and absolutely takes a commitment on both the team and the management. And it works best when there can be open, honest discussions about what both the team and management need. It’s unfortunate so many developers are in situations which require them to have to resort to sneaky tactics just to try something new.

The real snake oil is the years of management advice which says that top-down management is the best thing since Gantt charts. That the manager is the manager because she knows best, and, by definition, the team can’t. It’s time to stop focusing on these pretty little charts and asking hard questions. What value do we offer? How can we deliver that value as rapidly as possible? What will help our customers, and how can we reach out to them?

And, in the meantime, work to understand what your management needs, and how you can continue to provide that to them. And if they just don’t want to work with you, then either do it anyway, or find some place that will.

Comments on this entry are closed.

  • Damon Poole September 24, 2009, 2:47 am


    That was a riot! Thanks for the entertainment.


  • Kevin Wolf September 25, 2009, 7:58 am

    I might offer up one more point. It seems like lot of the buzz I read/hear is coming from people implement-ing (read -ing not -ed) agile. What I’m hearing from this “buzz” is that people that may not agree with some aspects of agile are doing things are wrong. This includes some very successful pioneers in our industry *cough* @spolsky *cough*.

    When I hear someone with somewhat limited experience that is implement-ing agile stating that they assume they know more about software development then people with a successful track record, a little red flag goes up about the whole process.

    My point is not that there isn’t any validity to agile. IMHO the best process is one put in place that takes into account the context (leadership, team skill/experience, type of project, etc…). Statements like “When should I test” “All the f**king time” do a discredit to value that agile brings and raise red flags.

    my two cents

  • Mike Dietz November 11, 2009, 2:35 pm

    Fair disclosure: I have only read about, and been to seminars on Agile and Scrum, never done it. One place I worked tried to do Agile light LOL.
    Have you ever taken your car in to be fixed, the repair shop says: “we will call you by noon to tell you what it needs?” They call, give you the diagnosis, usually worse than you expected, and more expensive. You agree, show up at 5 to pick it up, and find out either: they are not done or it will cost more. Worse is when they give you the car back and it still is not right.
    Compare that purchasing experience to going to the store and buying a six pack of beer. The worst thing is the added tax, or if under age show ID. And of course the beer might be a little on the old side, as if you would notice.
    Obviously the beer buying experience is a better one. IMHO management thinks it is getting the beer buying experience with traditional development and that Agile is closer to the car repair experience. Key word here is THINKS. The hurdle to acceptance is to realize provide more accurate analogy for what the current development is like.

  • Marc bledsoe November 25, 2009, 12:53 pm

    Cory, great post! I have bookmarked your site and will be sharing these gems with my team.

    I think Mike makes a really good point.

    Car repair is much more complicated than you know. Beer buying isn’t. (I like the analogy myself)

    Agile methodologies allow for developers and customers/product owners agree on the short term/easy changes to develop first and if you want the head gasket replaced, it is going to cost you and take longer than you expect.

    The other point is: you really don’t know what is wrong with your car when you take it in. You trust that the mechanic is telling the truth and really is only concerned about you driving a safe car. My question is: why don’t we trust developers similarly?