Kanban
Audie Reints
In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying kanban method originated in lean manufacturing,[1] which was inspired by the Toyota Production System.[2] 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.[3]
For example, on the kanban board shown above, the "deployment" step has a WIP limit of five and there are currently five epics[clarification needed] 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.
A kanban board is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). It can help both agile and DevOps teams establish order in their daily work. Kanban boards use cards, columns, and continuous improvement to help technology and service teams commit to the right amount of work, and get it done!
"Kanban" is the Japanese word for "visual signal." If you work in services or technology, your work is often times invisible and intangible. A kanban board helps make your work visible so you can show it to others and keep everyone on the same page.
Kanban can be adapted to many environments, from manufacturing to human resources, to agile and DevOps software development. The type of environment adapting kanban often dictates if the board is physical or digital. In my research, I discovered a $58 million dollar construction job managed with a physical board in a trailer and I spoke to many, many software teams using digital kanban boards.
The simplest kanban boards are physical boards divided into vertical columns. Teams mark up a whiteboard or blackboard and place sticky notes onto the board. These sticky notes move through the workflow and demonstrate progress.
As the kanban system gained favor with software and engineering teams, kanban boards underwent a digital transformation. Digital boards allow teams that do not share a physical office space to use kanban boards remotely and asynchronously.
Trello is a fast and simple way to make a digital kanban board. The setup involves just a few clicks to create digital lists, which represent the stages of your kanban process, on a board view that your whole team can access and manage.
Some digital kanban boards are simple, and some are more robust and customizable. Teams that require additional functionality like WIP Limits and Control Charts should opt for a more powerful tool like Jira Software. Jira comes out of the box with a kanban project template that makes getting a kanban team up and running a breeze. The team can jump into the project and then customize their workflow and board, place WIP limits, create swimlanes, and even turn on a backlog if they need a better way to prioritize.
The difference between kanban and scrum is actually quite subtle. By most interpretations, scrum teams use a kanban board, just with scrum processes, artifacts, and roles along with it. There are, however, some key differences.
Kanban is a popular framework used to implement agile and DevOps software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Kanban is enormously prominent among today's agile and DevOps software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.
When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.
While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and cards, and even those can be virtual.
The work of all kanban teams revolves around a kanban board, a tool used to visualize work and optimize the flow of the work among the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.
Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.
The main purpose of representing work as a card on the kanban board is to allow team members to track the progress of work through its workflow in a highly visual manner. Kanban cards feature critical information about that particular work item, giving the entire team full visibility into who is responsible for that item of work, a brief description of the job being done, how long that piece of work is estimated to take, and so on. Cards on virtual kanban boards will often also feature screenshots and other technical details that is valuable to the assignee. Allowing team members to see the state of every work item at any given point in time, as well as all of the associated details, ensures increased focus, full traceability, and fast identification of blockers and dependencies.
A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.
Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenet of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets.
One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they're continuing to improve. When the team can see data, it's easier to spot bottlenecks in the process (and remove them). Two common reports kanban teams use are control charts and cumulative flow diagrams.
Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on precisely that: optimizing the flow of work out to customers
Some teams blend the ideals of kanban and scrum into "scrumban." They take fixed-length sprints and roles from scrum and focus on work in progress limits and cycle time from kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while. You can always get fancy later on.
In kanban, problem areas are highlighted by measuring lead time and cycle time of the full process and process steps.[4] One of the main benefits of kanban is to establish an upper limit to work in process (commonly referred as "WIP") inventory to avoid overcapacity. Other systems with similar effect exist, for example CONWIP.[5] A systematic study of various configurations of kanban systems, such as generalized kanban[6] or production authorization card (PAC)[7] and extended kanban,[8] of which CONWIP is an important special case, can be found in Tayur (1993), and more recently Liberopoulos and Dallery (2000), among other papers.[9][10][11][12][13]
31c5a71286