Kanban is a simple method that aims for just-in-time delivery while not overloading the team members. It is similar to scrum in that the goal is to deliver maximum value at the end, but it is much more flexible than scrum.
Kanban was not invented by the software development community. In fact, it has its origins in manufacturing processes at Toyota, and it has wide usage in other spheres. There are no strict procedures that you should follow, and no strict way you should implement and use kanban; it is, rather, a set of principles and practices, and you can choose from these practices to suit your needs. But there is one most-often used implementation of kanban in software development that includes the usage of a kanban board, consisting of columns representing stages of work, and tasks.
Columns represent the state of a task in the development process. The simplest example consists of three columns: “To Do,” “In Progress,” and “Done.” So, tasks are added to “To Do,” moved to “In Progress” when development starts, and considered “Done” when moved to the last column. But of course, it could be more complex:
“Backlog” → “Defining Specification” → “Ready for Development” → “Development” → “Code Review” → “Testing” → “Deployed” (→ “No one really uses it” → “Completely Removed”).
Every column can have subcolumns; for example, “Development” can be divided into “Planning” and “Coding”; “Testing” can be divided into “Unit Testing” and “Integration Testing,” and so on. Columns might be dedicated to specialists, if appropriate. The team defines the columns and stages according to its needs. Per the “pull” philosophy, tasks should only enter the workflow when the demand for them is immediate.
The purpose of this board is to visualize the workflow, which is the first key practice in kanban. In fact, kanban can be done without a board at all! It could be a simple list of tasks in a Google sheet with different background colors indicating the state of the task, or it can be Gantt charts, diagrams, tables… It could even be a set of buckets in your office, where each one represents the state of the task, and where balls are used as tasks. Just visualise the workflow and provide transparency to the whole process.
Another important principle is to reduce the batch size of your efforts. Simplified, this means avoid multitasking. That can mean reducing the volume of tasks you work on at the same time. If you have three designers in a team, the team might set the maximum number of tasks in the “Designing” column to three.
Like scrum, kanban also sees the team as the most important figure in the process. But it doesn’t suggest roles as scrum does, and you may keep the existing roles to avoid making changes to your existing process. The same stands for continuous improvement: Kanban generally encourages you to learn and improve continuously, but does not prescribe a specific event just for that process, as does scrum’s Sprint Retrospective.
« Back to Glossary Index