The Kanban system got started in 1950s on the manufacturing lines of the Toyota Corporation.
Afterwards it moved on to offices to become an essential tool of project managers.
The boundless flexibility of Kanban in practice and its capacities for self management of teams
have ensured efficiency where other approaches failed. In this very case, the system’s identity
card established itself as basically a card which further developed into the internal currency at
facilities with Kanban adopted.
Origins
Similarly to the Lean manufacturing concept, the Kanban system was elaborated by Toyota
managers. Taiichi Ohno, a Japanese industrial engineer and the author of the system, got inspired by the operating principle of American supermarkets where the buyer himself chose products he needed. The warehouse played the role of such «supermarket» in the Toyota Corporation.
Workers there exchanged signal cards (word-by-word translation of Kanban from Japanese) and thus controlled the manufacturing process on their own.
The cards were attached to containers with parts. Such tags indicated the following details: the
numbers and quantity of parts, the department sending them and their destination. The worker directly involved in vehicle fitting and assembly (downstream) took parts from the containers with an attached «Kanban» indicating a request for the warehouse. The card was taken off to be transferred, together with the empty box, by a transport worker to the warehouse where another worker had already prepared another container containing parts with a «production Kanban» tag attached to indicate data of parts produced.
Such production Kanban was replaced with a request Kanban addressed to the warehouse to be subsequently sent to the parts manufacturing line (upstream). Thus only the amount of parts
indicated in the card was manufactured. Containers with new parts were delivered to the fitting
line for transport workers.
Process
Kanban Fundamentals
Toyota managers have articulated 6 framework rules:
- Downstream workers withdraw from the warehouse precisely the number of parts which is indicated in the Kanban card
- Upstream specialists also deliver parts in strict compliance with the cards
- Nothing is manufactured or moved without Kanban
- Kanban should always be linked to parts
- Defected parts are not used in the system
- Any decrease in the number of Kanban cards makes management more sensitive tochanges. But no changes in the established number of cards should be done unless absolutely necessary.
Kanban is an «extending» system. It creates a balance between continuous flow to eliminate costs for expectation on the one hand and the minimum amount of work in progress (WIP) on the other, which finally reduces any risk of surplus production. WIP is regulated by means of cards: their number is fixed, and their instructions guide downstream workers.
The strict tag attachment rule works as the energy conservation law. The WIP limit is specified in
proportion to the number of Kanban cards calculated based on the level of sales and statistical
variance in current processes. The maximum amount of tags which represents that very «system
energy» fixes the top level of WIP within any given timeframe. WIP is also limited by the
extension principle: the upstream output rate depends on the downstream rate of production.
The chart apparently shows that Kaizen culture is one of the elements underlying the system.
Self-sustainment of processes and standard variance relieve the management of continuous
control, thus it becomes possible to focus on improving workers’ performance.
Using Kanban in IT
The Kanban system penetrated into the software field while continuing to generate value on
manufacturing conveyors.
However cards indicating such details as deadlines, process description or number and theтexecutive’s name are now attached not to containers with parts, but to the board featuring the following columns:
Backlog — tasks due to be implemented
- Tasks which are currently being developed;
- Tasks already implemented but not yet transferred to testers;
- Tasks ready to be transferred to the testing department;
- Tasks which are currently being checked by the project manager (PM);
- Tasks completed.
A limit number is usually indicated above a column to designate the maximum number of
processes in it. The backlog limit is calculated based on the lead time. If 5 works are in progress,
and each of them can be completed within 1 day on an average, then the backlog may also be
limited to 5.
The above structure is not strict — you may improvise and add columns depending on specific features of your project. Kanban systems requiring task readiness criteria to be determined before task execution are often the case. In such case, two columns named in English as specify (i.e. clarify parameters) and execute (i.e. start work) appear.
- A priority queuing column may also be added. When the executive gets free, he should empty this very task column, and only afterwards he may tackle the other ones.
- Unexecuted tasks either return to the backlog or are deleted from the chart.
- Kanban does not encourage multitasking, thus a limit of processes is set for one executive.
- One completed work is more preferable than several works just started.
- The second work may be tackled provided that the first one has been blocked.
- The timeframe for task execution should be balanced. Too short periods affect the quality. Too prolonged limits overspend the team’s resources and make the process more costly.
Kanban Advantages and Disadvantages
Kanban has the following advantages:
- Flexible planning. The team focuses only on the current work, and the manager prioritizes tasks.
- The team is strongly involved in the development process. Regular meetings, process transparency and possibilities for self-management make teams united and genuinely engaged.
- Reduced cycle duration. If several persons have similar skills, the duration decreases, but if only one person is relevantly skilled, a narrow space appears. Therefore, specialists should share their knowledge thus optimizing the cycle duration. It will enable the whole team to tackle the work which has been slowed down and to restore smooth workflow.
- Reduced number of narrow spaces. WIP limits make it possible to find narrow and problematic spaces resulting from lack of attention, human resources or skills.
- Visibility. When all executives have access to data, it is easier to notice narrow spaces. Apart from cards, Kanban teams usually use two general kinds of reports: management charts and cumulative workflow charts.
In practice, the system shows excellent performance in such non-core operations as:
- Software support groups or support services;
- Kanban operates well in startup management without clear schedules but with activ promotion of development.
Kanban also has its disadvantages:
- The system operates poorly with teams numbering more than 5 persons.
- It is not designed for long-term planning.
Difference from Scrum
Just as Agile Kanban, Scrum is a flexible methodology, and it is also often used in the IT field. At
first sight, the difference between them is not apparent. There are many similarities, e.g. both
approaches provide backlog.
Examples of Use in IT
With Microsoft straightway: Kanban debut in the field of software development
The Kanban fundamentals found use in the field of information technologies just over 10 years
ago. David Anderson, one of the major Kanban advocates for software developers, was consulting the Microsoft Company in 2005. One of the company’s subdivisions, XIT Sustained Engineering which was in charge of troubleshooting in internal applications, caused discontent. By the beginning of the reporting year, that subdivision appeared to be the worst one within its department. The backlog exceeded 5 times the admissible volume, and the duration of processing one request — lead time — usually took 5 months.
Anderson’s consulting enabled the new PM to increase the problematic department’s performance by 155% over 9 months. The lead time was reduced to 5 weeks, the backlog regained its normal volume, and timely execution of tasks was fixed at the level of 90%. All these results were achieved through minimum involvement of new specialists, and the personnel continued to correct program errors by using the same methods — only work arrangement approaches changed.
Interesting case: Dragos Dumitriou, a software manager who undertook to reverse the situation in XIT, was absorbed in Anderson’s book just at that time. To his surprise, he met the ideologist of software Kanban in the Microsoft Company where the latter had been employed shortly before. Dumitriou asked Anderson to assist him with his task, and Anderson agreed to apply the principles described in his book in practice.
Dumitriou found a department comprising three developers and three testers whose backlog had accumulated 80 requests. The PM’s appointment was temporary since the job requirements included the ability to handle the ASP technology, SQL Server administration and knowledge of MS Project Server. The top management envisioned «a tech worker» for this position, capable of programming and responsible for generating reports and predicting backlog loads. The department’s problem was believed to be discovered provided that a considerable data massive was compiled. Dumitriou was not such «tech worker» indeed.
However after starting to analyze the XIT operation with Anderson, he quickly discovered the key factors which negatively affected the department’s pace:
- Predicting consequences (ROM) resulting from request execution took too much time. Both developers and testers had to spend the entire working day to make necessary calculations, code verification and to complete documents. One request per day was received on an average. According to the PM’s calculations, ROM required 40% of the subdivision’s productive capacity;
- Priority was placed on requests having higher value. XIT obtained funding on account of order budgets.
- Priority ranking of orders was discussed on a monthly basis at the meetings of subdivision managers with customers — managers of other subdivisions. Given the swelling backlog at the current pace, when only 6-7 requests were processed over a month, priorities of other requests constantly shifted over the time passing by. Many of them were postponed to the distant «afterwards» which did not even mean the following month.
- Half of requests dropped out at the ROM stage. Part of them were too large, thus they were reclassified into projects and had to be transferred to other subdivisions, other ones were too costly and were simply canceled. Some requests were not taken for development since their introduction would turn out to be too time-consuming. Therefore, 40% of the subdivision’s productivity was spent on analyzing requests 50% of which were rejected. Approximately 15-20% of labor resources were wasted.
- Advance preparation for requests could last for months before introduction commenced. Calculations made at the ROM stage could be lost or forgotten over such time. It was particularly the case where the introduction procedure was handled by another developer — not by the one who had started the analysis.
Kanban solutions for Microsoft’s problematic subdivision
- In a dialogue with the top managers as well as with customer managers, Dumitriou and Anderson insisted on abandoning the ROM phase. Calculations immediately preceded the introduction phase being carried out by the same executive, i.e. they always remained «fresh».
- Requests were prioritized not at monthly meetings, but as situations demanded, through telephone calls or emails. 80 backlog tasks were sorted out depending on customers. The customers were asked to highlight the main requests which had to be implemented at first.
- XIT funding became fixed.
- The cost of requests was no longer taken into account.
- The PM introduced buffers on the Kanban board. Developers took work from two areas: approved tasks and executed tasks. The buffer contained 6 requests 5 of which were taken into the workflow. Testers selected items from the «testing due» buffer. Some tasks which did not require code alterations got there after bypassing the developers. With requests being broken down into one-task processes, the PM could better monitor the situation and ensure transparency for customers. The introduction of buffers reduced the lead time. Given such predictable system, customers could better determine whose request was the following one to get into the buffer.
- Decisions became immediate on too massive and costly requests. If a developer confirmed his readiness to execute a task within 15 days, or if modifications were worth making, such request was taken for operation regardless of its volume and cost.
- Having monitored the workflow in the subdivision, the PM came to a conclusion that the staff structure had to be transformed in favor of developers who would cope with mor workload. The transformation was carried out in the ratio of 2:1: XIT then comprised 4 developers and 2 testers.
According to the summary of 2005, the subdivision’s productive capacity grew by 155%. To further improve XIT’s performance, two more specialists were involved: one developer and one tester. The number of backlog requests decreased to 10, and one developer consistently processed 11 requests per quarter. 56 requests per quarter were completed versus previous 11. The request cost dropped from $7500 to $2900.
When Used by Corbis
Having succeeded in Microsoft, Anderson proceeded to solving a new complex problem in 2006.
At that time, he was working in Corbis — another company of Bill Gates who had not quitted
from MS yet. One of Corbis’ activities was photograph licensing. At that time, it was the second
largest photo stock in the world with the base numbering about 3.5 thousand pictures.
Anderson’s objective was to speed up the company’s main releases. The interval between the
releases was three months, and it could grow even more. The release plan discussion alone took two weeks of managerial work. It was necessary to align the output of secondary releases or updates every two weeks. At the same time, the key resources had to be targeted at implementing the main project.
The Corbis office got a Kanban board which became the venue for Anderson’s daily talks with the staff. The PM’s purpose was to improve visual monitoring of processes, to foster selfmanagement and to strengthen the executives’ personal accountability.
The Kanban system was also targeted at loosening managerial supervision and boosting the
productive capacity.
Apart from multicolored cards and graphs, a «waste bin» appeared on the board to collect
oversized tasks.
Photo from the official presentation
A Kanban System for Sustaining Engineering on Software Systems by David J Anderson
The Kanban system clarified the points where workflows were no longer smooth and where
delays occurred causing a so-called bottle neck. Prompt team discussions facilitated the discovery of current problems. For instance, the testing procedure lasted for 3 days, which negatively affected release timeframes. Three specialists united to find the way reducing that time to 24 hours.
Limits for Kanban cards were empirically established twice. In the «ready for development»
column, limits were not increased. A new column — «ready for testing» also appeared. Many
downstream requests were articulated incorrectly, which caused time overspending. Thus the PM investigated the upstream workflow and found errors there. Request processing could take 100 days, but anyway releases became regular — once per two weeks, as planned. Decisions on release content were made 5 days before publication. As in Microsoft’s XIT subdivision, the practice of calculations was shifted in favor of productivity.
Tasks were prioritized based on the «cost of delays» or readiness of resources. Not only did the Kanban system enable Anderson to achieve the purpose, it also ameliorated the climate in the personnel. Due to joint discussions and visibility of processes, team members became profoundly confident in each other. The personnel also adhered to Kaizen, which is the practice of continuous improvement.
Applications and Programs for Kanban
Trello
It is a popular Kanban system for task management. It differs by visual attractiveness and convenient interface. Users note its superflexibility.
Kanbantool
It represents a board free of charge for two users. It also offers support for API and touch interfaces.
Lean Kit Kanban
It is a board free of charge for five users, which provides good realization of joint work. It also
offers API support, enables import/export and provides good statistics.
Kanbanize
It is a completely free service with adequate functionality. Its owners warrant productivity
increment by 300% when their application is used.
Worksection
It is a Ukrainian saas application for swift project tracking and management. In addition to financial accounting, deadlines and Gantt chart, its functions currently include an adjustable Kanban board.
Verdict
Kanban is the practice which helps to succeed with no necessity to use only agile methods.
Significant changes are achieved through eliminating time losses, due management of narrow
spaces with reduction of variability.
However effective changes require time. They are gradual, and the team’s resistance against
novelties is minimal. The Kanban system motivates teams to get upgraded without altering their
engineering methods.