Kanban - MihkelPLoompuu/AgiilsedTarkvaraarenduseMetoodikad GitHub Wiki
What is Kanban
is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level 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 pulled as capacity permits, rather than work being pushed into the process when requested.
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, which was inspired by the Toyota Production System. 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.
Kanban boards
The diagram here shows a software development workflow on a kanban board.
Kanban boards, designed for the context in which they are used, vary considerably and may show work item types ("features" and "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 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.
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 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.