Principle 3 - We need to move authority to the information

Symptom

When teams start to release early versions of a solution they will get valuable feedback from customers. But often they are not able to act on this feedback because they are locked into a solution that was defined at the business case phase. Timelines have been set and suggesting changes based on feedback can be seen as scope creep. This means that teams are not able to reap the benefits of the feedback they are getting.

Cause

There is often a separation between the people who decide what to build, "the business", and the people building the product, "IT".

With the introduction of the assembly line in the early 20th Century, three distinct roles were created: the designer, the manager, and the worker. The designer decided on the product to be built. Managers were responsible for breaking down the build process into separate tasks and defining the best practices for how people should complete them, and the workers were responsible for completing the tasks as quickly as possible.

Mapped into the software development process, the "business" is the designer. They decide on the features to build and create the business case to invest in their development. The functional managers are the managers, they decide on the ways of working for the people in their teams. And the individual contributing designers, developers and testers are the workers.

The Context Change

With the goods in the mass-manufacturing era, demand was largely known before companies invested in building factories. They knew that goods like furniture, automobiles, and appliances had elastic demand so if they could produce them cheaper demand would go up.

With software, however, you never build the same thing twice. You can copy and paste code after all. So we are always building new products, which means our demand is not certain.

The forces the "business" to make assumptions about how people will behave. They are not product experts so they do not know what is possible or the best way to design the user experience. But they have to provide a detailed specification of what they want to build so they go with their best guess.

Frustratingly for management, after features fail to deliver the expected value, nobody takes accountability. The business identify issues like the features were not delivered as intended, the market sentiment changed or a new competitor entered the market. Equally, since the IT team does not have control over what they are being asked to build they say "I delivered the feature, it's not my fault if it didn't work".

Solution

We are treating software development as a delivery problem when the real challenge is in the design of the solutions. You cannot break up a design problem and lock in parts of the design before you have had time to properly evaluate whether it is effective or not. You need to be able to experiment with different solutions and see which one works best. To bring it back to our manufacturing analogy, we are still at the design phase of the process. We haven't validated the design to even set up the assembly line.

Changing software development from a delivery process to a design process requires changes to how we fund work. Instead of funding outputs, where we lock in a scope and limit the ability for teams to learn from customers, we should fund teams to deliver outcomes.

Impact

[Structure Impact]

We need to iterate on solutions from idea through to satisfied customers. This means that we need to work cross-functionally across the business and IT. This is a big shift in responsibility and ways of working for the teams.

Process Impact

Teams are used to building projects according to documented specifications. They are not used to identifying problems to solve. This is a big shift in responsibility and ways of working for the teams.

Funding Impact

Companies have limited resources so they need to ensure that those resources are being used effectively. Business cases let management review the costs and benefits of a project before deciding whether or not to invest in it. Funding teams to deliver outcomes is a big change for, and requires a lot of trust from, finance and senior leadership.

Alignment Impact

Projects with the highest ROI or strategic importance are funded first. Without business cases, there is a risk that funds will be spent in areas that are not as high a priority for the company, or in ways that are not aligned with the company's strategy. This requires new ways of aligning teams.

Governance Impact

Business cases provide clear timelines and budgets to govern against. Without these metrics, there will need to be a shift in how projects are governed which focus more on outcomes than outputs.

Mitigating the Impacts

Structuring Teams

As products grow the number of teams working on the product grows as well. There is a risk that these teams will become dependent on the same code base which leads to frequent rebasing, merge conflicts, and release dependencies which slows down releases.

There are many ways of splitting teams but the most effective way is to split them by value streams. Value Streams are separate flows within the product that deliver value to the customer, often aligned with different steps of the customer journey. The reason we choose value streams is because that is how customers look at our products, so the features that customers are looking for are often within independent value streams.

Our first cross-functional team type is a Stream Team, with each team owning one or more value streams. Stream Teams are empowered to decide what to build and how to build it so the team makeup needs to shift from pure delivery to also incorporate the necessary research and design skills required to identify opportunities and evaluate solutions.

But splitting up the work on a product into separate Stream Teams increases the risk of a lack of consistency in the product experience and overall direction. To solve this we need to introduce a second team type, the Product Team, which is responsible for deciding on the scope of work for each Stream Team as well as setting the overall product vision, strategy and quareterly objectives for the teams.

A Research, Design and Development Process

Since Stream Teams have responsibility for both identifying and delivering the solutions, their way of working needs to change. The new process must includes continuous research, to identify opportunities, continuous design, to identify and evaluate solutions, and continuous development, to iteratively build and validate the solutions. This will require training to ensure that the teams are competent in the new skills required and that they make the transition from a siloed way of working to the more collaborative way of working that is required.

Aligning Teams

When building products there are always multiple, seemingly equal, options for what and how to build. For Stream Teams to be able to effectively prioritise solutions they need to know the context surrounding the product they are building. This includes understanding the long-term vision for the product as well as the more near-term strategy on how they are going to achieve that vision. The Product Team needs to ensure that each Stream Team is aligned on the product direction and the outcomes that the Product Team are trying to achieve.

Funding Teams

The product strategy has to make the hard choices of where we should focus, and where we should not focus which allows us to compare the relative importance of each value stream. We then allocate funding to the value streams, rather than to the teams. This ensures that we are investing in the most important areas of the product.

Since the size of a Stream Team is limited, we can either allocate a single, high-value stream to a Stream Team or we can assign multiple lower-value streams. Stream Teams with less scope will be able to focus more on the specific area and therefore deliver more value.

Governance

By identifying the core success metrics for each value stream we have a way of measuring the value that the Stream Teams are delivering. By setting quarterly objectives for teams we can measure their progress against these objectives and ensure that they are delivering the outcomes that we are looking for.

There is often pushback from teams to be held accountable for outcomes because they are used to being unempowered. If you are held accountable for outcomes but you do not have control over the decisions that lead to those outcomes then you are being set up to fail. In addition, if teams are not autonomous and are not able to release quickly to gather the feedback they need to learn and iterate then they will not be able to achieve the outcomes either. Before shifting to outcome-based governance we need to ensure that teams are sufficiently empowered and autonomous.

Next Steps

With empowered, autonomous Stream Teams in place, the product outcomes should start to improve. But to date we have only focused in on a single product. There are a lot of other teams that Stream Teams need to interact with in order to achieve their goals. Our challenge shifts to scaling cross-functionally across the organisation. This includes thinking about how we can enable parallel delivery of multiple teams and multiple products as well as managing the dependencies between the teams.