The Agile Disease

As somebody who makes bucks off the word "agile", I feel like I should respond. I'm not going to take apart his piece, because I too am sick of the manifesto and believe that the top dogs are just in this as a marketing exercise.

Having said that, Agile was not put together by those guys. That's just what their books say. Agile techniques have been being used for decades. They just didn't have the cool marketing term. You don't have to drink the coolaid to be agile -- any high-performing team is going to be agile, whether they call themselves that or not.

Second, Agile is a philosophy, not a methodology. It doesn't tell you what to do, it tells you what to think about what you're doing. Agile/Lean IS just common sense, but nobody seems to have much common sense anymore. You can apply the agile philosophy to all sorts of methodologies.

Third, Agile is not for mushy-headed enterprise guys. It probably works better for small customer-facing shops. To say agile is a response to CMM or heavy-handed processes is again to buy into the story the book-writers want to tell you. Put down the crack pipe. Agile has always been around, and has been used inside of all kinds of other methodologies.

Finally, Scrum is NOT agile. Scrum is a project management framework that you can use for agile projects. You can use a lot of others, or you can roll your own. The Scum guys are the religious nuts in this circus, if you ask me, and they are the ones causing all of the backlash. The rest of the Agile movement is just about how to best iteratively and incrementally do your job. That's a good conversation to have.

Ironically, a key factor I'm finding in successful agile teams is the ability to be open-minded. If you are an agile disciple or evangelist, or if you are a anti-agilista, usually it gets in the way of team performance. It's the people who want to have an ongoing conversation about how to keep increasing team performance -- without getting hung up over what book it was in or not -- that grow killer teams.

A. Agile methods are just common sense.

B. My company has no common sense, so it treats the agile methods as some sort of religion, and thereby remains completely dysfunctional.

C. I am in hell and need something to shout at. If I shout at my coworkers I will get fired. But there is a consultant within shouting distance.

D. My life sucks and it's all the fault of the Agile Methodologists!

If anyone ever wonders why management consultants charge all that money: This is it. Would you want to walk into this guy's company and try to give advice? You'd have to be awfully well paid!

The author is on the path to enlightenment, but he is not yet there. He's figured out that the capital-M Methodology is primarily designed for broken companies. [1] He's well on his way to figuring out that he's working in a broken company himself, which is why there are so many people employing Methodology there. What he hasn't figured out is that you can't fix a broken company by walking up to people and telling them "you aren't writing documentation or using the bug tracker because you aren't a very talented coder and you have no common sense". I have seen this management style tried, and it doesn't work: it just makes everyone unhappier, and it focuses their unhappiness on you.

If you want to tinker with a dysfunctional company instead of just running for the hills, you need to (a) recruit allies, (b) equip your allies with powerful Jedi mind tricks that they can use on their less-enlightened management, and (c) find ways to maneuver problematic people out of the way of your allies -- or, if necessary, destroy them. This is why there is always a Methodology lying around -- and why, when one dies, another is always there to take its place. A Methodology is a rhetorical weapon, designed for just these purposes.

(a) It's not an accident that Methodologies evolve cultlike features. So does every effort to recruit a bunch of people to a cause, whether it's a fraternity, a political movement, a school of software development, a message board for hackers, or, you know, an actual cult. "Join me and we will fix the company."

(b) The Methodology eventually evolves expensive consultants in suits, and industry-standard buzzwords and rituals whose magical powers are strong and unquestioned. This is important. If your buzzwords aren't magic, nobody will listen to you unless they have common sense, which is very unreliable. Remember when Java was on the uptake, and you couldn't sell anything to a corporation unless it somehow involved J2EE? "Don't worry, Higher Management. We are not merely employing our own native talent and common sense. We are using an Accepted Methodology as endorsed by Higher Powers. You don't need to see our identification; these aren't the droids you're looking for."

(c) I have never heard of a "Scrum Manager" before, and I agree that he or she has a very silly name, but I think I already know what this person is for. This person is there to provide a second manager that is empowered to talk back to the first one, who may well be clueless (at least part of the time). The original poster actually understands this. He just doesn't accept it. He has yet to accept that occasionally-clueless managers, let alone permanently clueless managers, are a fact of life. He seems to think that you can somehow avoid having clueless managers, or fix them by appealing to their common sense. [2] Give him time. Someday he will stop bemoaning the needless existence of powerful weapons and start learning how to use them. "Mister Manager, sir, if you don't stop insisting on screwing up our work I'm going to have our Scrum Manager report you to the Methodology Police."

Unfortunately, like Harry Potter's magic or the Force, Methodology is just a tool. The fact that people are using it all the time, brandishing its most powerful aspects in broad daylight, doesn't mean that things are going well or that the forces of good are necessarily going to win out. Quite the opposite, really. Someone whose projects are well-managed will appear to be living a comfortable, slightly boring life in his home in the swamp, and will rarely be heard employing a Methodology out loud.

---

[1] As opposed to garden-variety methodology, which is fine and -- for the talented -- is just "common sense".

[2] Those of us without nominal managers -- startup co-founders and independent consultants -- shouldn't feel too smug here. Clueless customers and clueless clients can be every bit as problematic as clueless managers.

The funny thing is that while our company tries to follow agile practices internally, this does not prevent iterations from failing. The developers are not that bright, the growing code base is not that awesome, and this is our worst enemy.

However if you're stuck in large organization that has been doing waterfall, almost any change is good news.

And you bet A LOT of very respected software companies, not IT departments of other companies, but actual pure software companies are stuck in waterfall.

So then this pseudo religious movement comes along with Scrum and stand up meetings and story points and blah blah blah, but along with the blah also comes test driven development, and iterative development.

Yes daily standups are a lot easier to adopt then TDD, but that's why the pseudo religious thing is useful.

It helps you drink ALL the kool-aid.

But game design on the other hand I'm not so sure about, how long does a game technology like a 3D engine last? Is it long enough to justify 100% test coverage? As much as I love TDD, I am not so sure about it in game dev.

That doesn't mean that Scrum is just a "cookbook." A book that's "just a cookbook" would only have recipes. A book about learning how to cook a certain cuisine would have recipes included as examples and exercises, but would also go into generally applicable principles.

Of course there is a spectrum. Lots of cookbooks have some instructional material. There are even books that are 1/2 instructional, 1/2 straight recipes.