Back in January, I wrote a Kanban Sidebar for an upcoming book on Agile Coaching by Rachel Davies and Liz Sedley. The book is now out in beta, and I have updated the sidebar as part of the review process. I found it interesting to see how my thinking has evolved over the last few months.

A Kanban System for Software Development focuses on visualising work as it flows through various stages of transformation in a value stream, with limits on work in progress at each point. This enables a team to see bottlenecks and constraints in the system such that they can continually strive to improve the system and increase productivity and performance.

This focus on flow renders task estimates unnecessary, making task breakdown an analysis and design activity. Prioritisation, planning and releasing still occur regularly, forming a natural cadence around each activity. The team no longer estimates what it will deliver within a time-box, instead forecasting how much will be delivered from known cycle-time and throughput information.

A team setting a limit of three features being in progress at a time will concentrate on maximising the flow of those features to completion, while deferring time spent on new features until they have spare capacity. The prioritisation, analysis and planning of new work is therefore triggered “Just In Time”, as opposed to being scheduled with an iteration planning meeting. Prioritisation is based on the teams previous capability to deliver features, weighed against future business goals and objectives.

Kanban is the Japanese word for “visual card” and was the name given to the tool used to operate the Toyota Production System. A Kanban System for Software Development will often use an index card as the kanban token limiting work in progress, and a token might represent a unit of value such as a User Story. A Kanban System is, therefore, able to manage the flow of single pieces of customer value through the development system from idea to release.