A supermarket is a large form of the traditional grocery store, a self-service shop offering a wide variety of food and household products, organized into aisles. The good thing about it is that I find a large variety of products. Supermarkets don’t look like an interesting organization; I was surprised to find out that they were the basis of one of the prevalent modern management methods, applied today in manufacturing and software development. I got a first glimpse of it when I wondered how supermarkets manage the expiring products. It turns out that they return them to the supplier, which is waste for the supplier. Controlling the rate of production using the rate of demand reduces waste. In the situation described, the supermarket is better organized than the suppliers.
Toyota studied the supermarkets in the last 1940s with the purpose of applying store and shelf-stocking techniques to the factory floor. In the supermarket, as customer, I get the required quantity at the required time, no more, no less. Furthermore, the supermarket stocks only what it expects to sell within a given time frame, and customers take only what they need, since future supply is assured.
There is such a system that uses the rate of demand to control the rate of production: Kanban. It was developed by Taiichi Ohno, at Toyota, as a solution to improve and maintain a high level of production. Kanban is part of an approach where the “pull” comes from the demand. The supply or production is determined according to the actual demand of the customers. To be effective, Kanban must follow strict rules. Toyota, for example, has six simple rules, and close monitoring of these rules is a never-ending task, thereby ensuring that the Kanban does what is required:
- Do not send defective products to the subsequent process
- The subsequent process withdraws only what is needed
- Produce only the exact quantity withdrawn by the subsequent process
- Level the production
- Kanban is a means of fine tuning
- Stabilize and rationalize the process
In development, a certain and tested method of “reduce waste”, Kanban, helps us managing a software development process in a highly efficient way. It only takes four steps:
- Visualize the development processes, from request to deployment
- Visualize the work through the use of a Kanban board
- Measure the cycle time and lead time and
- Continuously manage and improve the flow
Kanban can help you identify and reduce the seven wastes of software development (see Mary Poppendieck’s books on Lean Software Development)
- Partially Done Work: any work that’s not checked-in, integrated, tested, and deployed.
- Extra Features: features implemented, usually because a stakeholder or a developer thought they might be useful, and unused
- Relearning: if an activity that supposedly provides value is repeated, then probably it didn’t provide value the first time.
- Handoffs: passing work from one role to another reduces the knowledge of that task and can result in defects or a longer time spent understanding it.
- Delays: anything that either delays the start of a value adding activity or that makes a value adding activity take longer than it should.
- Task Switching: deep concentrated thinking is required for even minimum effectiveness as a software developer. Interruptions are the ultimate enemy of deep concentrated thinking, and any task switch constitutes an interruption.
- Defects: if the impact of a single defect is constant, the waste created by that defect increases with time until detected
Supermarkets, car manufacturing and now software development have proven ways to reduce waste. It is up to us to learn how and act accordingly.
Want to reduce waste in your software development process? We can help:
- An assessment on your organizational practices
- Call one of our coaches to help you adopt or improve your Kanban process:
- Build the Value Stream Map of your process
- Build the visual board and identify the work in progress
- Define policies to help you keep a constant level of quality
- Facilitate a retrospective to improve your flow
- Attending the “Lean Kanban” workshop, also available in-company
- Attending the “Certified Kanban Workshop” workshop with Mattias Skarin
If the situation is more complex, we would be happy to create a customized package for your needs.
Just to play devil’s advocate, don’t forget that one man’s waste is another one’s error margin. Maybe you’ve heard of entire industries shutting down temporarily because one factory was flooded and since everyone downstream was using kanban nobody had any warehouse stores. Also, passing off work allows everyone on the team to learn several parts of the project, which will come in handy when one of them is hit by a bus, or simply put on a bus. As for delays, does that include time taken to sit and think about the problem? Because that’s not a waste… yet many managers see it that way.
Last but not least, where have you read that supermarkets return expired food? Way I heard it, they throw it away, to the tune of 1 billion tons a year in the US alone. And that’s one of the most appalling forms of waste I can think of.
Thanks for your comment. There are more nuances to the Kanban approach than can fit in an introductory blog post. I hope I can clarify a few.
I think the problem with Kanban, as with agile, usually comes from forgetting the base principles. These methods should be applied mindfully; whenever they aren’t and something bad happens the method gets blamed. Because we do kanban, we shouldn’t forget everything we learned about risk management, or software architecture, or strategy, or intelligent problem solving.
Regarding the flood example, I think there’s a hidden misconception there. “Reducing inventory” doesn’t mean “wiping out inventory”. Kanban didn’t force the companies to have no warehouse; it was their own decision. Other factors come into play in this decision: the cost of having a warehouse, the cost of a disaster etc.
With regard to software development, I often see the type of thinking you described and it goes against the lean principles that are kanban’s foundation. Software development is knowledge work, and building knowledge inside the team is a primary objective in lean. The way we do it in practice is not by passing work around, but by limiting the work in progress to be less than the number of team members so that people have to work together on the same task, usually through pairing. Learning items should be part of any backlog, be it for lean or agile. From my experience, when we worked with the team to create the kanban board and make the work visible, managers shifted their focus from micromanaging people to asking relevant questions about the work in progress and figuring out how to help the team get better. (Of course, some managers don’t need kanban to do it, while other managers won’t stop micromanaging even with kanban – it’s a tool, not a silver bullet).
As for supermarkets, Iuliana has experience with local food industry and lived the situation described in the blog post. Maybe the example came out as too general; thank you for that, we will try to edit the post so that it’s clearer.