Kanban is a scheduling system for work items that I’m exploring further.
I heard about it from several sources, but didn’t focus my attention until earlier this year.
I highly recommend Kanban by David J Anderson. He is someone who is a practitioner as well as an author, which really helps in his explanations.
His book is broken up into four sections:
- Benefits of Kanban
- Implementing Kanban
- Making improvements
Each section is filled with references to industry theory, both in software and manufacturing, and liberally sprinkled with case studies from his own companies.
One part that really resonated with me is that introducing Kanban layers over the top of an existing development process. That is, you do not need to change your current process. Instead, the focus is on scheduling the work that goes into the process.
This makes Kanban a logical fit for processes such as Agile, as well as more traditional iterative or even waterfall development projects.
From the book:
Kanban is an approach that drives change by optimizing your existing process. The essence of starting with Kanban is to change as little as possible. You must resist the temptation to change workflow, job titles, roles and responsibilities, and specific working practices. Everything from which the team members and other partners, participants, and stakeholders derive their self-esteem, professional pride, and ego should be left unchanged.
The main target of change will be the quantity of WIP and the interface to and interaction with upstream and downstream parts of your business. So you must work with your team to map the value stream as it exists. Try not to change it or invent it in an idealistic fashion
As with any new area of knowledge, I feel like I’ve only scratched the surface. The interesting part is the range of topics to explore further, such as Deming’s writing.
It is also helpful to be working with teams that have already implemented many of the techniques from Kanban process, and to hear first hand stories of their implementation.