This is followup #3/n to my LSSC12 debrief.
I’ve put the slides for my scheduled LSSC12 talk “Who moved my risk?” up on slideshare.
- There are risks inherent in each piece of work; some of these are unique and specific to that piece of work but there are some easily-recognised varieties of risks based on time and expectation. Time does funny things to priority – it has a habit of making a nonsense of any priority scheme that is fixed in time. And don’t think that risks based on expectations aren’t real risks!
- There are additional risks that relate to the (in)capability of the system (lead time and throughput performance/predictability especially) when faced with a volume of work. Capabilities differ between systems, but less capable systems can still offer high capability on limited subsets of work, those subsets perhaps based on the varieties of part 1 above. It is a “killer feature” of Kanban that we can easily make variety explicit so that good risk-based judgements can be made within teams on a day-to-day basis. Furthermore, it is relatively straightforward to design resilient kanban systems that consistently deliver good results in the face of variety, something that many systems deal with rather poorly.
- Don’t get so focussed on the system that you can’t step outside of it to see what’s really possible. Avoid “backlog driven development” (I’m sure you can work out what this means) – quite apart from its grim economics, you need to be spending time with different kinds of stakeholders concentrating on working out what’s important – using imagination, thinking the unthinkable (good and bad), filtering out the noise, creating good possibilities and heading off the bad ones. To put it another way, backlog grooming (on steroids or otherwise) is no path to success. But there’s good news: limit your WIP, shrink your backlogs and work on growing shared understanding outside your system and your risk will seem very different. Who moved your risk? You did!
Watch out for the “triple” win of improvements that are good for the customer (effective), good for the organisation (economic), and good for the team (humane). To my mind, “effective, economic, humane” in my estimation beats “better, faster, cheaper”; less catchy perhaps, but where’s the humanity in the more traditional test?
How did it go? That’s quite a lot for a 45 minute slot and I should probably have pruned it more. Also, I made a tactical error in thinking that we could do an interactive exercise before we had all warmed up. Lessons learned. Despite those improvement areas the feedback was pretty good and sufficient people were kind enough to tell me of the useful thoughts they took away that I’m happy enough with how it went.
I’ll write up my unscheduled talk on portfolio level problems soon.