The ZeroBlockers Framework Principles

Best practices emerge from the underlying principles of what you are trying to achieve coupled with the context in which you are trying to achieve it.

These are the principles that the ZeroBlockers framework is built upon.

Principles

1. We don't know exactly what customers want

We're experts and we have years of experience so of course we believe we know what our customers want. But the data shows otherwise - 90% of features fail to deliver the expected business value. We spend a lot of time trying to improve the efficiency of how we build software products but it doesn't matter how efficient we are if we don't get a return on our investment. Therefore, we need to reduce the risk of failure upfront which means we need to identify and validate our assumptions before we invest in building a solution.

2. We can't manage dependencies, we must remove them

We can reduce our upfront risk but we can't eliminate it. We need to be able to do quick iteration on our products to get critical feedback from customers. The challenge is that there are a lot of blockers stopping teams from delivering small iterations such as architecture reviews, stage gate sign-offs, and change control boards. We need to replace these blockers with internal processes that deliver the same benefits so that we can safely deliver more frequently and learn from our customers.

3. We need to move authority to the information

Reducing risk and enabling teams to deliver more frequently is only beneficial if teams can change the solution that they are working on as they learn from their customers. This means that we need to shift from deciding on the solution upfront in a business case to empowering teams to deliver the underlying outcome that we are hoping the solution will deliver. While this requires a lot of trust, once teams are empowered and autonomous we can hold them accountable for the outcomes they achieve and not just the outputs they deliver.

4. We need to encourage innovation internally

You cannot create a cross-functional team with every skill and capability that you need. This means that Stream Teams will need to collaborate with other teams across the business. The challenge is that functional departments have their own ways of working and their own priorities which can slow down product development. Given that these internal departments are monopolies there is limited incentive to improve their processes. We need to introduce a product way of thinking, coupled with competition, to encourage these internal departments to innovate and improve their processes.