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.