Creating Stream Teams around Value Streams

In our last article, identifying the value streams in your system, we end by saying that not all value streams are equal. Some are small, some large, some complex and some simple. If we want to build teams around these value streams we need to be able to reconcile the difference in value stream size and complexity.

The first step is to categorise our value streams along three different axes: strategic priority, market differentiation and cognitive load.

Strategic Priority

You could have identical products but with very different stream team structures based on the strategic direction of each product. For example, let's say you are working on an e-commerce platform. If you are in a high-growth phase, you might want to focus on the product range, search functionality, recommendation engine and reviews features. If you are in a cost-cutting phase, you might want to focus on the efficiency of the supply chain, shipping costs and minimising the risk of returns. If your current strategy is to lower churn and increase customer lifetime value you could focus on the customer service, loyalty program and personalisation features.

It is easy to say that every part of your product is important. But strategy is about making the hard choices. A good strategy says where you are willing to let service and quality slip in order to excel in other areas. Making this explicit will help you allocate the right resources to the right areas.

Market Differentiation

There are four stages of software development: genesis, customisation, productisation and commoditisation. In the genesis stage, you are creating a new product that has never been seen before. In the customisation stage, you are creating a product that may already exist but you are making it unique to your particular needs. In the productisation stage, you are creating a product that is valuable to a particular market segment. And in the commoditisation stage, you are creating a product that is valuable for everyone. Only the first two stages are worth investing in. You need to avoid the trap of investing in parts of your system that would be better off being bought off the shelf.

The size and complexity of modern products means that there will be elements of all four categories in your product. Lets use the e-commerce platform example again to illustrate this.

Genesis: You could have a proprietary technology for doing virtual avatars of customers to try on clothes. This is brand new but because it gives you a competitive advantage it is worth the high investment.

Customisation: Even though recommendation engines exist in the market, you have unique requirements that give you a competitive edge on your competition so it is worth building internally.

Productisation: Customer service is a must, but you can reduce costs using an AI chatbot. There are a lot of competing chatbots on the market so you can choose one that best suits your needs.

Commoditisation: Finally, you need to host your site. There are a lot of cloud providers offering hosting services with very similar features. so again, you can choose one that suits your needs best.

The best way to identify where each part of your product fits is to use the Wardley Mapping process. You start with the customer need and then list all of the different components of your product that are required to deliver on that customer need. Then you map them on a graph with the x-axis being the level of evolution of the component and the y-axis being the value to the customer. Where you position each component on the map is more of an art than a science but by involving the full team in the process, you can use the diverse perspectives to get a more accurate map.

The value streams and system components are not an exact 1-to-1 match but they are often close enough. If a component spans multiple value streams then it is worth validating its maturity stage in both locations.

Cognitive Load

The final dimension is the cognitive load of the value stream, which is a combination of the complexity of the technology and the complexity of the business domain. There is only so much complexity each team can handle before unexpected side effects start slowing down performance.

Accurately measuring cognitive load is difficult. But you can get a rough idea by looking at the number of different technologies used in the value stream, the number of different business processes involved and the number of different stakeholders that need to be consulted. There is a technique called Blink Estimates, where you discuss the different value streams with the team and ask them to give a quick estimate about how difficult they think it would be to work on that value stream. You will find that most people tend to converge on a similar estimate. If there are any outliers you can discuss what they believe causes the additional or lower complexity.

After you have categorised each value stream you should have an idea of which elements you should build in-house and which require more or less focus.

Assigning Skill Sets to Value Streams

Once you have a list of value streams with relative weighting, the next step is to identify the skill sets required to deliver the value stream.

In the article processes need visions too, we highlighted that a stream team needs to be responsible end-to-end for their value stream. This is because we don’t know how customers will react to our products. We need to work in really small batches starting with the research to really understand what customers need and then teams need the autonomy to be able to be able to experiment with ideas and iterate on them to uncover a solution that customers really want.

In a project-world, the end-to-end flow can involve dozens of different specialists, each contributing to one of the steps of the flow. However your stream teams cannot have dozens of people as the communication overhead would slow down the team, and it is not an efficient use of everybody’s time.

So what is the right number of people on a team? You should start from a default position of one person per value stream. A developer.

With one person trying to do everything though the level of quality will suffer. They likely do not have high level skills in research and design which will limit the quality of the work they can do. But since people are expensive you should query every new person that you add to a team.

For value streams where you believe the user experience will be a differentiator then you should add a designer as well. For teams, where you are working on new and novel tech you should add a researcher to dig deeper into the customer pain points and unmet needs to avoid the trap of building what you think customers will love and actually build what they want.

Multiple channels

Value streams should be created from the viewpoint of a customer, and since customers assume your mobile apps and website should behave the same it is often wise to support multiple channels with the same team. This means that you might need to add more specialised technical roles such as dedicated backend, frontend, mobile engineers. But this can start getting very expensive.

A recent trend to counter this cost explosion is the use of a single stack for mobile, frontend and backend. Technologies like React, NodeJS, htmx and WASM are enabling this trend. There is a similar trend in design where designers are expanding into interaction design, service design and more.

Some skills like machine learning and mainframe systems will still require specialist skills though, for now.

Business Experts

Finally, you should look at the business experts that can add value by being a permanent member of the team. If the value stream is in the Awareness phase then a marketer should be on the team, if it is in the Usage phase then customer support and operations experts would be valuable.

Continuing the e-commerce example, you can find a sample list of roles for value streams below. Your teams will obviously be different, but the important point is to argue for each additional role and why the responsibilities cannot be spread across the existing team members.

Designing Teams

In the simplified example above we have five different value streams. But that doesn’t mean that we have five different teams. we can assign multiple value streams to teams based on the overlap of required skills, the cognitive load and the relative priority.

In the example above, we could have three teams:

Funding Teams

To date we have been looking at our idealised team structures. But the salaries of the people in these teams need to be paid so we will need to put together a case to justify the costs to secure the necessary funding.

In the next article, we’ll go into the ways of funding teams and the governance approaches you can use to verify that teams are performing.