Karl Scotland – Using Agile to Deliver Value
Posts tagged Sidebar
A Kanban Sidebar – Take 2
Jun 22nd
Posted by Karl Scotland in Agile
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.
VN:F [1.9.17_1161]
A Kanban Sidebar
Jan 9th
Posted by Karl Scotland in Agile
I was kindly asked by Rachel Davies and Liz Sedley to write a sidebar on kanban for their upcoming book on Agile Coaching (no links yet). Here’s what I put together:
An alternative approach to planning work in time-boxed iterations is to use a Kanban system.
A Kanban system uses physical tokens to limit work in progress and to pull work as single units. This helps create a one piece flow, where features of value move through the system individually, rather then being grouped into batches. Kanban is the Japanese word for “visual card”. When applying a Kanban system for software development the Kanban token can be an index card representing a user story.
A key characteristic of a Kanban system is that it limits the work in progress in order to improve cycle time, reduce investment in inventory and enhance teamwork. For example, if the team sets a limit of only three user stories being in progress at a time, the team can exclusively focus on those three stories, and defer analyzing and planning new stories until there’s space in their queue. Instead of having an iteration planning meeting, the team simply waits until they complete one of these three stories. Now they have the capacity to pull the next most important story, as prioritized by the customer.
Following this approach, task estimates are no longer necessary, and any task breakdown becomes a purely analysis and design activity. Releases can still happen early and often, but a kanban system allows the planning and release cadences to be de-coupled. The customer might prioritize user stories on a weekly basis but releases might only happen fortnightly, and releases contain whatever is ready, rather than a planned set of stories.
Instead of the team committing to deliver each feature within a time-box, the team commits to delivering features at an agreed throughput (rate of stories per release) and mean cycle time (how long each story takes to get done). These agreed metrics are arrived at by measuring the team’s performance over time.
Applying this approach with a team that was using Scrum, but struggling to deliver reliably, allowed a more natural process that enabled the team to improve and become more successful.
VN:F [1.9.17_1161]
