Kanban has its roots in lean manufacturing introduced by Toyota and was brought to software development by David J. Anderson. Kanban is a visual process management system and helps organisations to improve their existing processes. So in contrast to Scrum, Kanban is not introducing a new process but rather visualize an existing one and helps to improve it. That often faces less resistance and fear within an organisation than a complete change to a Scrum.
Here an example of a Kanban board that shows how work is done in a development environment. Someone (e.g. a product owner) defines work items which should be done next.
As soon as someone in the team has time, she would pick it up, analyse and break it into smaller tasks. She would also indicate with a little Avatar on the work item that she is working on it. The team has defined that something is properly analysed as soon as all required tasks are defined and a second person had a look at it. The item will then be placed in the column “Done”. Here the limit of work in progress (WIP) is 3, so no more than three items have to be in the “Analysis” column. This makes sure that not too many things are somehow in progress at the same time but also that not too much stuff is prepared up front and piled up.
People with development skills then pull such work items in and work on them. They mark the tasks on which they are working also with little Avatars and they would mark impediments with red stickers. Everything that gets done, cross-checked and unit-tested will be placed in “Done”. Work in Progress (WIP) limit in this column is 3.
The next step will be performed by someone who has a look at a work item from a users perspective. Also here, an explicit agreement makes sure that just work items are placed in “Done” if they are properly checked. WIP limit is 2.
People with special skills in putting new features into production will do so by grouping features to bundles which go into production.
Swarming around Bottlenecks
So what would happen if development has three things in “Done” and their work in progress (WIP) limit is therefore filled? Obviously there is a bottleneck at accepting work items. Because this is now visible to everyone, team members start to help out people working on acceptance testing. As an example a developer could support a test specialist by writing automated tests or preparing test data. Helping out each other and fixing bottlenecks or blockages it on of the major topics in Kanban.
The philosophy of Kanban is based on six core principles:
1. Visualize – visualize the flow of work items makes it easy to spot bottlenecks, blockages and dependencies to external sources.
2. Limit Work in Progress (WIP) – that implies a change to a pull system where every step in the progress is limited to a small number of work items. If this limit is reached, a new work item can not be pulled in before others haven’t been pulled out by a following process step.
3. Manage flow – Work can be monitored, measured and reported. That helps to see if changes on the progress have positive or negative effects.
4. Make policies explicit -define what has to be done to declare something as done.
5. Implement feedback loops – not only on team level but also on operational level (reviews).
6. Improve collaboratively, evolve experimentally – small continuous, incremental and evolutionary steps that stick.
A very good introduction can be found here at InfoQ: Kanban and Scrum – making the most of both
We are also running an Agile Practitioner’s Meetup where we had the pleasure to welcome Dan Brown (aka Kanban Dan) to give an introduction to Kanban and how does forecasting works. Have a look at the videos.