One of the ongoing debates in the Agile blogosphere boils up to, “Scrum vs. Kanban.” I have seen endless discourses, based mostly on the proponents’ personal experiences, as to which is the better way to run a project. As an evidence-based manager, I wanted to know if there were any objective data one way or the other, and went looking. The answer is, “Not really.”
But I found enough information to warrant a two-part series on what we do know. In this post, I will explain what kanbans—yes, plural—originally were and still are in their original setting. I think that is highly relevant to the debate. In the next post, I will review the evidence regarding Kanban’s use in projects, especially software.
Kanban was invented by Toyota as a way to control parts production, prevent delays, and limit the costs of creating and storing excess inventory. Like many management techniques thought to be exclusively Japanese, it had roots in U.S. manufacturing. One study says: “Early on, Toyota leaders did not have the economies of scale enjoyed by Ford or General Motors and believed they could not attain these, so they tried to develop a system that they imagined Henry Ford might have used in their situation.”[i]
People involved in Kanban’s evolution explained in 1977, “In order to avoid such problems as inventory unbalance and surplus equipment and workers, we recognized (the) necessity of schemes adjustable to conform with changes due to troubles and demand fluctuations.”[ii] One adjustment was to have the final assembly line withdraw parts on demand (“pull”) rather than trying to predict how many parts of each type are needed (“push”). “Toyota sees the stock on hand as being only a collection of troubles and bad causes,” these originators wrote. The system extended outward to the production of parts as well.
There are many variations of the (pre-robot) process, but here’s a basic description summarized from the sources I found. A kanban is just a plastic card naming a part and a set number of pieces. When the last of one part in a bin is used at Station 2, its operator moves the empty bin to the output side of Station 1. The Station 2 operator places the kanban for those parts in Station 1’s kanban holder, typically a standalone post with card slots. There can be multiple bins for a part, each calling for the same number of parts.
Meanwhile, when a bin gets filled at Station 1, the Station 1 operator moves the bin to Station 2’s input side, and places the card saying those parts are ready in the holder for Station 2. If the distance is short enough, there might only be one bin rack between the stations, so only the kanban would be moved between holders.[iii] Operator 1 then draws the top card in Station 1’s holder to know what to work on next.
Clearly this means each workstation can produce and use a variety of parts. It is critical to note that those parts are standardized, and each operator can do everything needed to create that part at one station. In other words, no direct interaction between operators is needed to create a part.
Nor are there frequent design or process changes. There will be occasional changes to a part, or entire assembly line, when new models come out. But those are relatively rare, due to the substantial costs of making changes in manfacturing. Most days the work is routine. One reason people are trained on different machines is so they can switch tasks regularly to prevent boredom.
Kanban evolved in manufacturing to emphasize five principles, a journal article explains:
- “visualize workflow”
- “limit work in progress (WIP)”
- “measure and manage flow”
- “make process policies explicit”
- “use models to recognize improvement and opportunities”[iv]
Notice that the WIP limit is a key feature. “If there is no explicit WIP limit and no signaling to pull new work through the system then it is not a Kanban system,” one research team stated flatly.[v]
A presentation at a systems engineering conference explained why. “WIP limits accomplish several goals: they can lower the context-switching overhead that impacts individuals or teams attempting to handle several simultaneous tasks; they can accelerate value by completing higher value work before starting lower value work; and, they can provide for reasonable resource work loads over time.”[vi]
Kanban has spread far beyond those origins in manufacturing, for example to HR departments,[vii] restaurants,[viii] and of course, software.[ix] For project work, the most minimal form of Kanban re-creates the kanbans as sticky notes, and the holders as a chart on a wall. The chart has columns showing a backlog and the state of a card when in progress, like this:
And, of course, there’s (many) an app for that! There are only three other absolute rules in this version, per every book or journal article I’ve read:
- Rank-ordering of the cards in the backlog.
- Clear definitions of the criteria that must be met for a card to move out of a column.
- A WIP limit, either by column or for the whole board, which is the maximum number of cards that can be in play at any time.
By the way, the point to kanbans was not to make tasks more visible to managers. Quite the contrary: “The cards are used to visually represent work items… for the teams to self-organize by assigning their own tasks and to complete work without direction from a manager,” a review of software-related studies said.[x] A team leader who uses a Kanban board to assign work has quite entirely missed the point.
In fact, I was stunned when I saw the title of that 1977 article, “Toyota Production System and Kanban System Materialization of Just-in-Time and Respect-for-Human System.” I add the italics, because in a decade of reading and hearing about Kanban from Americans, I had never seen that phrase used. “It is not a conveyer that operates men…” the article says, “it is men that operate a conveyer, which is the first step to respect for human independence” in the workplace.
Empowerment was a recurring theme in the article:
- “Any employee at Toyota has a right to make an improvement on the waste he has found.”
- Toyota instituted “visible control” in the form of kanbans so managers and foremen were not the only people who could identify problems. So “the authority and responsibility for running and improving the workshop have been delegated to the workers themselves…”
- “‘Jidoka’ as used at Toyota means ‘to make the equipment or operation stop whenever an abnormal or defective condition arises,'” and employees were praised when they did so.
Having certification in organizational change, I was not surprised to see that from 1965 to 1973 as Kanban was instituted, acceptance by Toyota workers of proposals for improvement rose from 39% to 76% due to the workers’ involvement in decision-making.[xi]
When properly instituted, Kanban matches perfectly the principles in the Manifesto for Agile Software Development around “self-organizing teams” and trusting your workers. But does it match software development, or other project work? I’ll cover the evidence in the next post.
Please share this post at the bottom of the page.
[i] Bradley R. Staats, David James Brunner, and David M. Upton, “Lean Principles, Learning, and Knowledge Work: Evidence from a Software Services Provider,” Journal of Operations Management 29, no. 5 (July 2011): 376–90, https://doi.org/10.1016/j.jom.2010.11.005.
[ii] Y. Sugimori et al., “Toyota Production System and Kanban System Materialization of Just-in-Time and Respect-for-Human System,” International Journal of Production Research 15, no. 6 (January 1977): 553–64, https://doi.org/10.1080/00207547708943149.
[iii] C. Sendil Kumar and R. Panneerselvam, “Literature Review of JIT-KANBAN System,” The International Journal of Advanced Manufacturing Technology 32, no. 3–4 (February 21, 2007): 393–408, https://doi.org/10.1007/s00170-005-0340-2.
[iv] Muhammad Ovais Ahmad et al., “An Empirical Study of Portfolio Management and Kanban in Agile and Lean Software Companies: An Empirical Study of Portfolio Management and Kanban in Agile and Lean Software Companies,” Journal of Software: Evolution and Process 29, no. 6 (June 2017): e1834, https://doi.org/10.1002/smr.1834.
[v] Muhammad Ovais Ahmad et al., “Kanban in Software Engineering: A Systematic Mapping Study,” Journal of Systems and Software 137 (March 1, 2018): 96–113, https://doi.org/10.1016/j.jss.2017.11.045.
[vi] Richard Turner et al., “Effectiveness of Kanban Approaches in Systems Engineering within Rapid Response Environments,” Procedia Computer Science, Conference on Systems Engineering Research, 8 (January 1, 2012): 309–14, https://doi.org/10.1016/j.procs.2012.01.065.
[vii] Ahmad, Muhammad Ovais, Denis Dennehy, Kieran Conboy, and Markku Oivo. “Kanban in Software Engineering: A Systematic Mapping Study.” Journal of Systems and Software 137 (March 1, 2018): 96–113. https://doi.org/10.1016/j.jss.2017.11.045.
[viii] Resalin Rago, “Agile and Lean Lessons from the Restaurant Industry,” Agile Velocity (blog), March 15, 2017, https://agilevelocity.com/agile/order-agile-lean-lessons-restaurant-industry/.
[ix] Ahmad et al., “Kanban in Software Engineering”; Staats, Brunner, and Upton, “Lean Principles, Learning, and Knowledge Work”; Ahmad et al., “An Empirical Study of Portfolio Management and Kanban in Agile and Lean Software Companies”; Denis Dennehy and Kieran Conboy, “Identifying Challenges and a Research Agenda for Flow in Software Project Management,” Project Management Journal 49, no. 6 (December 2018): 103–18, https://doi.org/10.1177/8756972818800559; Paulo Sérgio Medeiros dos Santos et al., “On the Benefits and Challenges of Using Kanban in Software Engineering: A Structured Synthesis Study,” Journal of Software Engineering Research and Development 6, no. 1 (October 19, 2018): 13, https://doi.org/10.1186/s40411-018-0057-1.
[x] Ahmad et al., “Kanban in Software Engineering.”
[xi] Sugimori et al., “Toyota Production System and Kanban System Materialization of Just-in-Time and Respect-for-Human System.”