A friend of mine recently posted a somewhat anti-“Agile” rant on Facebook a while ago and I had a momentary urge to throw some arguments back at him. After all, I cannot be silent while one slanders the glorious movement!
Actually, I can. Any glory of the movement has been extracted and defiled long ago. Most “Agile” implementations I’ve seen have either been bottom-up revolts from under-empowered developers or top-down mandates from over-empowered managers. Neither approach actually works.
It’s almost as if mixing a prescription of meetings with obscure rugby jargon isn’t enough to fix all of an organization’s problems. You can, if you need to, substitute “XP” or “Lean” or “Kanban” into that last sentence, In the case of Kanban, you get to use Japanese manufacturing jargon instead of rugby jargon because business school guys steeped in a long tradition of Toyota worship really like that.
Obligatory response to “If it’s not working, you’re not doing it right.” Of course we’re not doing it right. Nobody does it right.
I’m not about to bust out the Gantt charts and sharpen my pencil for 200 page technical specification writing, though. Because as much as I’m no longer really pro-agile, I remain militantly anti-waterfall.
The secret ingredient? It’s HATE. Usually it’s love, but…
Why? Let’s look at what happens in a rigid waterfall project:
Firstly, all of the decisions are made at the beginning of the project, a time when (hopefully) everyone knows the least. Also, as the project is probably going to be relatively long, the business has a perverse incentive to cram as much as possible into the specs instead of thinking small and designing only the things that they know they actually need.
Next, the developers will start to push back and say “woah, that’s too much!” in a way that tends to get framed as a negotiation instead of a collaboration. The business guys are almost better negotiators than the developers, so the developers walk away feeling steamrolled. Now the developers start to resent the business as they are committed to a date and deliverable that they couldn’t give meaningful consent to. The macho culture of overwork (long hours, late nights, weekends) only makes that worse.
As this is a big project that you have one shot at, the stakes are really high to get things right the first time. Developers and architects over-develop and over-architect, respectively. They build themselves hooks and layers and infrastructure and generalizations that they might someday end up needing, just in case. The software, an abstract and ethereal beast by nature, becomes even more disconnected from any customer-facing business reality. Developers start having arguments with religious zeal about things like style and formatting. The developers start to hate each other.
After months of sound and fury which seems to signify nothing, the business starts to worry. Why haven’t we seen anything? Let’s have more frequent status meetings. Developers feel distrusted and start to hate the business for breathing down their necks.
After a chunk of working at an unsustainable pace, the developers say “Hey! Now we have something to look at! Are you happy now?” Followed almost immediately by “What? You want that to behave differently? But this is what you signed off on!” and “Of course that part isn’t done yet, I didn’t tell you that part was done, did I?” and “Stop complaining about the fonts, we can fix the fonts later. Sheesh”
Eyes are rolled. The business starts to hate the developers for being so difficult and condescending.
Once the thing more-or-less works, it’s bundled up and sent over the wall to QA. As QA now has less time than they managed to negotiate but no room to adjust. That’s what you get for being at the tail end of a fixed-date schedule. When they find “real” bugs, developers resent them for making them look bad. When they find things that aren’t “real” bugs, developers berate them for being wrong.
The testers start to feel that they are the only people who care about the users, and that the crappy developers don’t even care enough to fix the goddamn bugs. They fight among themselves about what bugs are “priority one” and what bugs are “priority two” and bug #2628 is really a duplicate of bug #2599. The intellectual output of some of the best minds in our generation has been spent arguing over differing priority levels of bugs that will probably never get fixed anyway.
Eventually, the “critical” defect count gets low enough that the business decides to release the darn thing, even though the QA folks think they are wrong to do so, there’s nothing they can do to stop it.
Maybe there’s a launch party. We’re done! Bust out the French Champagne! Everyone feels a little more uneasy than celebratory, however.
Customers start to get their hands on it. It’s radically (and pointlessly) different from the last version, so existing customers hate it because it changes their expectations. It also has a lot of bugs in it, so new customers get to hate it as well. Tech support hates everyone for releasing this half-baked beast into the wild and putting them in a difficult position. Everyone scrambles to put together “hot fixes”, the releases of which never warrant French Champagne.
Upon hearing all of the complaints, the business obliquely blames QA for not finding all of the bugs (as if the existence of bugs that they didn’t create is somehow their fault) with the semi-rhetorical “did anyone even test this?” QA hates this, naturally, and now they get to hate the developers for making them look bad.
Those who have the strength to keep going get to jump into another cycle! As all of the problems were obviously caused by lack of up-front design and documentation, so we’ll do even more of that. Also, as the code has degraded into a dangerous pile of spaghetti, broken glass, and human blood, we’ll just completely rewrite it with an entirely new architecture and “paradigm” to have fresh arguments over.
Part of the tragedy is that throughout this whole process, everyone is doing their best. The business people aren’t “bad” business people, they just lack super-human foresight. The developers aren’t “bad” developers, they just have normal emotional reactions to work they are invested in. The QA people aren’t “bad” QA people, they just lack super-human omniscience. Though I have worked with some QA people who were to close to omniscient it was scary, that’s a different story.
The whole arrangement is an engine for hatred and despair, an engine fueled by tribalism and resentment. The only thing holding these isolated hate-filled groups together is their even greater hatred for everyone else.
It’s also an engine for guilt and shame. People feel that they are never following the “proper” process “properly”, and they sneer at those who don’t even try to follow the process as either “cowboy coders” or “gullible fools who drank the agile kool-aid”.
So, go ahead. Mock “agile” all you want, but let’s remember the historical context, shall we?