The Anti Anti Agile Manifesto
I recently came across a rather misinformed document called the Anti-Agile Manifesto. Normally, I just ignore this sort of thing, but in this case, people I know who are in the exploratory phase of agile adoption were treating the document seriously. Because the thinking in this document, which is not uncommon, undermines the success of fledgling agile shops, it seemed worth discussing it.
I worry about I-tried-agile-and-it-didn't-work folks who have never actually have tried agile, giving agile processes a bad name. The Anti-Agile Manifesto is a case in point. It contains a lot of misinformation:
…Agile is simply the obfuscation of common sense…
epics are really just projects
stories are really just use cases
sprints are really just work
stand-ups are really just meetings
iterations are really just versions
backlogs are really just to do lists
backlog grooming is really just planning
burn-down charts are really just earned value charts
velocity is really just output
and that tasks, in fact, are really just tasks.
That is, while the concepts on the left are often presented as groundbreaking
or unique, they are merely weakly defined versions of those on the right.
Pretty much every one of these statements is wrong, but the misunderstanding is widespread, so let's go through their points:
Epics are really just projects
An epic is a story—a short narrative that describes a user working through a problem—that's so large that it can't be fully implemented in a reasonable time frame (a couple weeks). A typical agile project is a collection of epics, each concerned with a different subject area within the application. For example, a store-front application might have a "check out" epic that involves several stories "purchase with a credit card for yourself" "purchase a gift for someone else," etc. That single epic isn't a project—a store-front that supported checking out but didn't support any of the "shop for something" epics wouldn't be of much use to anybody.
The agile notion of a "project" also differs from the traditional waterfall notion in an important way: Waterfall projects have well-defined beginnings and ends, and the project is considered a failure if you don't arrive at that end. In the agile world, killing a project part way through if you discover that nobody wants what you're building is a success. You might find that you achieve you business goals (profitability, for example) after only part of the project is complete, rendering the rest of the project unnecessary.
Put another way, the agile approach is all about flexibility (which is what the word agile means, after all), not about arriving at a predetermined endpoint.
None of this project stuff has anything to do with the epics, though.
Stories are really just use cases
Partly true. I think of a story as a use-case scenario—a way in which the use case could play out. For example, given a use case like "purchasing a product," there are many scenario/stories: purchase one product, purchase many, the credit card wasn't approved, etc. The fact that the notion of a story comes from use-case analysis is a good thing because we can leverage a considerable body of knowledge to improve our stories. The one piece of UML that I still use regularly, for example, is an Activity Diagram, which is a great way of visualizing the flow through a complex story.
Sprints are really just work
Yes, a sprint (I actually prefer the more general term iteration) is a kind of work. So is digging ditches.
Iterations are very discipled work. They must have a prescribed length, a well-defined planning process, an unambiguous set of criteria that determine when they're done, a mandatory analysis of the process failures (a retrospective), and so forth. This is not just random "work" on a program feature.
Stand-ups are really just meetings
Yes, a stand-up is a meeting. So is that vanity session where you had to listen to your insecure boss drone on about nothing for two hours in order to convince himself that he was really in charge.
The problem with this a stand-up-is-just-a-meeting attitude is that it encourages dysfunctional stand-ups in which random issues are brought up. For example, I've been to so-called stand-ups where a power-mad SM, who didn't understand that the SM role is not the same as a project manager, did nothing but order people around and criticize them for well over an hour. (People sat down—you'd think that would be a clue.)
A stand-up meeting has very specific rules: it should last no more than 15 minutes (and that's long). Everyone should say what they're working on, what's blocking them, and what they need help with (or alternatively, what you did yesterday, what you're doing to day, and what's blocking you). That's it. Nobody runs this "meeting." You go around the circle once, and then you solve problems one-on-one afterwards.
In a Kanban environment, stand-ups sometimes take an alternate form of a formal walk across the card wall, identifying the blockages and bottlenecks. Also highly focused, however, and also very short (10 minutes).
A stand-up is not just another word for "meeting."
Iterations are really just versions
Also not true. An iteration is a way to do work in small increments in order to get feedback in a timely way. An iteration might be devoted to fixing existing defects, for example. The code should be stable at the end of the iteration, but it might not be fully functional. (You may need to implement a few more stories before you want to deploy it, for example.)
A version is something that's deployed to the end user.
Backlogs are really just to do lists
A backlog is not a list of tasks that you can check off as they're completed. A backlog is a prioritized list of stories (not tasks), and the priority is set by the business—the most senior people you can convince to participate. The order in which stories are moved from the backlog into the working queue is important, and stories on the backlog may never be implemented if they turn about to be unimportant. Since the business can fail if you get the priorities wrong, having the CEO participate in this process is not unheard of.
That's not to say that there isn't a place for to-do lists. I always use one when I'm working, adding to it things that occur to me that I need to do once I'm finished with whatever I'm working on. They're particularly valuable when you're doing TDD. Those lists aren't a backlog, though.
Backlog grooming is really just planning
Grooming is a prioritization, not a planning, process. Grooming is planning in the sense that it specifies what you'll work on next, but the grooming process has little to do with actual planning. (Allocating people and resources, figuring out the best order of implementation, figuring out how how to deploy safely—all those things are planning, but none of them are backlog grooming).
Burn-down charts are really just earned value charts
They achieve similar goals in that they show you whether an iteration is on track. Personally, I think that burn-down charts are a waste of time, so this point is pretty irrelevant.
Velocity is really just output
There's no connection between velocity and output. A very high-velocity team might be generate very little output this iteration if it's working on a particularly difficult story.
Velocity is the ratio between an ideal-time estimate and the actual time that it takes to do something. It is a measure of estimation accuracy, not of output or work. In fact, treating velocity as an output indicator is actively destructive. It leads to initiatives to "improve the team velocity," which typically lead to dysfunctions like overtime.
Velocity indicates how much the team can do at the current moment in time on the current class of problems. You use it to help size stories to make sure that they'll fit into a fixed-length iteration.
And that tasks, in fact, are really just tasks.
Yes, a task is a task, but so what? I'm not really sure what sort of task they're talking about. You, a programmer, might come up with a list of development tasks as you're implementing so that you don't forget to do something. That's your business, not the team's. Agile planning has nothing to do with assigning tasks, though a team might decide to do that as part of the iteration-planning process.
Planning tasks, like backlog grooming, are a whole different ball game, and they do involve the whole team.
Simplistic summaries like this manifesto never bring real clarity to a discussion, and they often do active damage. It bothers me to think of the damage a list like the current one can do to someone who is just trying to figure out what "agile" actually means.