Yesterday I attended a Waterloo Agile Lean session on Story Mapping presented by Mark Levison. I had heard of Story Mapping but hadn't worked through it before. I liked the hands-on exercises approach Mark took to help us understand the process and benefits of that technique. This blog post is not about Story Mapping.
I love learning and take any opportunity I can to hear different speakers present on topics that I think may be of value. Sometimes I even attend the same talks and workshops when they are done by different speakers so that I can understand differences of style in presentation, stories, and tips/techniques for getting the ideas across to the audience/participants. Once I even attended the same topic by the same speaker 2 days in a row, and I learned something new/different the second time around! (It was a Cem Kaner talk when he was in our area a few years ago.)
Yes, I gained an appreciation of Story Mapping yesterday. More importantly, I learned a new anecdote from the speaker - one that got me thinking. At one point, Mark answered a question about managing a large backlog on a Scrum/Kanban-style (information radiator) board. The problem with really large backlogs of stuff to do (likely anything with more than 100 items in it), is that the items near the bottom become meaningless over time. You will probably never get to them because something more important always comes up.
Mark told us a quick story about Taiichi Ohno, the father of Lean Manufacturing. I looked up the story and found a reference to it here. In 1984, Ohno was interviewed about the history of development of the Toyota Production System (which later became Lean Manufacturing). At one point in the interview that discussed work standards and the early stages of doing kaizen (continuous improvements), Ohno said:
This is an interesting point. When I work with Testing teams, I sometimes hear the right words but see the wrong practices.
For example, I often hear testers talking about Risks. That's good. They do a risk assessment and create tests for those risks but never revisit the risks. That's bad. Over time, those original risks become salary thieves. Are they still relevant? Have things changed? Are you wasting your time to put effort into managing the testing of things that are so out of date that not even the developers/programmers use them to create the code you are now testing?
What about test cases? And Regression Testing? How many of those tests check risks and ideas that are no longer relevant? How many of them are salary thieves, taking away our precious time that we could have spent finding more relevant bugs and identifying new risks to stakeholder value?
What about the tools that we use to support and manage our work? How many of them have sunset clauses tied to the creation dates of artefacts? For example, automatically identifying requirements in a backlog, test cases in a repository, or personas in a reference area that are "old" (by some definition) and therefore potential risks of losing value.
Right. I don't know any software development tools that do this right now. It seems like a perfectly reasonable feature to look for though.
When we think about the "dinky" Scrum/Kanban board with pieces of paper identifying bits of work, we realise that ageing has a very real effect on paper. We see the paper get old over time, the ink start to fade. If we have to rewrite a card or sticky note, we should be asking: what is the value of keeping it on the board at all?
With electronic tools, things are a bit different. Electrons, unfortunately, don't show signs of wear over time. Unless we specifically ask a computer to keep track of information like this, we are likely to forget about it because of all the other things we have to do and keep track of.
Physical board: 1, Electronic tools: 0.
So. What are your salary thieves?
What are some ideas you have for avoiding them?
I love learning and take any opportunity I can to hear different speakers present on topics that I think may be of value. Sometimes I even attend the same talks and workshops when they are done by different speakers so that I can understand differences of style in presentation, stories, and tips/techniques for getting the ideas across to the audience/participants. Once I even attended the same topic by the same speaker 2 days in a row, and I learned something new/different the second time around! (It was a Cem Kaner talk when he was in our area a few years ago.)
Yes, I gained an appreciation of Story Mapping yesterday. More importantly, I learned a new anecdote from the speaker - one that got me thinking. At one point, Mark answered a question about managing a large backlog on a Scrum/Kanban-style (information radiator) board. The problem with really large backlogs of stuff to do (likely anything with more than 100 items in it), is that the items near the bottom become meaningless over time. You will probably never get to them because something more important always comes up.
Mark told us a quick story about Taiichi Ohno, the father of Lean Manufacturing. I looked up the story and found a reference to it here. In 1984, Ohno was interviewed about the history of development of the Toyota Production System (which later became Lean Manufacturing). At one point in the interview that discussed work standards and the early stages of doing kaizen (continuous improvements), Ohno said:
I tasked the shop floor leaders with regular kaizen of work methods and revision of the standard work, telling them "If the kanbans do not change for one month you are salary thieves."During Mark's workshop yesterday, he mentioned the "yellowing of paper" [on the backlogs] as an indicator of "salary thieves." He was tying this point back to the question: how long has an item been sitting on your backlog? Maybe they are salary thieves.
This is an interesting point. When I work with Testing teams, I sometimes hear the right words but see the wrong practices.
For example, I often hear testers talking about Risks. That's good. They do a risk assessment and create tests for those risks but never revisit the risks. That's bad. Over time, those original risks become salary thieves. Are they still relevant? Have things changed? Are you wasting your time to put effort into managing the testing of things that are so out of date that not even the developers/programmers use them to create the code you are now testing?
What about test cases? And Regression Testing? How many of those tests check risks and ideas that are no longer relevant? How many of them are salary thieves, taking away our precious time that we could have spent finding more relevant bugs and identifying new risks to stakeholder value?
What about the tools that we use to support and manage our work? How many of them have sunset clauses tied to the creation dates of artefacts? For example, automatically identifying requirements in a backlog, test cases in a repository, or personas in a reference area that are "old" (by some definition) and therefore potential risks of losing value.
Right. I don't know any software development tools that do this right now. It seems like a perfectly reasonable feature to look for though.
When we think about the "dinky" Scrum/Kanban board with pieces of paper identifying bits of work, we realise that ageing has a very real effect on paper. We see the paper get old over time, the ink start to fade. If we have to rewrite a card or sticky note, we should be asking: what is the value of keeping it on the board at all?
With electronic tools, things are a bit different. Electrons, unfortunately, don't show signs of wear over time. Unless we specifically ask a computer to keep track of information like this, we are likely to forget about it because of all the other things we have to do and keep track of.
Physical board: 1, Electronic tools: 0.
So. What are your salary thieves?
What are some ideas you have for avoiding them?
