Here are a few things I have observed about kanban that I didn’t know when I started:
- Although kanban roughly translates to “signal card,” the cards on a team wall are not the signals. The empty spaces are the signals (that you have capacity). The fixed capacity is represented by the spaces/slots, and not the cards themselves.
- It’s okay to distinguish cards in a queue as being “done” and not done. Only in a perfect cadence will you not need the concept of (and corresponding way to identify) some items in a queue being “done” and some not.
- Many value-stream maps show the customer need at the beginning of the cycle, but it’s useful to visualize the customer need at the end (perhaps as a circle) in order to show how demand is pulled through the system and not pushed.
- Cumulative-flow diagrams and run charts (showing cycle time for each story) are the most powerful and helpful metrics to use, and you can implement them by hand as big visible charts. They don’t need to be created in electronic tools.
- Be sure you visualize the entire value stream (“concept to cash,” including deployment) somewhere or you will simply optimize on your development cycle.
- To visualize a minimal marketable feature moving, create an MMF horizontal lane above the normal story cards or simply make a temporary horizontal lane for that feature.
- You don’t have to be “advanced” in agile or any other philosophy/methodology to do kanban. I used to believe this, but David Anderson (et al) have been helpful in conveying the idea that you start by modeling and making visible what you already do and improving from there.