ComparisonScaling Software Development - ZeroBlockers vs Scrum@Scale: Which scaling framework is better for you?

Both frameworks identify dependencies and blockers as the cause of the slowdown in delivery as companies scale.

Scrum@Scale addresses this challenge by introducing a new team, The Scrum of Scrums, to manage and limit the impact of the dependencies. There is a lot of effort in upfront Scrum of Scrums planning to identify and avoid dependencies.

The ZeroBlockers approach stems from the belief that you cannot manage dependencies. The overhead involved continually increases and the teams end up being blocked anyway. The blocking dependencies must be removed to improve efficiency.

Scrum@Scale uses a single Scrum of Scrums product backlog across multiple Scrum teams. The Chief PO is responsible for defining the features and prioritising them accordingly. The Scrum@Scale Guide recommends prioritisation based on value creation, risk mitigation, and internal dependencies. The challenge is that since the Chief PO is defining the solutions the team is only accountable for building the solution and not the effectiveness of the solution.

ZeroBlockers believes 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. The core metric is whether customers change their behaviour as a result of the feature.

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 Scrum@Scale advocates adding technical debt reduction items to the backlog based on team and Scrum of Scrums retrospectives it is difficult to fix all of the issues given the incentive to produce debt in every sprint. 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.

There are a million ways we can change how we work but not all of them are improvements. Even though managers have a lot of experience comparing improvements can lead to battles of opinions unless there is a clear vision. ZeroBlockers has a vision of having zero blockers in the flow of work so teams now have a target to aim towards and something to use to compare alternative options for improvement. You'd be surprised how much time this saves.

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.

Scrum@Scale follows a traditional Scrum approach at the team level with a PO defining what is to be built and the team building it.

The ZeroBlockers approach is that we don't know exactly what customers want so the team needs to uncover the best solutions to build. This means that the team needs to do research, ideate on potential solutions, evaluate them using experiments and then build the winning ideas iteratively so the team can continue to improve the solution over time.

In Scrum@Scale scaling is achieved by breaking a large product into multiple Scrum of Scrums. The Chief Product Owner works together with the POs to define the scope of work for each Scrum of Scrums. Managers shift from making detailed decisions about how teams operate to enabling teams to be self-managing and self-organising.

The ZeroBlockers approach is similar to Scrum@Scale in that it splits up a Product into different areas to reduce complexity and managers are to help teams be more self-managed. However ZeroBlockers goes another step in that teams have autonomy over their backlog, architecture and path to production. This frees up the Product Team to focus more on the strategy and validating that the initiatives being worked on by the Stream Teams are achieving the desired business goals.

Both frameworks scale the product/program level approach to the portfolio level. The same challenge as described at Product Level apply here as well. By empowering teams to identify their own solutions they can be more innovative, respond quicker and be held accountable for outcomes. The Portfolio team can focus more on strategic goals and validating the effectiveness of the Teams.

Scrum@Scale builds on the Scrum operating model which is already in place in many organisations. This, coupled with the fact that the changes involved in implementing Scrum@Scale are largely limited to the IT department, makes implementation easier compared to ZeroBlockers.

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.