While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board, or team-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?
A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.
A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.
A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.
By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.
Karl, THANK YOU SO MUCH for pulling this succinct view of Kanban together. I am particularly thankful that you emphasize that value and flow must be considered (along with WIP limits) and made visible to truly declare that you are doing Kanban. THANK YOU!
Can I ask you to comment about cycle time as well? That is: are you doing Kanban if you are not tracking cycle time (or is this what you fourth paragraph addresses?) I have this sense that all the “continuous improvement” in Kanban on visibility, WIP, value, and flow feed an overall goal of continuously reduced cycle time for delivering these stories/MMFs/vanilla reqts.
And as long as I am commenting, I will just throw this out there. I have been talking about flow, pull, and innovate and reduced WIP for a while. I just never figured out the close close correlation with Kanban. For me, it isn’t so much a new mental model as it is one that reinforces and adds information/improvements on what had been a personal (and seemingly useful) model.
Thanks!
Jean
Most “story walls” I’ve dealt with have had stages for work being prepared and work ready for release, though I would agree that most of the focus is on the current work in build/test. I would say that the key aspect that “Kanban Systems” has added is explicitly calling out the capacity of each stage and using that to limit WIP. Explicitly managing to capacity for any kind of hand-off is what tends to be missing from teams I see.
Very nice description!
[…] has offered this post explaining the difference between a Scrum task board and a Kanban […]
Karl,
I’ve commented on this post here [http://www.agiledesign.co.uk/scrum/task-boards-and-kanban-boards/].
I wonder if you are trivialising the use of task boards by many practitioners, the principles of limiting WIP (less explicitly) and exposing a wider view of the value stream is not uncommon in Scrum teams.
Regards
Dave.
[…] has written a really great post on why kanban isn’t just a task board in response to the questions being asked in the last week on the kanbandev yahoo group about what […]
I agree with Dave Draper. Comments like “This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.” only serve to show that the Scrum teams you have worked with/witnessed did a lousy job of doing their work.
All good ScrumMasters (and Scrum team members) insist on “story swarming”, to the point where good teams I’ve worked with do not even task out a story until they are all ready to work on it. WIP is limited to one task per person or pair at any given time.
Further, the Scrum taskboard is not a fixed or limited thing. Teams use it to display all kinds of information, as relevant to their work and the goals of the organization. There is nothing to stop teams displaying backlog items-in-waiting or completed stories ready for release. The only restrictions in Scrum are the imaginations of the participants. Saying “Scrum doesn’t do XXX” is just a cop-out. Scrum doesn’t do anything. People do things.
I guess you can call what you do “Kanban”. I just consider it part of Scrum. Seems simpler to me.
But having said all that, I have to add that I think Karl Scotland is awesome, and if you ever get the chance to do his rhythm workshop — go for it! 🙂
As a person trying to use Kanban for backlog management specifically and for identifying areas of optimisation in general – I have to say, from experience, Kanban is not just a taskboard.
Infact the board is perhaps the last (and most visible) part of a system that requires a bit of thought to construct and even more to keep adapted.
And I would wager if you had a team that
a) intereacted really well;
b) tuned to team-optimise
c) with a high cross functionality
you could without a visible board and it would be a better Kanban system than most!
And with all due respect Tobias – Good Scrum is not Kanban by another name. The mindset (I think) you need for Kanban is slightly but significantly different. Different enough that a good Scrum team may struggle to work well within Kanban even.
Maybe you are like Neo from the Matrix, Tobias, and you see Scrum in everything and in a few years time we will all realise is just Scrum done well – such is the fate of visionary 🙂
Mike
[…] Isn’t Kanban Just a Task-board? « AvailAgility (tags: Kanban) […]