I wrote about the 5 most common arguments against Kanban in my e-book Kanban for Skeptics.
- We lose our ability to plan
- It will take longer
- Things will get stuck — we can’t keep WIP limits
- Stakeholders don’t care about feeding the flow
- We will lose team cohesion
My request to the readers was to send me new arguments and help me to improve the book. Seems like the most popular argument against Kanban is: “Software development is not manufacturing“. In the latest version of the book, I added a response to this argument by comparing the design phase of a car and manufacturing.
When you learn about the origin of Kanban, people quickly understand that a WIP limited pull system makes a lot of sense in manufacturing. Even in industry, most manufacturers have jumped on the lean wagon, trying to bridge the gap that Toyota has created decades ago. Lean manufacturing nowadays is mainstream in modern industry, there’s not much more to gain there.
The major battlefield lies in product development. Consumers want new products at a much faster speed than they used to. Companies that are able to create new products at a faster speed, gain an enormous advantage on their competitors.
Developing a new idea from concept to product is a completely different game than assembling a product en masse. It is characterized by:
- creative thinking
- continuous testing of new ideas
- seeking as much feedback as possible
- intense discussions
This feels quite similar to a software development project, doesn’t it? Especially since most software applications are only created once, and certainly not reproduced over and over again.
Environments like these are hard to manage, let alone plan. It is no surprise that in most organizations the life-cycle of designing a new product takes years. An increasingly number of organizations starts to feel the need to reduce their time to market. Lean product development tries to offer a solution by attacking waste in product development head on.
Software industry folks will instantly recognize some of the characteristics:
- Strong leadership
- Cross-functional teams
- Set-Based Concurrent Engineering
- Short feedback loops
- Focus on the customer and supplier
- Cadence, Pull, and Flow
This looks a lot like Agile, right? Aren’t we applying the same principles in Agile projects?
- the Product owner role
- Cross-functional teams
- Delivering working increments
- Time boxed iterations
Indeed we do! It’s the only way to deal with a world that is full of hypotheses and uncertainty. Instead of trying to predict the future, we acknowledge its uncertainty and organize our-self to learn fast and make good decisions.
Now how does Kanban fit into this picture? First you need to change your perception. Stop looking at Kanban as a tool that helps to improve your progress efficiency, because it’s much more than that. Look at Kanban as a way to introduce pull into your product development teams, a major waste reduction. Instead of holding on to a plan, we focus on learning and adjusting our course accordingly. Just as lean product development says: ‘Create multiple alternatives and gradually eliminate the weaker options’. The concept of feeding a Kanban flow matches perfectly. Limiting WIP will give you fast feedback and makes it easier to adjust course. If a cadence is useful for keeping focus or creating rhythm, do so. Kanban allows you to work in a continuous flow or in a cadence.
If you take it to an abstract level, lean product development and lean manufacturing are built on the same ideas and principles. Their actual application differs significantly. Where in manufacturing the focus lies on efficiency, in product development the major focus is dealing with the uncertainty of creativity and innovation.
The same difference is found in the application of Kanban in software development. Software development teams use Kanban to deal with uncertainty. Support and operations teams use Kanban to improve efficiency. Nevertheless, both follow the same principles.
(image by ChrisM70)