The following tirade is the result of years working in badly-implemented Agile environments, and the sneaking suspicion that there is no other kind.
ChildSkeletonFactory
In software, we like to be agile. Not literally, not in any way that involves physical movement beyond the coffee machine, but metaphorically. We like metaphors, preferably more than one at a time, and so code is full of picturesque objects like factories, dictionaries, trees, bootstraps, threads, skeletons, children, containers, watchdogs and so on. At best, they’re combined into monstrosities like ThreadDictionaryContainer and ChildSkeletonFactory. Anyway, Agile, in software terms, is a way for us developers to feel like ninjas without all the tedious fitness and discipline. It is, to be perfectly frank, a way of organising software projects.
Before there was Agile, there was the universally derided Waterfall. Waterfall meant trying to finish stuff before selling it. Of course, this never worked; every piece of software there has ever been is, to varying degrees, incomplete and broken. So Agile embraces this fact, making a virtue of deliberately releasing stuff while it’s still full of bugs and missing features. Then you see whether anybody notices. Since you didn’t document what it was supposed to do in the first place, they might not.
Managers love Agile. It sounds progressive, doesn’t it? Who wouldn’t want to synergistically leverage an Agile methodology? Buzzwords aside, they love it because it reduces admin. It reduces admin by getting the developers to do it, while giving managers some slick charts to show to their managers. Agile means that the managers don’t have to write a specification. The developers talk to the customers and hammer it out that way. Or actually, since there probably aren’t any customers yet, they make it up themselves. Still, probably better than whatever the managers would have come up with. Meanwhile, the managers keep themselves busy writing blogs about how effectively they manage their Agile projects, and eventually quit and start lucrative careers as consultants, explaining to other companies how to synergistically leverage Agile methodologies in turn.
I’d Be Committed
Naturally, the lack of any plan to speak of can cause tensions between the developers and their (potentially imaginary) customers. In the Agile world, we refer to the customers as ‘chickens’ and the developers as ‘pigs’. Well, I don’t, I’m not a consultant. More formally, like if you ever get to meet one, the chickens are known as stakeholders, because they’ll come after you with a pointèd stick if you don’t produce enough code-bacon. As a developer, you can fight back using a ‘spike’ to keep them at bay. A spike is a metaphor, of course, so you don’t get a real one. Instead, it’s a kind of universal excuse for not getting any code written, while you try to work out what the hell the project is supposed to be about, or whether the latest hot technology the management insist that you use (Mycoservices or Spork or Recat or whatever) is actually relevant in any way.
To mitigate the chaos, one of the developers takes on the role of Scrum Master, which is like a manager but on a developer’s salary. The Scrum Master has to keep the chickens away from the pigs, so that the pigs can keep their noses in the trough, i.e. coding. Why Scrum Master, not cow or goat or another barnyard animal? Because, perhaps realising that it never ends well for a pig or a chicken, the metaphors here take a turn away from farming and into sport.
Hangman’s Cricket
The most common way to do Agile is called Scrum. Nobody really explained rugby to me at school, we were just expected, as boys, for it to come naturally. So my memories of the actual scrum are of wearing little shorts in a cold muddy field, while the scrum master (i.e. the geography master in a tracksuit) told us which boy’s head went between which boy’s thighs, then engage and push! Then something happens with the ball, you run around for a bit, somebody falls in the mud and you start all over again. The metaphor is far from transparent.
But then, it’s not really rugby, it’s running. Remember “It’s a marathon, not a sprint”? That’s out of date, Daddio. Totally Waterfall. With Agile, it’s always a sprint. You sprint and sprint and iterate and reiterate pretty much forever. A sprint is an allotted time, after which you (pigs) should have hacked together (gorged) something (pork) functional (fat) enough to release (slaughter). There isn’t a standard length for a sprint, but the consensus is that three weeks is too short and two weeks is too long.
Horsicle
But then, it’s not really running, it’s darts. It’s all about the board. The board is where you organise what passes for a specification this week. Except that it’s not darts, there are swim lanes on the board because you’re doing Scrumban and… let’s back up a bit. Relieved of any actual managing to do, the manager’s role becomes one of defining the process. And they like to keep their hand in, so that will happen constantly. Every sprint, there’ll be something slightly different: a new report to fill in, a different arrangement of the board, another level of work items, something like that. At some point, they’ll try Kanban. Kanban means you stop doing sprints and start just producing stuff that somebody needs, just when they need it. Sadly, it won’t work either, because nobody knows what they need until it’s too late, and the managers will get worried because the charts and reports stop flowing. So they’ll take the best features of these two super-efficient Agile systems, Scrum and Kanban, and combine them into one. Think of a bicycle and a horse, two ways of getting somewhere faster. Now combine them: a horse on a bicycle! A horsicle! That’s Scrumban.
Assuming your team has a board, you’re going to need to put some points on it. What do points mean? Prizes! No, actually, nobody knows what points mean, that would spoil the fun. They’re called story points, because everyone makes up their own story about what they’re worth. They’re used to measure effort, so naturally they’re worth a certain number of hours of work. Except that you’re not allowed to say that. Beings so transcendentally Agile that they have no need of time units are able to measure the bigness of a task in abstract, unitless numbers. The rest of us, constantly striving for that Agile-nature, have to play poker until we get it. The poker is not another sharp implement, it’s an actual card game; it’s only slightly metaphorical this time. It’s a version of poker where everyone has the same hand, the deck is nonsense and nobody wins. Planning Poker cards are numbered 1/2, 1, 2, 3, 5, 8, 13, 20 and 40 - a demonstration of what happens when an agile team writes a Fibonacci sequence function (“The customer says 21 isn’t round enough, can we make it 20 instead?"). These numbered cards are for bluffing. There are also some truthful cards, for emergencies: one marked ∞, for “this will take forever”, one marked ?, for “I have no idea”, one marked 0, for “We’ve already done it without telling you”, and one marked ⛾, for “We’re going to need more coffee”. But mostly, you try to second-guess which number the scrum master is going to play, and copy them, because if you choose something different you’ll be asked to justify your maverick opinions.
The Sizzle
(Reader’s voice:) But this is just Agile done badly. What if it’s done well? Isn’t there a good system under all the mixed metaphors?
I don’t know. I hope so. And it may exist: that airy and well-lit office, where a diverse but universally good-looking team of rockstar ninja developers, powered by artisanal coffee, spike and sprint and swim together to synergistic success, under the admiring gaze of their visionary and enabling management. I’ve never seen it, but I can’t prove a negative. We all hope it’s somewhere out there. This hope, this Utopia, this perfect workplace, is the sizzle the consultants will sell you. You’ve just got to ask this question: what’s in the sausage?