Governance
When we empower Stream Teams to own the delivery of outcomes, we are delegating responsibility but not abdicating accountability. The Product Team is accountable for achieving their business targets. We need to ensure that the Stream Teams are working on the most important areas and that they are working efficiently and effectively. This is where our governance practices come in.
Where are we spending our money?
As companies scale it can become overwhelming to identify all of the different initiatives that are taking place across the organisation. ZeroBlockers helps with this by funding teams instead of projects. It is easier to identify and validate which parts of the product are receiving funding.
But the second challenge of where are we spending our money is that we need to know what the teams are doing with the money. In a project model, the PMO would track the projects so that senior leadership would have visibility of all of the different initiatives. We want Stream Teams to move quickly trying out new ideas and invalidating them or iterating on them until they work. The speed of the Stream Teams means that updating the PMO would be a considerable drag on performance as well as overwhelming for the PMO.
Instead of adding another step, we can use the tools that the Stream Teams use to track the work they are doing to provide transparency to Product Teams and senior leadership.
Stream Kanban Board
One of the challenges of a traditional Kanban Board is that you can lose the forest for the trees; there are so many low-level tasks that it is hard to see the bigger picture of how the tasks relate to a feature. The Stream Board is intended to contain both the low-level detail of what teams are working on but also contain the context of the larger feature that is in development and the rationale for why the feature is being worked on including the underlying opportunity, the personas / job being targeted, the target metric, the expected outcome and the hypothesis of why the team believes this solution will achieve the outcome.
The Product Team can collate the contents of multiple Stream Boards into a single, more condensed, Product Board to ensure that they are aware of the activities taking place across the product.
Is it working?
The Product Team is ultimately accountable for the success of the product. They need to ensure that the Stream Teams are working efficiently and effectively.
Stream level
The Weekly Stream Review is how the Product Team can gauge the performance of the Stream Team. The review consists of multiple dashboards of trends for the key product and business metrics related to the value streams of the Stream Team as well as the product as a whole. For teams whose value stream includes acquisition or engagement, the review should also include go-to-market metrics such as customer acquisition cost, channel efficiency, awareness reach and message-to-action conversion. A team whose product metrics are improving while acquisition is flat has built something great that nobody is finding — that gap should surface in the weekly review. The purpose is to identify trends in the metrics so that teams can get ahead of any potential issues. It also provides the Product Team the opportunity to validate their assumptions about the correlation between the product metrics and the business metrics. If the metrics are consistently not being achieved then the Product Team should restructure or disband the Stream Team.
Product level
The Weekly Business Review is how the Ecosystem Team can gauge the performance of the product. The review is similar to the Stream Review but it covers all of the key metrics whereas the Stream Reviews focus more on stream-level metrics. The purpose is the same though, to identify trends in the metrics so that the Product Team can get ahead of any potential issues. Similar to Stream Reviews, if the metrics are consistently not being achieved then this could trigger a leadership challenge in the Product Team.
Can we ship safely?
Empowered Stream Teams release their own software. The traditional alternative, a centralised QA team running a regression cycle before every release, is the dependency that this framework is designed to remove. But removing the gate without replacing the discipline is how outages happen. ZeroBlockers replaces the stage gate with a graduated traffic-light release model that scales oversight to the team's recent track record.
| Status | What it means | How a team earns it |
|---|---|---|
| 🟢 Green | The team releases autonomously. They own their testing, their deployment and their sign-off. There is no external review. | The team has a stable history of clean releases, comprehensive automated tests, working observability and a fast rollback path. |
| 🟡 Amber | Heightened attention. Releases still happen but the team and the QA Enabling Team agree on additional checks for the riskier areas. The team must be able to detect and recover from a production issue within an agreed time window or the release is escalated. | The starting position for brand new teams, and after a minor production incident. |
| 🔴 Red | A full pre-release review is required before any production deploy. The team works with the QA Enabling Team to identify the gaps in their testing, observability or rollback capability and close them. | A serious incident, a pattern of failures, or a deliberate decision to slow down before a high-risk launch. |
A team in Red earns its way back to Green by shipping a defined number of clean releases (typically two or three) with the additional checks in place. The status of each team is visible across the organisation to create peer pressure and let team pride do most of the policing.
The traffic-light model preserves the speed advantage of empowered teams while giving the organisation a predictable, transparent answer to "is this team currently safe to release?". Teams who are doing the work well never feel the gate. Teams who are not get help to improve.
Can we do even better?
Another key aspect of governance is ensuring that we are always improving. This is achieved through two key areas: process improvement and task improvement.
Process improvement
There are infinite ways to change how we work but not all are equal. Stream Teams should use the process vision of having zero blockers from idea to satisfied customers and the Theory of Constraints to identify the bottlenecks in their process. This enables prioritisation of potential improvements. Since Stream Teams are accountable for the outcomes they deliver they have the necessary authority to make changes to the way they work. But like product development, some ideas sound great in theory and yet fail to deliver the expected benefits. Teams can reuse their research, design and delivery skills to identify the improvements they believe will deliver the best benefits and then run experiments to validate their improvements. Improvement stories can be tracked alongside feature stories on the Stream Board.
Task improvement
The skill levels of the individuals within a Stream Team impact the quality of the outcomes of the activities that they perform. Enabling Teams are responsible for streamlining the performance of the Stream Teams which includes training to directly increase skills as well as creating best practice guides and templates for common tasks so that teams do not have to reinvent the wheel. Finally, the Enabling Teams are responsible for identifying the best tools in the market that meet the needs of the Stream Teams.