The following article is part of the self-preparation for the modern BVOP® Scrum Master Certification program.
The Kanban methodology helps manage product development, focusing on continuous delivery and not overburdening agile software development.
- The purpose of the Kanban system
- Kanban is an Agile style of working
- The Kanban Board
- Scrum Board
- The main differences between Scrum and Kanban
- Kanban or Scrum
Kanban is a Just in Time (JIT) production planning system. Taiichi Ohno, a Toyota industrial engineer, developed Kanban to improve production efficiency. It is one of the methods of achieving JIT.
Kanban is perceived as a useful tool for maintaining the manufacturing system as a whole, and a great way to encourage improvement. Problem areas are highlighted by measuring execution time and cycle time of overall process steps. One of the main advantages of Kanban is to set a maximum limit for work that is in the process of being created and completed (Work in Progress).
The purpose of the Kanban system is to limit the accumulation of surplus stocks at each point of production. Exceeding a limit means inefficiencies that must be resolved by teams and management.
In software engineering, Kanban is used to limit the work in progress. These limitations aim to reduce the number of defects and the stress on teams and increase their focus. By introducing work limitations and minimizing obstacles, overall productivity should increase.
Kanban is a popular Agile working style used in software development. Kanban requires team capacity communication in real-time and full transparency of work. The tasks of the teams are visually presented on a Kanban board, which allows the team members to see the status of work at any time.
The Kanban Dashboard, or Board, is an Agile project management tool designed to visualize work, limit Work in Progress, and increase efficiency. Kanban boards use cards and columns to help teams engage with the right amount of work.
The "card" is a visualization of the "task" (the effort it takes to get the job done). It may contain the name of the work required (effort), a description, and other elements such as the "type" of the effort.
The "column" is a very simple visual vertical column containing cards.
Each column should contain cards but in a limited amount.
Tasks in progress (Column 1)
Tasks in a testing (Column 2)
Waiting for approval (Column 3)
|Task 1||Task 2||Task 7|
|Task 3||Task 4|
|Task 5||Task 6|
In the example table above, the logic stated is as follows:
The first column 1 lists the cards (work, tasks, efforts) that are currently being developed.
In the second column, some cards (tasks) are already completed but expect quality control specialists to confirm that there are no problems with them.
The third column contains the cards, which are tested for defects and are awaiting approval from someone.
These columns are just an example. The team invents their names, determines the number of cards and columns that the Kanban dashboard will have.
Each column represents some logical steps in the workflow.
There can be four, five, or even more columns in the dashboard if each task has to go through every stage that the team has defined.
It is logical that the more steps there are in the process, the more complex is the team workflow. An optimal workflow requires a balance between performance and simplicity.
These are the cards that are currently being developed.
Kanban puts a limit on the workflow by simply restricting the number of cards that can be stacked in a single column. If a wooden board on which notes are attached for each task is used, the column cannot be infinitely high. Also, the whole team should know how many cards (tasks) are allowed in one column.
If Kanban Board software is used, the software itself may limit the number of cards.
The teams decide for themselves how many cards (tasks) are in the columns, based on the amount of work that can be done.
The teams decide whether to use the Kanban method of work. It will be a mistake if such a decision is made by senior management, especially if there is no in-depth knowledge of the day-to-day work of the teams, their processes, needs, problems, competence, weaknesses, and strengths.
The same goes for using Scrum. Teams discuss how and most of all, why to use it. It will be practical to experiment and go through different ways of working in order to decide which one is best. Sometimes a working method will no longer be helpful, and decisions can be made to change it.
Work in progress includes not only the currently executed tasks but these for testing and approval.
In Scrum, Agile, and all other work methods, this idea must be kept in mind.
When a card is completely finished, it must be removed from the dashboard and if necessary a new one added in its place.
When working with Scrum, the board usually has no limit on the number of tasks. The team plans the number of "cards" (items, tasks) during the Sprint Planning meeting.
Whether working with Scrum or Kanban, teams must regularly check performance. Do the teams handle the planned tasks? Are there too many, too few cards to place, or is workload precision achieved?
Validation and change are at the heart of the whole Agile culture.
Scrum has sprints and roles (Scrum Master, Product Owner, and Development team).
There are no sprints or roles at Kanban.
In both cases, the teams are self-organizing.
The Kanban board is used continuously throughout the product development lifecycle by simply replacing the cards.
At Scrum, at the end of each sprint, the dashboard is renewed. No new cards (items) are added until the end of the sprint. Cards are also often found in columns and have a corresponding status.
When it comes to Agile practices, some organizations explicitly use Kanban for some of their projects. Others explicitly prefer Scrum.
When an organization states out loud that it is using Kanban, this is likely due to some of the following factors that are unrelated to the Kanban practice itself:
- The organization does not have enough staff capacity, and the teams are too small.
- The organization does not have sufficient management experience.
- The organization aims to save money.
- The organization and teams practice micromanagement. These manifestations can often be generated by senior management.
Moreover, these probable causes are even more likely if the Kanban approach is practiced in organizations that do not clearly express Agile production methods or do not have a transparent Agile culture.
There is always the possibility that an organization will use Kanban for the intended purpose, and not for the aforementioned negative reasons.
Using Kanban to organize the work and help the team means a high Agile culture, as well as great discipline, self-organization, and competence.
Kanban is a workflow in which there are no "sprints". Kanban is a flow of work that is ongoing.
BVOP focuses attention on the fact that teams can feel exhausted over time.
The lack of some periodicity and cycles can bring about the feeling of endless and unfinished work. Energy and motivation can be reduced.
Scrum offers sprints. These are equal intervals of time that can psychologically satisfy the need for a beginning and an end.
The periodicity and the end goal of a sprint can bring a sense of accomplishment and completion. Such recurrence helps for optimal mental dynamics and satisfaction with the goal achieved.
BVOP recommends that the choice between Kanban or Scrum is made after both work methods are tested. A periodic opinion review of all team members can help decide whether a migration to another style of work is necessary.
The following issues related to chapter "Kanban" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of January 30, 2023, 11:44 am
|0||What is a card?||60 sec||SM, PO|
|1||Work In Progress.||60 sec||SM, PO|
|2||Kanban is an Agile style of working||60 sec||SM, PO|
|3||Kanban or Scrum||60 sec||SM, PO|
|4||Scrum Board||60 sec||SM, PO|
|5||Kanban may exhaust teams||60 sec||SM, PO|
|6||The purpose of the Kanban system||60 sec||SM, PO|
|7||Kanban the right way||60 sec||SM, PO|
|8||Kanban is a flow of work that is ongoing||60 sec||SM, PO|
|9||The main differences between Scrum and Kanban||60 sec||SM, PO|
|10||What is a column?||60 sec||SM, PO|
|11||The Kanban Board||60 sec||SM, PO|
Comments from the BVOP™ community on "Kanban"
Comparisons between Kanban and Scrum
Kanban is a system developed by Toyota's industrial engineer Taiichi Ohno, which seeks to improve efficiency in the planning of continuous production or so-called Just in Time (JIT). Kanban is an effective tool for constant maintenance of the flow of tasks and their constant improvement. And at the same time, teams don't get more work than they can do. All this is done with two of the principles of Kanban and they are visualization of work and establishing a maximum limit of work that is in the process of creation and completion (Work in Progress).
This model of operation is often compared to Scrum, which is wrong. Scrum is a framework made up of roles, events, and artifacts. Scrum gives you the independence to determine the working methods that would suit your specific circumstances. Scrum divides the phases of your project into small pieces that can be completed by different teams in an organization over a period. These pieces of time are called Sprints.
Although the two terms are different, let's still point out the similarities and differences between Scrum and Kanban. Both frameworks use so-called dashboards to visualize tasks in the work cycle itself. Scrum has the so-called sprints or more precisely certain periods in which the progress of work is observed. Sprints length can vary from 1 to 4 weeks, depending on the project itself. Additionally, the team members organize meetings on a daily, weekly, monthly basis, during which the tasks and problems are discussed. Also, Scrum includes roles such as Scrum Master and Product Owner. When working with Kanban, sprints, and roles do not exist. Also, the tasks are limited because it is believed that work is more efficient and reduces the risk of defects. When operating with Scrum, the number of tasks is not limited.