It was quite a mess Frederick Taylor left for all of us.
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!
For such a simple idea, it had a huge impact, spawning an entire field of study known as "Taylorism", or Scientific Management.
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.
And who's going to argue with that? As technologists, we quickly learn how to create technical things by breaking a substantial problem into smaller problems, solving the small problems, then reassembling to create the whole. We fix problems by scientific deduction. It only makes sense to use this way of thinking wherever it's possible.
The problem is that this method doesn't always work.
The problem is that they don't always work.
To begin with, backlogs aren't requirements. Say this over and over until it finally sinks in. Agile backlogs are a symbolic work token list. The tokens represent conversations, diagrams, requirements, tests, and many types of other "real" work that happens later in the project. They're just tokens. Yes, they perform the best when you make the story titles in such a format as to express the future state of the system. For example: "When the storm hits, as a farmer I require someplace to hide so that the it will not destroy me and my pals". But simply 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 stories as future tests, which is a really good thing to do. Always begin with tests!
Breaking them up into smaller chunks, just like you would do a programming problem, is not applicable. Wait until the last moment to create the smaller chunks and to set aside and plan work, not to decompose the system. They are not requirements.
Enough with the detail! Too much detail distracts us from the overall view.
Next, team members can only deal with so much. If you've ever sat through a backlog session where somebody brings up a 280-item list on a spreadsheet and then the team grinds though it, you know exactly what I mean. There is a natural limitation to the amount that I can actually use. The team is not made of automatons. The backlog doesn't serve as a symbolic work-token list if the people involved can't mentally manage the symbols in the list. The best thing about backlogs is you can create the symbols at any degree of abstraction you wish. Hell, it's possible to have one backlog item, "Fix problems". It would be useless for helping plan the upcoming activities of the team, but it would be much less useless than the enormous monstrosities many teams are using to do the same thing. Large fuzzy backlogs are very easily decomposed and further defined as needed. Ginormous, finely-detailed backlogs bring cognitive destruction to anything they come near.
Thirdly, by emphasizing Agile backlogs you only hit one part of describing the work. Even if you get the idea that backlog user stories are simply abstract symbolic work tokens, people will start concentrating on the future behavior of the system and miss the problems of the here and now. This simply doesn't work. There are 3 kinds of information your group works with to produce a solution, and only three: information about behavior, information about structure, and overall 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 technical sketches. Usually too much. If you're in a room with a lot of folks who used to be Business Analysts, they're fantastic at discussing future behavior. Usually too much. Oddly enough, nobody cares much about broad rules, things like "We need all the screens in Martian too." Weird, huh? Perhaps if you were in a room with compliance officers, they'd be really specific about all the business and non-functional rules that must be satisfied. It woud be an interesting experiment.
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!
For such a simple idea, it had a huge impact, spawning an entire field of study known as "Taylorism", or Scientific Management.
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.
And who's going to argue with that? As technologists, we quickly learn how to create technical things by breaking a substantial problem into smaller problems, solving the small problems, then reassembling to create the whole. We fix problems by scientific deduction. It only makes sense to use this way of thinking wherever it's possible.
The problem is that this method doesn't always work.
The problem is that they don't always work.
To begin with, backlogs aren't requirements. Say this over and over until it finally sinks in. Agile backlogs are a symbolic work token list. The tokens represent conversations, diagrams, requirements, tests, and many types of other "real" work that happens later in the project. They're just tokens. Yes, they perform the best when you make the story titles in such a format as to express the future state of the system. For example: "When the storm hits, as a farmer I require someplace to hide so that the it will not destroy me and my pals". But simply 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 stories as future tests, which is a really good thing to do. Always begin with tests!
Breaking them up into smaller chunks, just like you would do a programming problem, is not applicable. Wait until the last moment to create the smaller chunks and to set aside and plan work, not to decompose the system. They are not requirements.
Enough with the detail! Too much detail distracts us from the overall view.
Next, team members can only deal with so much. If you've ever sat through a backlog session where somebody brings up a 280-item list on a spreadsheet and then the team grinds though it, you know exactly what I mean. There is a natural limitation to the amount that I can actually use. The team is not made of automatons. The backlog doesn't serve as a symbolic work-token list if the people involved can't mentally manage the symbols in the list. The best thing about backlogs is you can create the symbols at any degree of abstraction you wish. Hell, it's possible to have one backlog item, "Fix problems". It would be useless for helping plan the upcoming activities of the team, but it would be much less useless than the enormous monstrosities many teams are using to do the same thing. Large fuzzy backlogs are very easily decomposed and further defined as needed. Ginormous, finely-detailed backlogs bring cognitive destruction to anything they come near.
Thirdly, by emphasizing Agile backlogs you only hit one part of describing the work. Even if you get the idea that backlog user stories are simply abstract symbolic work tokens, people will start concentrating on the future behavior of the system and miss the problems of the here and now. This simply doesn't work. There are 3 kinds of information your group works with to produce a solution, and only three: information about behavior, information about structure, and overall 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 technical sketches. Usually too much. If you're in a room with a lot of folks who used to be Business Analysts, they're fantastic at discussing future behavior. Usually too much. Oddly enough, nobody cares much about broad rules, things like "We need all the screens in Martian too." Weird, huh? Perhaps if you were in a room with compliance officers, they'd be really specific about all the business and non-functional rules that must be satisfied. It woud be an interesting experiment.
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 backlogs and teams, or his website on being a Agile ScrumMaster.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.