View

Daryl Powell

Supermarket-based Kanban pull systems are unable to manage custom-engineered parts and components. The success of these systems is highly dependent on the use of standard components and parts. Customized lean alternatives are Scrum & Kanban boards.

Scrum boards, Kanban boards (Workload Control)

Difficult to identify work flow in high variety / job shop environments.

High levels of WIP. Many jobs open simultaneously. Long throughput times.

Higher level of flow efficiency. Shorter throughput times.

Both Scrum and Kanban use visual boards to show available work, work-in-process, and completed work (often under the headings “To-do”, “Doing”, and “Done”). Scrum and Kanban encourage and promote team-based problem solving throughout the completion of prioritized tasks, and can be effectively adopted in both software- and hardware development, as well as in project-based production environments, such as in ETO manufacturing.

 In Scrum, tasks are selected from a prioritized backlog and posted under “To-do”. The tasks that are selected are expected to be completed by the Scrum team during the sprint that follows, which typically takes place over the next 7 days to 4 weeks (Sprint duration is normally constant from one sprint to the next). Each day during the sprint, all team members gather around the Scrum board in what’s known as a stand-up meeting (typically maximum 15 minutes long). During the stand-up, the participants discuss what was achieved on the previous day, the plan for today, and the problems that were addressed / remain to be addressed such that the Sprint can be completed on time. On the first stand-up meeting, individuals will select and move “To-do” items to “Doing”. Upon completion, these jobs will be moved to “Done”. On the last day of the Sprint, team members should reflect on the Sprint in order to improve during the subsequent Sprint. In essence, Scrum constitutes a pull-mechanism as the quantity of tasks that is released into each Sprint remains fixed for the duration of the Sprint. The quantity of tasks released is based on the amount of required capacity that is anticipated to complete each task during the Sprint. No further tasks shall be released into the current Sprint unless there is a plausible exception, and only then by approval of the product owner.

 Kanban is very similar to Scrum in that a visual board and daily stand-up team meetings are the mechanisms for success. However, the major difference is that a Kanban board explicitly limits the amount of tasks that can be assigned to each stage of the operation. In the case of Kanban, “Doing” is often segregated into separate operations, each with a visually-defined limit of tasks that can be processed simultaneously in that operation. Tasks are still selected from a prioritized release list, as in Scrum (and indeed POLCA and CONWIP). Yet the fundamental difference between Kanban and Scrum is that Kanban can be more reactive to changes in requirements. This is due to the fact that tasks are not locked in for the duration of the sprint (e.g. 7-28 days); the response time of a Kanban team is the time it takes for capacity to become available after having completed a current task in process. This follows the general principle of one-out-one-in, as in CONWIP.