ComparisonScaling Software Development - ZeroBlockers vs Kanban: Which product development framework is better for you?

There are a lot of similarities between the frameworks. They both visualise work, limit work-in-progress, and focus on continuous improvement. However, there are also some key differences.

Kanban focuses on the delivery of a defined solution while ZeroBlockers starts earlier in the process, focusing on the discovery to identify the best opportunities, design to evaluate solutions and then the delivery of the solution.

While Kanban advocates for limiting work-in-progress it doesn't give teams any strategies for breaking up solutions. Releasing software has a cost involved, and since it isn't a core metric that teams are tracked on, it encourages teams to do demos instead of actually releasing a working increment. If you don't need to release it is more efficient to break features into separate technical component pieces. This is more efficient per component, and it enables a demo but the system can't run until every component is done.

In contrast, ZeroBlockers forces teams to release early and often by making it a core metric. The framework gives teams strategies for breaking down solutions into working iterations so that teams can achieve very short lead times and get the critical feedback required to improve their products.

The other core difference regarding efficiency is that Kanban focuses on how a single team operates but often the biggest challenges are how teams work together. As companies scale the number of dependencies between teams increases and this slows down delivery. ZeroBlockers focuses on removing these dependencies.

Kanban doesn't explicitly define that there is a PO role but this is a common implementation as Kanban often evolves from SCrum as teams realise that they can be more efficient moving from defined sprints to continuous delivery. This means that there are still the same challenges such as a separation between the business and IT. The business are the stakeholders who define the features to be built in a business case. The PO then prioritises the order of delivery of the signed off features and business stakeholders confirm their acceptance during the demos.

ZeroBlockers takes a completely different approach because the core principle is that you cannot know how customers will react to new features until they have them in their hands. It is not fair to ask a business person to specify the outcome of a feature because we don't know. We all have ideas that sound great but few of them work. Therefore solution evaluation and iteration are integral parts of the process. We empower teams to identify the best solutions and then hold them accountable for outcomes.

Shared code is subject to the tragedy of the commons. Each team has a tight deadline so they need to cut corners at the end. While Kanban advocates identifying bottlenecks, of which technical debt may be one, it is very hard to improve the code base when other teams are increasing the debt in the shared code base. That is why in ZeroBlockers each team owns their own code. They are responsible for ensuring the health of their code so they can work sustainably.

Kanban advocates for identifying and removing bottlenecks but the challenge is that you rarely remove complexity, you are usually transferring it elsewhere. To remove a bottleneck another function normally needs to change how they work. This can be challenging unless the team is cross-functional.

ZeroBlockers also wants to remove bottlenecks with a vision of having zero blockers in the flow of work. By advocating for cross-functional teams ZeroBlockers can more easily implement the necessary changes to improve the flow of work.

Burnout isn't caused by challenging targets or high workloads. It is caused by being held to targets that you can't control such as an unrealistic deadline that was imposed on you. By giving teams autonomy over the way they achieve the product goals you are putting them in control. We can still set challenging stretch targets but, once teams can control how they achieve the targets, this can energise rather than cause burnout.

Kanban doesn't explicitly define any team members or events but teams often evolve from Scrum to Kanban so they keep similar structures, at least initially.

The core difference between the frameworks is that Kanban focuses on the delivery of the solution while ZeroBlockers starts earlier in the process, focusing on the discovery to identify the best opportunities, design to evaluate solutions and then the delivery of the solution. This means that in ZeroBlockers we have skills and events dedicated to the discovery and design phases.

The Kanban framework has an advantage in implementation because it is more established, requires less changes and has more support.

ZeroBlockers involves changes across the business - because software is integral to our products today - not something just tacked on. This means you need more buy-in to get started. But you can start small - one product, one value stream. With over 10 years of UXDX content and case studies, there is also a large body of resources to assist in the rollout of the framework. It might be tougher to implement but it will deliver better outcomes.