Agile Backlogs. Sigh.
What a mess Frederick Taylor created.
We can’t blame him completely, of course. He was just an engineer born in the mid 1800s who asked a simple question: “Why don’t we break up industrial processes into smaller and smaller pieces and then use the scientific method to improve on them?”
This seemed like a completely natural idea, and it’s done wonders for a lot of manufacturing, but it has also led to the oppression and murder of millions. Perhaps even the sorry state of your current agile project.
The result of Taylor’s question was “Taylorism“, or Scientific Management.
Lenin was a big fan. So was Stalin. It was used extensively in the old Soviet Union to measure — and punish — workers. It puts forth a way of thinking that feels like common sense. Even today, methodologies like Six Sigma are built on defining processes, measuring them, and so forth. The assumption is that all processes are naturally decomposable.
Who can disagree? As technologists, we learn to create technical things by breaking a big problem into smaller problems, solving the small problems, then reassembling the whole. We solve problems by scientific deduction. It only makes sense to use these tools wherever we can.
The problem is that they don’t always work.
Our Misconceptions About Agile Backlogs Are Killing Us
First, backlogs are not requirements. Say this over and over again until it finally sinks in. Agile backlogs are a symbolic work token list. The tokens represent conversations, diagrams, requirements, tests, and all sorts of other “real” work that occurs later in the project. They’re just tokens. Yes, they work best when you make the titles in such a format as to describe the future state of the system “When the tornado hits, as a farmer I need someplace to hide so that the tornado will not kill me and my family” But simply because you are using the old trigger, actor, verb-noun-phrase, goal pattern of requirements-writing doesn’t mean that you are writing requirements. It just means you are stating your stories as future tests, which is a really good thing to do. Always start with tests!
This means that breaking them up into smaller pieces, like you would do a programming problem, is not appropriate. You break them up at the last responsible moment to allocate and plan work, not to decompose the system.
Second, people can only handle so much. If you’ve ever sat through a backlog session where somebody brings up a 300-item list on a spreadsheet and then the team plods though it, you know exactly what I mean: there is a natural limit to how much I can naturally work with. The team is not full of robots. The backlog doesn’t work as a symbolic work-token list if the people involved can’t mentally keep track of the symbols in the list. The beauty of backlogs is that you can create the symbols at any level of abstraction you like. Hell, you could have one backlog item, “Do Stuff”. It would be worthless for helping plan the future activities of the team, but it would be much less worthless than the huge monstrosities many teams are using to do the same thing. Big fuzzy backlogs are easily broken up and further defined as needed. Huge, finely-detailed backlogs bring cognitive death to anything they touch.
Third, by focusing on Agile backlogs you only hit one part of describing the work. Even if you get the idea that backlog items are simply abstract symbolic work tokens, many times you still start thinking that the future behavior of the system is all that there is to represent the system ahead of time. This is simply not true. There are three kinds of information the team works with to create a solution, and only three: information about behavior, information about structure, and general rules that must be applied in various circumstances. That’s it. What I find is that if you’re in a room with a lot of architects, they’ve got structure nailed — lots of diagrams and technical sketches. Sometimes too much. If you’re in a room with a lot of folks that used to be Business Analysts, they’re really good at talking about future behavior. Sometimes too much. Oddly enough, nobody cares much about broad rules, stuff like “We need all the screens in Klingon too.” Go figure. Perhaps if you were in a room with compliance officers, they would be really exact about all the business and non-functional rules that must be satisfied. Don’t know.
Future behavior is the one that gets the most attention from our Product Owners and Managers, because that’s what makes the most sense to talk about. What will the system do next week once we’re done? It’s a natural form of test that anybody can understand: what did you say the future behavior would be? Is that true today? That’s why the backlog is stated in terms of future behavior. But you need all three kinds of information, and in roughly equal amounts, for a solution to emerge. That’s fine for most Agile teams — we can get a lot through conversations and notes on story cards. The problem is that if you’re not completely sold on Agile, you start focusing on those User Stories, on the backlog, and start thinking that the harder you work at the backlog, the better the future product will be. That’s simply not the case. In fact, it works the opposite way. You end up with a perfect set of specifications and designs for a system that takes way too long to build.
A practical, short book on Agile Backlogs
All of this is why our second book in our Tiny Giant series is going to be on backlogs. It’s the thing we’re most unhappy with. Most teams have backlogs that need quite a bit of work — and they know it. It’s the thing that’s most-misunderstood about actually implementing Agile. A simple-to-understand and short book on Agile backlog management, grooming the backlog and agile backlog formats has to be something that can bring value to the community.
The idea that anything that humans can do can be broken down and managed scientifically is true when it is limited to a narrow set of activities around producing concrete items. But when the product becomes more like intellectual property, the process boundaries are no longer concrete — ideas don’t move around your team on a conveyor belt — and the paradigm fails. And even when it does work, nobody wants to be treated like a robot. Do yourself and your team a favor: take some time today and think hard about the state of your agile backlogs.
January 25, 2012