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?
Nice post ... I agree I've seen too many cases of faded/dusty post-its on the wall. If I took nothing else from last night it was the conscious awareness that will now have me targeting those items in a different wayReplyDelete
Very interesting article.ReplyDelete
Maybe our electronic tools should connect the 'last_edited_on' (date and maybe time information) of a backlog item to its contract, when displayed: The older the item, the lower the contrast.
If you're daring & bold, you could auto-delete items, when the contrast falls below some threshold.
In many places people seem to be afraid to clean up old stuff for some reason. It seems to me that 'It might be useful or necessary in the future' represents a powerful force that we need to deal with. (Not only in our professional lives BTW.)
when the glue on the back of a post-it dries, the note falls to the floor - a suggestion that the task written thereupon really wasn't of high priority at all.ReplyDelete
I love the creative ideas and yes the drying of the sticky note is a good sign or perhaps just poor quality stickies.ReplyDelete