The Kanban system began its journey in the 1950s on the production lines of Toyota, after which it transitioned to offices and became an important tool for project managers.
The limitless flexibility of the practice and its ability to self-organize personnel allowed for efficiency where other approaches did not work. This is the case where the business card of the system became the card itself — it has established itself as an internal currency in organizations that have implemented Kanban.
Origin
Like the concept of Lean manufacturing, the Kanban system was developed by Toyota managers. The system’s author, Japanese engineer Taiichi Ohno, was inspired by the operating principles of American supermarkets, where customers selected the products they needed themselves. The “supermarket” role in Toyota was performed by the warehouse.There, signaling cards — which is what “kanban” literally translates to from Japanese — were exchanged among workers, who manually regulated the production process.Cards were attached to crates with parts. Such tags indicated information about the part number and quantity, which department was sending them, and where they were to arrive.
The worker directly involved in the assembly of machines (“downstream”) would take parts from the crate to which the “kanban” requesting replenishment was attached. The card was removed and passed along with the empty crate to the transporter to the warehouse. There, another worker prepared a new crate with spare parts, to which the production “kanban” — a tag with information about the produced spare parts — was attached.
The production “kanban” was replaced with a “kanban” requesting replenishment and sent to the spare parts production line — “upstream”. Thus, exactly the quantity of parts specified on the card was produced. The crate with new spare parts was placed by transporters on the assembly line.
Principles of Kanban
Toyota managers articulated 6 system-forming rules:
- Workers from the “downstream” remove exactly as many parts from inventory as specified on the kanban
- Workers from the “upstream” also supply parts strictly according to the cards
- Nothing is produced or moved without a kanban
- The kanban must always be attached to the parts
- Defective parts are not used in the system
- Reducing the number of kanban cards makes management more sensitive to changes. But without extreme necessity, it is not advisable to change the established number of cards.
Kanban is a “pull” system. It creates a balance between a constant flow, which eliminates waiting costs, and a minimal amount of work in progress (WIP), which reduces the risks of overproduction. WIP is regulated using cards: their number is fixed, and the instructions in them guide the “downstream” workers.
The WIP limit consists in proportion to the amount of kanban cards, which is calculated based on sales levels and statistical variability in current processes. The maximum number of tags — the “energy” in the system — secures the upper WIP level at any given time. WIP is also limited by the pull principle: the production speed of the upstream depends on the working speed of the downstream.
The graph shows that one of the basic elements of the system is the Kaizen culture. Autonomous processes and standard variability free management from constant oversight, thereby allowing it to focus on improving employee performance.
Application of Kanban in IT
The Kanban system, continuing to provide benefits on production lines, has penetrated the software domain.
Only cards, which contain information about deadlines, descriptions, or process numbers and the executor’s name, are now attached not to crates of spare parts but to boards with divided columns:
- Backlog — tasks to be completed
- Tasks currently being developed
- Tasks completed but not yet handed over to testers
- Tasks ready for handover to the testing department
- Tasks undergoing project manager (PM) review
- Completed tasks
Number is usually written above the columns — the limit, which indicates the maximum number of processes in it. The backlog limit is calculated depending on the lead time. If there are 5 work processes in the system and the average completion time for each is 1 day, the backlog can be limited to 5.
The structure above is not strict — depending on the specifics of the project, improvised columns may be added. A Kanban system may often have the need to define criteria for task readiness before execution. In this case, two columns appear, referred to in English as specify (clarifying parameters) and execute (taking on the work).
- Another column with a priority queue may be added. When an executor becomes free, they need to clear this column of tasks first before taking on others.
- Tasks that have not been completed are either returned to the backlog or crossed out of the scheme.
- Kanban does not encourage multitasking, thus limiting the number of processes for each executor.
- Completed work is better than several started tasks.
- A second job can be taken if the first is blocked.
- Time for task execution must be balanced. Too short a deadline can affect quality. An overly extended limit burns team resources and raises process costs.
Why is the Kanban board used everywhere instead of, for example, tablets or large monitors? Supporters of the system answer this question by stating that a regular board has two advantages: it is simple and provides visual control. It is easy to make changes on it, and it encourages tactile and social interaction among team members.
Advantages and Disadvantages of Kanban
Kanban has the following advantages:
- Flexibility in planning. The team focuses solely on current work, with task priority set by the manager.
- High team engagement in the development process. Due to regular meetings, process transparency, and opportunities for self-organization, employees come together and show genuine interest.
- Shorter cycle duration. If the necessary skills are possessed by several people, duration decreases; if only one person possesses them, a bottleneck arises. Hence employees should share knowledge thus optimizing cycle duration. This allows the entire team to work on stalled tasks and restore smooth flow.
- Fewer bottlenecks. WIP limits allow for quick identification of bottlenecks and problem areas arising from lack of focus, manpower, or skills.
- Visibility. When all executors have access to data, it becomes easier to spot bottlenecks. Kanban teams, aside from the cards themselves, usually utilize two common reports: control charts and cumulative flow.
In practice, the system shows great results in non-core production areas:
- software support groups or help desks.
- Kanban works well in managing startups without a clear plan but where active development is happening.
Kanban also has disadvantages:
- the system works poorly with teams of more than 5 people
- it is not intended for long-term planning.
Differences from Scrum
Scrum, like agile Kanban, is a flexible methodology that is also often applied in the IT sphere. The differences between them are not obvious at first glance. There are many similarities, for example, the presence of a backlog in both approaches.
Scrum | Kanban | |
Pace | Repeated sprints of fixed duration | Continuous process |
Release output | At the end of each sprint after approval by the project manager (product owner) | Flow continues uninterrupted or at the team’s discretion |
Roles | Product owner, Scrum master, development team | Team led by PM; in some cases agile Kanban coaches are involved |
Key metrics | Team velocity | Lead time |
Regarding change acceptability | During a sprint, changes are undesirable as they can lead to miscalculation of tasks | Changes can occur at any moment |
Examples of Application in IT
Right from Microsoft: The Debut of Kanban in Software Development
The use of Kanban principles in information technology began a little over 10 years ago. David Anderson, one of the main promoters of Kanban for software developers, consulted with Microsoft in 2005. They were dissatisfied with the performance of their department — XIT Sustained Engineering, which was fixing bugs in internal applications. By the beginning of the reporting year, this department was the worst in its division. The backlog exceeded the acceptable size by five times, and the lead time for processing one request was typically five months.
The new PM, with Anderson’s consultations, increased the productivity of the troubled department by 155% in nine months. The lead time was now five weeks, the backlog returned to a normal size, and timely task completion stabilized at 90%. All these results were achieved with minimal onboarding of new employees; staff continued to fix bugs the same way — only the approaches to organizing work changed.
An interesting fact: program manager Dragos Dumitriu, who set out to turn the situation around in XIT, was just captivated by Anderson’s book. To his surprise, he met the ideologist of program Kanban in the very Microsoft where he had started just the day before. Dumitriu asked Anderson for help with his task, and the latter agreed to apply the principles of his book in practice.Dumitriu encountered a department consisting of three developers and three testers, which had 80 requests piled up in the backlog. The PM himself was temporarily appointed since the job requirements included expertise in ASP technology, SQL Server administration, and knowledge of MS Project Server. Management envisioned a “techie” who could code, prepare reports, and forecast backlog load in this position. As it was believed back then, the problem of the department would be revealed if a large amount of data was gathered. Dumitriu was not such a “techie”.
However, starting to analyze the XIT operations alongside Anderson, he quickly identified key factors negatively affecting the department’s speed:
- Forecasting the implications (ROM) of fulfilling a request took a lot of time. Both the developer and tester had to spend a full workday performing necessary calculations, checking code, and completing documentation. On average, one request came in each day. According to PM’s calculations, 40% of the department’s productivity went to ROM;
- Priority was given to higher value requests. XIT was funded based on order value. Prioritization of requests was discussed monthly at department managers’ meetings with clients — managers from other departments. With an expanding backlog at the current speed, where only 6 – 7 requests were processed monthly, priorities of other requests constantly changed due to passing time. Many of them were postponed to a significant “later,” not even equal to the next month.
- At the ROM stage, half the requests were filtered out. Some were too large and were requalified as projects to be transferred to other departments, others were too expensive and simply canceled. Some requests were not taken into development because their implementation would take too long. Thus, 40% of the department’s productivity was spent on analyzing requests, 50% of which were rejected. About 15 – 20% of working resources were wasted.
- Preparatory work on requests could drag on for months before implementation began. Calculations at the ROM stage could be lost or forgotten during that time. Especially if the implementation was handled by a different developer than the one who started the analysis.
Kanban solutions for Microsoft’s troubled department
At the end of 2005, the productivity of the department increased by 155%. To further improve XIT’s work, two employees were brought in: one developer and one tester. The number of requests in the backlog decreased to 10, and one developer consistently processed 11 requests per quarter. On average, 56 requests were completed per quarter compared to 11 previously. The cost of requests fell from $7500 to $2900.
Application in Corbis
After achieving success at Microsoft, Anderson in 2006 began tackling a new complex task. Now he was working at Corbis — another company of Bill Gates, who had not yet left MS. One of Corbis’s activities was photo licensing. At that time, it was the second largest stock photo library in the world with a database of about 3.5 thousand images.
Anderson’s task was to accelerate the main releases from the company. The interval between their releases was three months and could grow even longer. Just discussing the release plan took management two weeks. It was necessary to establish the release of secondary releases or updates every two weeks. At the same time, key resources had to be directed toward the main project.
A Kanban board appeared in Corbis’s office, where Anderson spoke with the team daily. The goal of the PM was to improve visual control over processes, encourage self-organization, and greater personal accountability among executors. The Kanban system was also aimed at reducing manager oversight and increasing productivity.
In addition to colorful cards and graphs, a “garbage bin” appeared on the board — into which tasks that were too large were sent.
Photo from the official presentation
A Kanban System for Sustaining Engineering on Software Systems by David J Anderson
The Kanban system clarified when the flow ceases to be smooth and where delays occur, the so-called bottleneck. Quick discussions with the team helped identify current problems. For example, testing took 3 days, which negatively impacted the release timeline. Three employees came together and found a way to reduce the time to one day.
A bottleneck is a section of the scheme or algorithm of the company’s operations, where resource or human productivity limitations sharply reduce the throughput of the task flow. A shortage of manpower, poor internet, or a director on vacation blocks or slows task execution.
Limits for Kanban cards were set in an empirical way twice. In the “ready for development” column, the limits were increased. A new column — “ready for testing” — also appeared. Many requests for the downstream were incorrectly formulated, causing unnecessary time expenditure. Therefore, PM investigated the upper flow’s operations and found mistakes.
The request review procedure could take 100 days, but releases still began to emerge every two weeks as planned. Decisions on release content were made 5 days before publication. The counting practice, as in the case of the XIT department at Microsoft, was abandoned in favor of productivity. Task priorities were set according to “cost of delays” or readiness of resources.
The Kanban system not only helped Anderson achieve the set goal but also improved the morale within the team. Thanks to collective discussions and visibility of processes, employees established trust in each other. The staff also embraced Kaizen, that is, the practice of continuous improvement.
Programs and Apps for KANBAN
Trello
Popular Kanban system for task management. It is noted for its visual appeal and user-friendly interface. Users highlight its super flexibility.
Kanbantool
Free board for two users. API support and touch interfaces.
Lean Kit Kanban
Free board for five users with good collaboration features. API support and import/export capabilities, extensive statistics.
Kanbanize
Completely free service with decent functionality. Its owners guarantee a 300% increase in productivity when using their product.
Worksection
Ukrainian SaaS — application for quick tracking and managing projects. Currently, in addition to accounting for finances and deadlines, there is a Gantt chart. In the coming months, the developers will add a Kanban board with customization options, making the service even more suitable for Kanban.
Verdict
Kanban is a practice that helps achieve success, while the use of only agile methods is not compulsory. Significant changes are achieved by eliminating wasted time, managing bottlenecks, and reducing variability.
However, successful changes require time. They occur gradually, while the team’s resistance to innovations is minimal. The Kanban system motivates personnel to improve without changes in engineering methods.
Books for the article are provided by kniga.biz.ua