Kanban (development)
{{COI|date=August 2022}} {{Short description|Workflow management method}} {{About|the process-management and improvement method|the lean-manufacturing process|Kanban}} [[File:Abstract Kanban Board.svg|right|thumb|A [[Kanban board]]]] {{Software development process}} {{Use dmy dates|date=January 2021}} '''Kanban''' ([[Japanese language|Japanese]]: {{Nihongo2|看板}}, meaning ''[[signboard]]'' or ''[[Billboard (advertising)|billboard]]'') is a [[Lean_manufacturing | lean method]] to manage and improve work across human [[system]]s. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level [[Bottleneck (production)|bottlenecks]].
Work items are visualized to give participants a view of progress and process, from start to finish—usually via a [[kanban board]]. Work is [[Push–pull_strategy#Complete_definition|pulled]] as capacity permits, rather than work being pushed into the process when requested.
In [[knowledge worker| knowledge work]] and in [[software development]], the aim is to provide a visual [[Business process management|process management]] system which aids decision-making about what, when, and how much to produce. The underlying [[kanban]] method originated in [[lean manufacturing]],{{Cite book |last=Womack |first=James P. |title=The Machine That Changed the World |year=2007 |publisher=Simon & Schuster |isbn=978-1847370556}} which was inspired by the [[Toyota Production System]].{{Cite book |last=Ohno |first=Taiichi |title=Toyota Production System: Beyond Large-Scale Production |year=1988 |isbn=978-0915299140}} It has its origin in the late 1940s when the Toyota automotive company implemented a production system called just-in-time, which had the objective of producing according to customer demand and identifying possible material shortages within the production line. But it was a team at Corbis that realized how this method devised by Toyota could become a process applicable to any type of organizational process. Kanban is commonly used in software development in combination with methods and frameworks such as [[Scrum (software development) |Scrum]].{{Cite book |last=Corey |first=Ladas |title=Scrumban and other essays on Kanban System for Lean Software development |date=2008 |publisher=Modus Cooperandi Press |isbn=9780578002149 |location=Seattle, Washington |oclc=654393465}}
== {{anchor|Kanban Boards}}Kanban boards == {{Main|Kanban board}} The diagram here shows a software development workflow on a kanban board.{{Cite web |last=Boeg |first=Jasper |date=February 2012 |title=Priming Kanban |url=http://www.infoq.com/minibooks/priming-kanban-jesper-boeg |access-date=17 February 2014 |publisher=InfoQ}} [[File:Sample Kanban Board.png|thumb|upright=2.2]] Kanban boards, designed for the context in which they are used, vary considerably and may show work item types ("features" and "[[User story|user stories]]" here), columns delineating workflow activities, explicit policies, and swimlanes (rows crossing several columns, used for grouping user stories by feature here). The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders.
A Kanban Board represents the system's Definition of Workflow{{Cite web |last1=Coleman |first1=John |last2=Vacanti |first2=Daniel |title=Kanban Guide - Definition of Workflow |url=https://kanbanguides.org/english/ |access-date=2023-08-17 |website=Kanban Guides |language=en-US}} and requires the following minimum elements:
- A definition of the individual units of value that are moving through the workflow. These units of value are referred to as ''work items'' ''(or items'').
- A definition for when work items are ''started'' and ''finished'' within the workflow. Your workflow may have more than one started or finished points depending on the work item.
- One or more defined states that the work items flow through from started to finished. Any work items between a started point and a finished point are considered ''work in progress'' (WIP).
- A definition of how WIP will be controlled from started to finished.
- Explicit policies about how work items can flow through each state from started to finished.
- A ''service level expectation'' (SLE), which is a forecast of how long it should take a work item to flow from started to finished.
== Kanban practices == The Practices of Kanban as described in the Kanban Guide{{Cite web |last1=Coleman |first1=John |last2=Vacanti |first2=Daniel |title=Kanban Guide |url=https://kanbanguides.org/english/ |access-date=2023-08-17 |website=Kanban Guides |language=en-US}} are
- Defining and visualizing a workflow
- Actively managing items in a workflow
- Improving a workflow
Kanban is a strategy that aims to follow these in order to create systems that are efficient, effective, and predictable.
The Kanban Method is a specialized and detailed extrapolation of Kanban. As described in books on The Kanban Method for software development, the two primary practices of The Kanban Method are to visualize work and to limit work in progress (WIP). Four additional general practices of The Kanban Method listed in ''Essential Kanban Condensed'' are to make policies explicit, manage flow, implement feedback loops, and improve collaboratively.
The kanban board in the diagram above highlights the first three general practices of The Kanban Method.
- It visualizes the work of the development team (the features and user stories).
- It captures WIP limits for development steps: the circled values below the column headings that limit the number of work items under that step.
- It documents policies, also known as done rules, inside blue rectangles under some of the development steps.
- It also shows some kanban flow management for the "user story preparation", "user story development", and "feature acceptance" steps, which have "in progress" and "ready" sub-columns. Each step's WIP limit applies to both sub-columns, preventing work items from overwhelming the flow into or out of those steps.
== Managing workflow == Kanban manages workflow directly on the kanban board. The WIP limits for development steps provide development teams immediate feedback on common workflow issues.
For example, on the kanban board shown above, the "deployment" step has a WIP limit of five and there are currently five epics {{cite web |url=https://web-mist.com/index.php/2025/03/22/work-using-kanban-wip/ |website=Mist | title="Mist" | publisher=Mist Technologies |ref=17}} shown in that step. No more work items can move into deployment until one or more epics complete that step (moving to "delivered"). This prevents the "deployment" step from being overwhelmed. Team members working on "feature acceptance" (the previous step) might get stuck because they can't deploy new epics. They can see why immediately on the board and help with the current epic deployments.
Once the five epics in the "deployment" step are delivered, the two epics from the "ready" sub-column of "feature acceptance" (the previous step) can be moved to the "deployment" column. When those two epics are delivered, no other epics can be deployed (assuming no new epics are ready). Now, team members working on deployment are stuck. They can see why immediately and help with feature acceptance.
In a Kanban board setup, swimlanes are used to visually organize work into different stages of a process, ensuring clarity and focus. For efficient workflow management, it is crucial to maintain distinct swimlanes for key phases such as requirements, development, testing, and closed/completed tasks. Specifically, testing stories should always be placed within the designated "Testing" swimlane. This separation ensures that testing activities are easily trackable and not intermingled with other stories in development or other stages. By keeping testing tasks within their own swimlane, teams can quickly identify bottlenecks, prioritize issues, and maintain the integrity of the testing process without cross-contamination from development or requirement phases. This structure leads to clearer workflows and enhances team collaboration.
This workflow control works similarly for every step. Problems are visual and evident immediately, and re-planning can be done continuously. The work management is made possible by limiting work in progress in a way team members can see and track at all times.
== Evolution and documentation of method == David Anderson's 2010 book, ''Kanban'',{{Cite book |last=Anderson |first=David J. |title=Kanban: Successful Evolutionary Change for Your Technology Business |date=April 2010 |publisher=Blue Hole Press |isbn=978-0-9845214-0-1}} describes an evolution of the approach from a 2004 project at Microsoft{{Cite conference |last1=Anderson |first1=David J. |last2=Dumitriu |first2=Dragos |date=November 2005 |title=From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution at Microsoft's IT Department |url=http://images.itrevolution.com/images/kanbans/From_Worst_to_Best_in_9_Months_Final_1_3-aw.pdf |access-date=24 September 2020 |conference=[[Theory of constraints#Certification_and_education|TOC ICO]] World Conference November 2005 |publisher=Microsoft Corporation |location=USA}} using a [[Theory of constraints|theory-of-constraints]] approach and incorporating a [[Theory_of_constraints#Operations |drum-buffer-rope]] (comparable to the [[Kanban#Operation|kanban pull system]]), to a 2006–2007 project at [[Branded Entertainment Network |Corbis]] (a separate company, also founded by Bill Gates) in which the kanban method was{{by whom?|date=June 2020}} identified. In 2009, Don Reinertsen published a book on second-generation lean product-development{{Cite book |last=Reinertsen |first=Donald |title=The Principles of Product Development Flow: Second Generation Lean Product Development |date=May 2009 |publisher=Celeritas Publishing |isbn=978-1935401001}} which describes the adoption of the kanban system and the use of data collection and an economic model for management decision-making. Another early contribution came from Corey Ladas, whose 2008 book ''Scrumban'' suggested that kanban could improve [[Scrum (software development) |scrum]] for software development. Ladas saw [[scrumban]] as the transition from [[Scrum (software development)|scrum]] to kanban. Jim Benson and Tonianne DeMaria Barry published ''Personal Kanban'',{{Cite book |last1=Benson |first1=Jim |last2=DeMaria Barry |first2=Tonianne |title=Personal Kanban: Mapping Work, Navigating Life |date=January 2011 |publisher=Modus Cooperandi Press |isbn=978-1453802267}} applying kanban to individuals and small teams, in 2011. In ''Kanban from the Inside'' (2014),{{Cite book |last=Burrows |first=Mike |title=Kanban From The Inside |publisher=Blue Hole Press |year=2014 |isbn=978-0-9853051-9-2 |location=Seattle, WA}} Mike Burrows explained kanban's principles, practices and underlying values and related them to earlier theories and models. In ''Agile Project Management with Kanban'' (2015),{{Cite book |last=Brechner |first=Eric |title=Agile Project Management with Kanban |publisher=Microsoft Press |year=2015 |isbn=978-0735698956 |pages=160}} Eric Brechner provides an overview of kanban in practice at Microsoft and [[Xbox Game Studios|Xbox]]. ''Kanban Change Leadership'' (2015), by Klaus Leopold and Siegfried Kaltenecker,{{Cite book |last1=Leopold |first1=Klaus |last2=Siegfried |first2=Kaltenecker |title=Kanban Change Leadership |publisher=John Wiley & Sons |year=2015 |isbn=978-1-119-01970-1 |location=Hoboken, NJ}} explained the method from the perspective of change management and provided guidance to change-initiatives. In 2016 Lean Kanban University Press published a condensed guide to the method, incorporating improvements and extensions from the early kanban projects.{{Cite book |last1=Anderson |first1=David J. |last2=Carmichael |first2=Andy |title=Essential Kanban Condensed |publisher=Lean Kanban University Press |year=2016 |isbn=978-0-9845214-2-5 |location=Seattle, WA}}
In 2020 John Coleman and Daniel Vacanti published ''The Kanban Guide'' to describe the minimal conditions needed to operate a Kanban system. Colleen Johnson, Daniel Vacanti, and Prateek Singh published The Kanban Pocket Guide{{Cite web |last1=Johnson |first1=Colleen |last2=Vacanti |first2=Daniel |last3=Singh |first3=Prateek |title=The Kanban Pocket Guide |url=https://prokanban.org/kpg/ |access-date=2023-08-17 |website=ProKanban.org |language=en-US}} in 2022, which helps practitioners navigate the Kanban practices. Will Seele and Daniel Vacanti also published the Flow Metrics for Scrum Teams{{Cite web |last1=Seele |first1=Wilbert |last2=Vacanti |first2=Daniel |title=Flow Metrics for Scrum Teams |url=https://prokanban.org/scrum-flow-metrics/ |access-date=2023-08-17 |website=ProKanban.org |language=en-US}} book in 2022 to bring the benefits of metrics commonly used in Kanban to Scrum teams.
== See also == {{subject bar|auto=y|d=y}} *[[Agile management]] *[[List of software development philosophies]]
==References== {{reflist}}
== Further reading == {{refbegin |30em}}
- {{cite book |last=Anderson |first=David J. |author-link=David J. Anderson |title=Kanban: Successful Evolutionary Change for Your Technology Business |year=2010 |publisher=Blue Hole Press |location=United States |isbn=978-0984521401}}
- {{cite book |last=Ladas |first=Corey |author-link=Corey Ladas |title=Scrumban: Essays on Kanban Systems for Lean Software Development |year=2009 |publisher=Modus Cooperandi Press |location=United States |isbn=9780578002149}}
- {{cite book |last=Brechner |first=Eric |author-link=Eric Brechner |title=Agile Project Management with Kanban |series=Developer Best Practices |year=2015 |publisher=Microsoft Press |location=United States |isbn=978-0735698956}}
- {{cite book |last1=Hammarberg |first1=Marcus |author-link1=Marcus Hammarberg |last2=Sunden |first2=Joakim |author-link2=Joakim Sunden |title=Kanban in Action |year=2014 |publisher=Manning Publications |location=Shelter Island, NY |isbn=978-1-617291-05-0}}
- {{cite book |last=Kniberg |first=Henrik |author-link=Henrik Kniberg |title=Lean from the Trenches: Managing Large-Scale Projects with Kanban |year=2012 |publisher=The Pragmatic Programmers |location=Dallas, TX |isbn=978-1-93435-685-2}}
- {{cite book |last1=Roock |first1=Arne |author-link1=Arne Roock |last2=Leschik |first2=Claudia |author-link2=Claudia Leschik |title=Stop Starting, Start Finishing! |year=2012 |publisher=Lean-Kanban University |location=USA |isbn=978-0985305161}}
- {{cite book |last=Skarin |first=Mattias |author-link=Mattias Skarin |title=Real-World Kanban: Do Less, Accomplish More with Lean Thinking |year=2015 |publisher=Pragmatic Bookshelf |location=United States |isbn=978-1680500776}} {{refend}} {{Authority control}}
[[Category:Agile software development]] [[Category:Japanese business terms]] [[Category:Software development philosophies]] [[Category:Toyota Production System]]
From MOAI Insights

디지털 트윈, 당신 공장엔 이미 있다 — 엑셀과 MES 사이 어딘가에
디지털 트윈은 10억짜리 3D 시뮬레이션이 아니다. 지금 쓰고 있는 엑셀에 좋은 질문 하나를 더하는 것 — 두 전문가가 중소 제조기업이 이미 가진 데이터로 예측하는 공장을 만드는 현실적 로드맵을 제시한다.

공장의 뇌는 어떻게 생겼는가 — 제조운영 AI 아키텍처 해부
지식관리, 업무자동화, 의사결정지원 — 따로 보면 다 있던 것들입니다. 제조 AI의 진짜 차이는 이 셋이 순환하면서 '우리 공장만의 지능'을 만든다는 데 있습니다.

그 30분을 18년 동안 매일 반복했습니다 — 품질팀장이 본 AI Agent
18년차 품질팀장이 매일 아침 30분씩 반복하던 데이터 분석을 AI Agent가 3분 만에 해냈습니다. 챗봇과는 완전히 다른 물건 — 직접 시스템에 접근해서 데이터를 꺼내고 분석하는 AI의 현장 도입기.
Want to apply this in your factory?
MOAI helps manufacturing companies adopt AI tailored to their operations.
Talk to us →