Kanban. The method to ensure steady workflow.
What is kanban in software development? How is a kanban board implemented? How does it measure production?
What is kanban in software development? How is a kanban board implemented? How does it measure production?
The Japanese word “kanban” is a composite of “kan” which means signal and “ban” which means card. As a technique, kanban was first described in 1978 by Toyota Production Manager Taiichi Ohno in a book about the Toyota Production System (TPS). Kanban is an element of just-in-time manufacturing, which means only what is needed to fulfill customer orders is produced. Information about what is to be produced in which quantities is passed from downstream to upstream by means of a kanban card. This creates a consistent and sequential production flow to reduce inventories. The goal is continuous improvement of process (kaizen) and the avoidance of waste (muza). A study carried out between 1985 and 1991 by the International Motor Vehicle Program led to this way of organizing production becoming known as Lean Production.
David J. Anderson:
David J. Anderson is credited with founding kanban within IT. In 2007 he published the book Kanban: Successful Evolutionary Change for Your Technology Business. In 2011 he started the Lean Kanban University (LKU), which established quality standards for the way Kanban is taught and practiced. According to Anderson, Kanban is not a software development process, but a method for managing, designing and improving flow systems for knowledge work. These are systems in which indeterminable work units move through different phases and finally create value for customers. A kanban system should limit the amount of work in progress (WIP) by using visual signals. Work is pulled into the system as soon as other work is completed instead of new work being pushed into the system as it is created.
These values are an expression of willingness to improve services using the method. Kanban cannot be applied faithfully without adopting these values.
There are three calls for action corresponding to organizational needs:
Together these aim for evolutionary improvement at all levels of the organization.
These focus on the user of a service and the value created for the user.
These should be undertaken by anyone managing a kanban system:
These practices involve clarifying rules and workflows and improving processes evolutionarily.
Arne Roock (Lean Kanban University):
A kanban board serves to visualize a workflow system. Units of work move from left to right through various phases of a process. Visual signals limit the amount of work in progress (WIP). Kanban systems also indicate criteria for commiting to and delivering work. Commitment takes place when customers and service agree on requirements or ideas for the system. Delivery takes place when work units are considered completed. The time it takes for a work unit to move from commitment to delivery is called the (system) lead time. When other aspects of the system besides this window of time are being examined, it’s called time in progress or TIP. The rate of delivery is determined according to delivered elements per time unit. If the end of a time period doesn’t result in delivery, the rate is called throughput.
John D.C. Little’s law applied to the workflow in a kanban system:
How do you measure whether the average work in progress (WIP) is ideally related to the lead time? There’s a visualization for this called a Cumulative Flow Diagram.
While in the Kanban method described above the total approximate average work in progress (WIP) is put into relation with the approximate average lead time, the Cumulative Flow Diagram on the right shows in addition the requirements before commitment (in yellow) and what is still being tested during development (in blue). In the best case, the lines do not overlap but flow uphill in parallel.
Learn more about what you can find out by examining the shape of the lines at our page Cumulative Flow Diagram.
Kanban itself originally didn’t call for any new positions, responsibilities or job descriptions. In practice, however, two positions developed that are now defined in the method. These roles are not job titles, but rather descriptions of the purpose of the position:
The Service Request Manager is responsible for understanding and analyzing stakeholder goals and needs. She selects the work units in the Replenishment Meeting. This meeting decides which input will fill the queue for a service.
The Service Delivery Manager is responsible for providing selected elements for the customer. She is also responsible for the daily kanban meetings and the delivery planning meetings and is sometimes called Flow Manager or Flow Master.
STATIK (Systems Thinking Approach to Introducing Kanban) was created for this purpose. Instead of looking at system components in isolation, you need to learn to understand how a system works holistically. The goals is to improve value creation for the customer. There are eight steps which aren’t necessarily to be followed in order. Rather, an iterative approach is to be taken where each step informs and influences the others.If organizations want to assess their progress with kanban, they can do a litmus test.
Step 0 | Identify Services |
Step 1 | Understand what makes the service fit for purpose for the customer |
Step 2 | Understand sources of dissatisfaction with the current system |
Step 3 | Analyze demand |
Step 4 | Analyze capability |
Step 5 | Model workflow |
Step 6 | Discover classes of service |
Step 7 | Design the kanban system |
Step 8 | Socialize the design and negotiate implementation |
If organizations want to assess their progress with kanban, they can do a litmus test. It consists of four central questions:
1.
Has management behavior changed to enable Kanban?
2.
Has the customer interface changed, in line with Kanban?
3.
Has the customer contract changed, informed by Kanban?
4.
Has your service delivery business model changed to exploit Kanban?