I’m busy finishing the very last chapter of Kanban from the Inside. It’s about the last step of the STATIK implementation process, namely rollout. I treat rollout as a long-running, open-ended process that is very amenable to visual management. In fact, it seems to be hard to find a significant Kanban implementation these days that doesn’t maintain some kind of visual management system in parallel with the main delivery system, devoted to change, problems, out-of-the-ordinary dependencies and so on.
With Kevin Murray of Valtech, I’ve had success with variants of what we call the “Problem Board”:
Anyone can add new problems to the input column on the left. After triage and ownership assignment, in-progress problems move vertically between the daily and weekly areas according to the amount of time we wished to devote to discussing them. Once “Sorted”, problems are “Closed” once we are sure that they aren’t going to resurface, decisions have been logged, and so on.
The board we’re using right now board is similar, except that we have conventional swim-lanes that span the board horizontally, each for a defined work stream. Unfortunately this means losing the daily/weekly split, but with a complex delivery to manage, it is more important that we’re able to organise problems this way.
Clearly, it is very much about change management. It emphasises two things that are important to me: agreement (one of the nine values), and validation (which I describe in the chapter on customer focus). Separating qualitative validation from quantitative verification seems very smart too; typically teams will be happy to confirm behaviour changes long before it is possible to confirm any significant performance improvement.
Next week I’m at the Kanban Leadership Retreat in Cascais, Portugal. I would be very pleased to discuss STATIK and compare change management kanban systems there. General purpose (like mine), or change specific (like Jeff’s)?