What a train wreck Frederick Taylor brought about.
But let's not lay all the blame on his shoulders. He was only an industrial engineer born in the mid-19th century who thought: "Why don't we break up industrial processes into smaller and smaller pieces and then use the scientific method to make improvements to them?"
This appeared to be an entirely natural approach, and it has led to big improvements for much of manufacturing, but it has also brought about the oppression and murder of enormous numbers of citizens. The sorry state of your present Agile project might even be because of this seemingly great idea!
Taylor's question became codified in books, schools, and management courses. It was generally known as "Taylorism", or Scientific Management, and it survives to this day.
Stalin was a fan. Vladimir Lenin loved it. It was put to use broadly in the old Soviet Union to closely measure - and punish - workers. It puts forth a mind-set that seems like sound judgment. To this day, techniques like TQM are designed on defining processes, measuring them, and so forth. The presumption is that all processes are naturally decomposable.
Looks to a lot of folks like a no-brainer. As people who develop technology, we quickly learn how to fashion technical products by breaking a big problem into smaller problems, dealing with the small problems, then reassembling the whole. We fix problems by scientific deduction. It makes complete sense to use these techniques wherever it's possible.
The problem is that this method doesn't always work.
The problem is that they don't always work.
Number one, backlogs aren't the same thing as requirements. Say this time and time again until it becomes second nature. 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 on in the project. They're just tokens. Yes, they perform most optimally when you create the story titles in such a format so that you express the future state of the system. An example title is: "Before the blizzard hits, I need to be prepared and have plenty of food, water, and supplies on hand". But just because you are using the old trigger, actor, verb-noun-phrase, goal structure of requirements-writing doesn't mean that you are writing requirements. It just means you are stating your user stories as future tests, which is a really good thing to do. Tests is the best place to begin!
Because of this breaking stories up into smaller pieces, just like you would do a computer programming problem, is not applicable. You break them up at the very last moment to allocate and plan work, not to decompose the system.
Stop drowning in detail! Start swimming in the sea of proper storyboarding!
Second, folks can only deal with so much. If you've ever sat through a backlog grooming where somebody introduces a 310-item list on a spreadsheet and then the team plods though it, you know exactly what I mean: there is a natural limit to the amount that any person can process. Your group is not full of robots. The backlog doesn't work as a symbolic work-token list if the folks involved can't mentally keep tabs on the symbols in the list. The great thing about backlogs is that you can create the symbols at any level of abstraction you want. Heck, you could have one backlog item, "Get stuff finished". It'd be worthless for helping plan the future activities of the group, but it'd be a lot less pointless than the huge monstrosities many Agile teams are using to do the same thing. Big fuzzy backlogs are very easily broken up and further defined as needed. Ginormous, finely-detailed backlogs bring cognitive death and destruction wherever they go.
Third, by emphasizing Agile backlogs you only hit one part of describing the project. Even if you get the idea that backlog items are simply abstract symbolic work tokens, quite often employees will still start thinking that the future behavior of the system is all that there is to represent the system in advance. That's not true. There are 3 kinds of information your group works with to create a solution, and only three: information about behavior, information about structure, and general rules that must be applied in various situations. 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 geeky sketches. Quite often too much. If you're in a room with a lot of people that used to be Business Analysts, they're really good at dealing with future behavior. Quite often too much. Oddly enough, nobody cares much about broad rules, stuff like "We need to have all the displays in Romulan too." Go figure. Perhaps if you were in a room with compliance officers, they would be really specific about all the business and non-functional principles that must be satisfied. I haven't experienced this yet.
Future behavior is the item that gets the most focus from our Managers and Product Owners, because that's the thing that makes the most sense to talk about. What will the system do once the steps are completed? It's a natural form of test that just about anyone can understand: what did you say the future behavior would be? Is that true ? That's why the backlog is constructed in terms of future behavior. But you need all three kinds of information, and in roughly the same amounts, for a solution to arise. That's acceptable for most Agile groups - we can make a lot of progress through informal conversations and notes on story cards. But there's a problem. If you're not sold on Agile, or even if you are and don't realize it, you will begin concentrating on those User Stories, on the backlog, and start thinking that the harder you work on the backlog, the better the future product will be. That's simply not the case. The truth is, it works the exact opposite way. You end up with a awesome set of specifications and models for a system that takes way too long to complete.
But let's not lay all the blame on his shoulders. He was only an industrial engineer born in the mid-19th century who thought: "Why don't we break up industrial processes into smaller and smaller pieces and then use the scientific method to make improvements to them?"
This appeared to be an entirely natural approach, and it has led to big improvements for much of manufacturing, but it has also brought about the oppression and murder of enormous numbers of citizens. The sorry state of your present Agile project might even be because of this seemingly great idea!
Taylor's question became codified in books, schools, and management courses. It was generally known as "Taylorism", or Scientific Management, and it survives to this day.
Stalin was a fan. Vladimir Lenin loved it. It was put to use broadly in the old Soviet Union to closely measure - and punish - workers. It puts forth a mind-set that seems like sound judgment. To this day, techniques like TQM are designed on defining processes, measuring them, and so forth. The presumption is that all processes are naturally decomposable.
Looks to a lot of folks like a no-brainer. As people who develop technology, we quickly learn how to fashion technical products by breaking a big problem into smaller problems, dealing with the small problems, then reassembling the whole. We fix problems by scientific deduction. It makes complete sense to use these techniques wherever it's possible.
The problem is that this method doesn't always work.
The problem is that they don't always work.
Number one, backlogs aren't the same thing as requirements. Say this time and time again until it becomes second nature. 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 on in the project. They're just tokens. Yes, they perform most optimally when you create the story titles in such a format so that you express the future state of the system. An example title is: "Before the blizzard hits, I need to be prepared and have plenty of food, water, and supplies on hand". But just because you are using the old trigger, actor, verb-noun-phrase, goal structure of requirements-writing doesn't mean that you are writing requirements. It just means you are stating your user stories as future tests, which is a really good thing to do. Tests is the best place to begin!
Because of this breaking stories up into smaller pieces, just like you would do a computer programming problem, is not applicable. You break them up at the very last moment to allocate and plan work, not to decompose the system.
Stop drowning in detail! Start swimming in the sea of proper storyboarding!
Second, folks can only deal with so much. If you've ever sat through a backlog grooming where somebody introduces a 310-item list on a spreadsheet and then the team plods though it, you know exactly what I mean: there is a natural limit to the amount that any person can process. Your group is not full of robots. The backlog doesn't work as a symbolic work-token list if the folks involved can't mentally keep tabs on the symbols in the list. The great thing about backlogs is that you can create the symbols at any level of abstraction you want. Heck, you could have one backlog item, "Get stuff finished". It'd be worthless for helping plan the future activities of the group, but it'd be a lot less pointless than the huge monstrosities many Agile teams are using to do the same thing. Big fuzzy backlogs are very easily broken up and further defined as needed. Ginormous, finely-detailed backlogs bring cognitive death and destruction wherever they go.
Third, by emphasizing Agile backlogs you only hit one part of describing the project. Even if you get the idea that backlog items are simply abstract symbolic work tokens, quite often employees will still start thinking that the future behavior of the system is all that there is to represent the system in advance. That's not true. There are 3 kinds of information your group works with to create a solution, and only three: information about behavior, information about structure, and general rules that must be applied in various situations. 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 geeky sketches. Quite often too much. If you're in a room with a lot of people that used to be Business Analysts, they're really good at dealing with future behavior. Quite often too much. Oddly enough, nobody cares much about broad rules, stuff like "We need to have all the displays in Romulan too." Go figure. Perhaps if you were in a room with compliance officers, they would be really specific about all the business and non-functional principles that must be satisfied. I haven't experienced this yet.
Future behavior is the item that gets the most focus from our Managers and Product Owners, because that's the thing that makes the most sense to talk about. What will the system do once the steps are completed? It's a natural form of test that just about anyone can understand: what did you say the future behavior would be? Is that true ? That's why the backlog is constructed in terms of future behavior. But you need all three kinds of information, and in roughly the same amounts, for a solution to arise. That's acceptable for most Agile groups - we can make a lot of progress through informal conversations and notes on story cards. But there's a problem. If you're not sold on Agile, or even if you are and don't realize it, you will begin concentrating on those User Stories, on the backlog, and start thinking that the harder you work on the backlog, the better the future product will be. That's simply not the case. The truth is, it works the exact opposite way. You end up with a awesome set of specifications and models for a system that takes way too long to complete.
About the Author:
If you would like to hear more from this writer, check out his work on Agile Teams and Backlogs, or his website on being a Agile ScrumMaster.
