The Kanban methodology helps manage product development, focusing on continuous delivery and not overburdening agile software development.
Kanban is a Just in Time (JIT) production planning system. Taiichi Ohno, a Toyota industrial engineer, developed Kanban to improve production efficiency. Kanban 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
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 reduce and limit the tasks that teams work on. These limitations aim to reduce the number of defects and the stress of teams and increase their focus. By introducing work limitations and reducing obstacles and defects, the overall productivity of the teams should increase.
Kanban is an Agile style of working
Kanban is a popular Agile style of working today 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 in a Kanban board, which allows the team members to see the status of work at any time.
The Kanban Board
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.
What is a card?
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.
What is a column?
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 are already ready but expect quality control specialists to confirm that there are no problems with them.
The third column contains the cards. They are tested for defects and are awaiting approval from someone.
The columns in this example are exemplary. The team invents their names. The team also determines precisely how many cards the columns will contain and how many columns 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 any stages 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.
Work In Progress.
These are the cards that are currently being developed.
Kanban puts a limit on the workflow in a process by simply setting a limit on the number of cards that can be stacked in a single column. If a wooden board is used on which notes are attached for each task, the column cannot be infinitely high. Also, the whole team should know how many cards (tasks) there should be maximum in one column.
If Kanban Board software is used, the software itself may limit that no more cards can be added than allowed.
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 and order are descended by senior management, especially if there is no in-depth idea 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 options, what, how, and most of all, why use it. It will be useful to experiment and go through different ways of working and decide which one is best. Sometimes a method of work will no longer be helpful, and decisions can be made to change it.
Work in progress is considered not only the tasks currently being worked on. It also includes the tasks that are to be tested and those that are pending approval.
In Scrum, Agile, and all other possible working conditions and methodologies, this idea must be borne in mind.
When a card is completely finished, it must be removed from the dashboard and a new one added in its place.
When working with Scrum, the board usually has no limit on the exact 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.
The main differences between Scrum and Kanban
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 cleaned and restarted. New cards (items) are not added there until the end of the sprint. Cards are also often found in columns and have the corresponding status.
Kanban or Scrum
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 staffing 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 may be 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.
Kanban the right way
There is always the possibility that an organization will use Kanban for the intended purpose and explicit desire of the teams, 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 of the teams and organization.
Kanban is a flow of work that is ongoing
Kanban is a workflow in which there are no "sprints". Kanban is a flow of work that is ongoing.
Kanban may exhaust teams
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 carry the feeling of a beginning and an end.
The periodicity and end of a sprint can bring a sense of accomplishment and completion. Such recurrence helps for moderate mental dynamics and satisfaction with the goal achieved.
BVOP suggests choosing Scrum when possible as a method of work that may provide teams a little more comfort.
BVOP recommends that teams choose whether to use Kanban or Scrum as the recommended method of choice would be a preliminary test of both approaches. A periodic review of the opinions of all team members can help decide to migrate to another style of work.