Today, many companies are reviewing their approach to the development process and work planning. Market grows and you have to speed up. But this in-a-hurry-development shouldn’t affect the software development quality. Here you meet the point when you have to apply the Kanban method for your development process.
Most of you probably heard about Kanban before. This is the method for Just-in-time (JIT) manufacturing invented by Taiichi Ohno, an industrial engineer at Toyota, in the late 1940s. Literally, Kanban name can be translated from Japanese as “signboard” or “billboard”. Btw, you could have already seen it in work in many task managers you use (remember Trello?).
Kanban aligns inventory levels with actual consumption. A signal tells a supplier to produce and deliver a new shipment when the material is consumed. These signals are tracked through the replenishment cycle, bringing visibility to the supplier, consumer, and buyer. Kanban uses the rate of demand to control the rate of production, passing demand from the end customer up through the chain of customer-store processes. In 1953, Toyota applied this logic in their main plant machine shop.
To apply Kanban method, Toyota invented 6 rules:
- Later process picks up the number of items indicated by the Kanban at the earlier process
- The earlier process produces items in the quantity and sequence indicated by the Kanban
- No items are made or transported without a Kanban
- Always attach the Kanban to the goods
- Defective products are not sent on to the subsequent process. The result is 100% defect-free goods
- Reducing the number of Kanban increases the sensitivity.
The primary goal of a Kanban system is to maximize the delivery of value to the customer by steadily increasing the speed and quality of output, simultaneously, until the system reaches an optimal level. Only when you have stable, smooth flow of work is predictability of delivery times even possible. And this is what you need in your web development process. So let’s try to interpret the rules suggested by Toyota to the software development process as the necessary steps.
Main steps to implement the Kanban system:
- Visualize your current workflow
Firstly, map the process you currently use to deliver work product to the customer on a visual control board (physical or digital). DIvide the process into columns where each column represents a step for adding value to a unit work. Make sure you map every step from conception to delivery to the end consumer. You may optionally have columns in between steps representing necessary “wait states” or buffers.
The Kanban board is not intended to be in a permanent configuration. The idea is to iterate the board configuration periodically, as a team, to find the optimal configuration.
- Apply Work-in-Process (WIP) limits
You can implement WIP constraints in Kanban by allowing a limited number of work units for any given column at a time. The exact limit on a column depends on your context, but we assume that the best number for WIP limits is the number of individuals (or pairs) who do work in that step. Work does not move to the next step until space opens up for it. The effect is a system where the end consumer gradually pulls work items through like a vacuum.
This is both the simplest and most powerful practice, but it faces the most resistance. Despite overwhelming scientific evidence to the contrary, people cling to the idea that if they work on more things at the same time they will get more done, more quickly. That is not true.
- Make policies explicit
Assign different classes of service to different work items. Common classes are “Standard”, “Expedite”, and “Fixed Date” classes. Some classes are allowed to skip to the front of the queue. The idea is that if everything is FIFO (“Standart”), a high cost-of-delay item can get stuck waiting behind a low one just because it arrived later in the line. Or an unanticipated item causes other planned work to stop, while you address it. But if you split demand into classes, while some items may end up with slightly longer lead time, overall the flow is more smooth and regular. High throughput is less valuable if it is bursty and unpredictable.
Reserve some capacity for unexpected work or work that had a fixed delivery date, perhaps using an 80/20 distribution. What this does is smooth the flow of work for standard items, and still allows for interrupt-driven, fixed date, and emergency work to use the “fast track lane”.
- Manage and measure flow
We are optimizing for speed and quality simultaneously. The metric we use is cycle time or its mathematical equivalent, throughput, which is calculated by the average time it takes a unit of work to move through the system. Throughput is the number of units that move during a given time period.
A Cumulative Flow Diagram (CFD) is the best visualization for this, but it takes some getting used to. Most people are used to a Control Chart. A real, robust tool would have both and calculate them for you, but they aren’t hard to build by hand.
- Optimize iteratively with data
Think carefully before you modify the board. Declare a hypothesis about how a change to the board will result in a specific, measurable outcome. Make the change, and allow the team to use the board in that configuration for a period of time. After this, measure whether it actually improves performance, and change it back if it doesn’t work.
The tip: if you’re having trouble tracking what everyone is doing, your stories are still too large. You should be aiming for continuous delivery, even if it’s just to staging, with a manual last step for deployment.
Kanban is an incredibly powerful method for managing your workflow process and gradually improving your performance. It encourages all of the core best practices of agile, like cross-functional teams, fast feedback, co-location and pairing, and continuous integration and deployment.
This material was created on the base of Kanban in 5 Easy Steps by Sam McAfee.
Stay tuned! In our next materials, we will tell you about alternative software development methodologies.