I attended a two-day Kanban training session in Seattle this past week - the first of a series of public courses given by David Anderson's consulting group. I had already read Anderson's book of the same name (my review), and I have done a Kanban project with a group of engineers (not IT). I have been building my own thoughts about how Kanban can fit into some of the other work I have done. This course was a great opportunity to hear from experts, listen to how others see this fitting into their environments, and get reminded of the basics of Kanban.
Kanban is a mechanism to manage evolutionary change in organizations. As such, the core principles reflect this:
- Start where you are now.
- Agree to incremental change.
- Respect all the current systems.
As the evolutionary change happens, the teams change only those things that limit their ability to get things done. The other parts of the system remain in place.
I particularly like this take on creating improvement, particularly at the outset. The only great fanfare has to do with putting a whiteboard up on a wall. (Yes, there are some machinations in the background.) A sample of this thinking is the statement that was repeated several times: the first board is not going to be "right." Be prepared to change it several times before the team finds the processes that work for them. Several other participants were very interested in this thinking, as they reflected on their experiences of sweeping up-front changes that were difficult to implement.
Along with these core principles are the five core practices of Kanban:
- Visualize workflow (with the Kanban board)
- Limit WIP (without WIP Limits you don't get Pull, a key aspect of Kanban)
- Manage & measure flow (cumulative flow diagrams)
- Make the process explicit (the board; simple rules)
- Improve collaboratively using models (ideas come from the team, and use TOC, Deming's profound knowledge, Lean, Cynefin, OODA)
These practices also reflect some of the things that have to happen in the background before starting the board. And a lot of the background work should sound familiar to people who are involved in other continuous improvement projects. Understanding the workflow gives you the lanes and columns on the board. The WIP discussion can only happen if you get a feel for the current flow of work in the system: what variety of work is there; how frequently does it arrive; how much variability in the demand. A key point about WIP Limits: if you don't have limits, the system can devolve into a push system that takes on anything the stakeholders throw at it. With WIP limits, there will be some point where work is requested but cannot start due to the limits. The conversation that happens at that point is the start of the evolutionary improvement. (Why can't we get more through the system? What's limiting our speed? Why are things getting stuck? etc. etc. etc.)
I liked the mention of the Lean Decision Filter. When making decisions about what to do there are two key elements: Value trumps flow. Flow trumps waste elimination. (This makes me think about one the Kanban simulation we played in the training - simulation from GetKanban.com. I wonder if I would have acted differently with these in front of me.)
Obviously, Kanban takes its name from the Japanese term that Lean uses in manufacturing. The term is "card" or a "visual signal" of something. It might be a sign that says a store is open (I happened upon a photo book of Japanese shop signs in my explorations for books on kanban). In Lean manufacturing, the kanban cards are a mechanism used to create pull through a production line. If the card is there, produce that item. And in Kanban, the card works a little differently, but the result is the same. The card is pulled through steps of a workflow, with the most generic form being Ready, Doing, Done. WIP Limits are used to control the total number of cards in the system. You can only pull a new one onto the board when a previous item is completed. Some boards place limits on each column. Others place limits on the number of given types of cards (project cards; maintenance cards; etc). I like that Kanban doesn't proscribe what the boards should look like. It is those principles and practices that have to work in the context of the organization doing the board. One thing I have noticed is that it is very easy for people to get stuck on building the board in a specific way, once they have started down a specific path. This is a good reminder that it doesn't have to be that way.
The idea of balance came up several times throughout the training. The main idea is that Kanban helps to balance Capability against Demand, but there were some interesting trains of thought. One is the word capability, instead of the more frequently used capacity. Capacity is often more of a raw calculation and has some very machine-like assumptions. Capability seems to fit with the idea of knowledge work: what are we capable of doing; how does it change with the context? In the end, of course, the measure is the same: how much can we get done. The other part of the discussion is the demand side of the balance. Rather than treating demand as a black box that comes from "out there" a lot of the collaboration that Kanban creates is a connection to the stakeholders. In order to improve the system, Kanban will encourage you to learn more about your customers, so that you can anticipate their needs. The claim is that this is somewhat unusual for organizations, which often want to focus only on their own work. But in order to improve, an organization can only get so far with an internal focus. They will need to shift their view to their customers: both from the perspective of how they serve their customers, and what the customers' needs are.
All disciplines and management approaches draw from a wide array of influences, whether they acknowledge them or not. Kanban makes its influences explicit - it is also an approach that is open to other ideas, which may be one of the reasons I enjoy it. The book and the training session mention Deming, Taiichi Ohno, Boyd, Seddon, and many others. A new connection in the Kanban community is the Cynefin framework from Dave Snowden and Cognitive Edge. I'm familiar with it, based on Snowden's work in the knowledge management community, and there have been discussion of Cynefin in the Theory of Constraints community. Local Cynefin aficionado, Steve Holt stopped by and give his take on the Cynefin framework and provide his perspective on how Cynefin can help conceptualize where Kanban fits into organizations. Kanban operates on complex systems, using the board to sense the status and it provides a mechanism to guide responses to help improve the system. (There's more to it than just that, of course.)
The training essentially followed Anderson's book, which makes sense. I know that he is in the process of writing a follow-up, and I would have liked some of that knowledge to be part of the course. (Maybe it was - like the Cynefin ideas.) The instructor was Dominica DeGrandis, who was one of the people involved in the Corbis implementation discussed in Anderson's book. We also had Dragos Dimitriu in the room - he was also featured in the book as the lead for the Microsoft implementation of Kanban. It was interesting to hear his perspective on both his Kanban experience as well as his general management experience and perspective. (Dragos is now at Avanade consulting.) The other attendees also contributed a lot of their own experience in project management, Scrum and Agile to the session.
I know Kanban can get started without the training - clearly, the first implementations haven't needed the book. I have experienced it, and I know several others that are doing the same outside of the IT industry. That said, the training was a great reminder and a bit of a wake-up for me. And an excellent reminder: your implementation doesn't need to be perfect. You just need to get going and commit to improving as you go.
Update: Clarified point number 5 in the core practices.