Component teams break Flow

Let’s say we’re running an eCommerce business and we have a platform with three main product lines: consumer electronics, books and personalised T-shirts.

Our Engineering department consists of Developers and Technical Leads reporting to a Head of Engineering. Our Product department consists of Product Managers and Product Owners reporting to a Head of Product.

Let’s visualise these roles and use some shape and colour coding to identify them:

Let’s create the customer roles for each of the customer segments as well:

The customer journey is simple. For each product type, customers can:

• search for a product
• place an order
• track and manage orders

The Engineering department

To support the customer journey we’ve set up three Scrum teams: Search, Purchase and Tracking & Management. Each team has its own backlog, its own Technical Lead and its own Product Owner. Let’s visualise these teams:

Let’s assume that:

1. the teams are cross-functional, i.e. backend, frontend and test engineers work together as part of the same team.
2. the system architecture allows each team to build, test and deploy independently using a continuous delivery pipeline.
3. the teams can deploy parts of features to production and hide them behind a feature flag in preparation for a business release.

The business backlog

On the business side we have Product Managers interfacing with customers. For each customer segment we have one Product Manager and a business backlog:

The business backlogs capture the product roadmap: we may have a single roadmap document or a roadmap document for each of our customer segments. At this stage the distinction is not crucial: what we’re highlighting here is that we have business backlogs managed by Product Managers and delivery backlogs managed by Product Owners with teams.

Delivering stuff to customers

In the system we’ve created, how do we get stuff delivered to customers? Actually, it’s pretty straightforward:

1. a feature F on the business backlog gets prioritised by a Product Manager.
2. the feature gets broken down for the three different teams, each team working on the part of the user journey they’re responsible for. Let’s call these increments A, B and C.
3. once all the parts are completed and ready for integration, the feature flags are turned off and the whole feature is released to the customer.

It quickly becomes apparent that even if each team is cross-functional (i.e. they have all the skills required to deliver a potentially-shippable increment) none of the teams can deliver a full feature to a customer, but only parts of a feature. We’ve built component teams.

What are the benefits of this configuration? Well, on the surface the biggest benefit is that each team owns an area of the platform and they have no code-level dependencies on other teams. But is this a real business objective? Not really. Minimising code-level dependencies should be the least of our concerns since in 2022 code-level dependencies is something we can manage very well, with modern practices and tools.

Component teams, in my experience, are still very common and the impact this structure has on Flow and culture is often not very well understood.

In this blog post we’ll expand on the impact on Flow. Then, in a follow-up blog posts, From structure to culture, we’ll discuss the impact on culture.

Finally, in The road to customer centricity we will introduce a structural solution which leads to better culture and improved business agility.

Asynchronous work

The increments A, B and C will be started and completed at different times by the three delivery teams, because they require different effort, and because when each increment lands on a team’s backlog that team is already working on something.

We’ve made the assumption that our teams can safely deploy parts of features to production. Therefore, when for example the Purchase and Tracking team are done with B and C they will deploy them to production behind a feature flag. With the Search team still working on A, the other two teams will now have the capacity to pick up something else and will do so …to keep busy. And there will be plenty of choices because the other two Product Managers have also got stuff in their business backlogs they have prioritised for these very same teams to deliver.

Meanwhile the Product Owner from Search will be attending weekly status update meetings to tell the business when ‘A’ is likely to be completed, since ‘A’ is holding up a business release and no customer value is going to be released until the whole feature is completed.

Could Developers from the other two teams help with ‘A’? In theory they could, but since the Developers in those teams have only worked on Purchasing or Tracking they won’t be too familiar with the Search code. So bringing them up to speed on Search now requires time the Search team doesn’t have: they would rather spend the time finishing increment ‘A’ and move on.

So, we’ve built a system where:

• work happens asynchronously
• none of the teams can deliver something of value by themselves, and
• Developers pick up the work that keeps them busy, not necessarily the work that’s needed to accelerate the next release

For those who are familiar with Flow, this is a system where both WIP (work in progress) and cycle time are higher than they should be.

Interestingly, in this system there is no guarantee that the highest value item on the business backlog will be the first item coming out at the other end of the delivery pipeline. Then what’s the point of prioritisation?

Mispositioned Product role

By assigning a Product Owner to each delivery team, we’ve created an unhealthy coupling between sub-systems in our platform and the Product Owner role which was originally intended as a business role. In our configuration none of the Product Owners is in fact a real Product Owner with access to customers. Only the Product Managers have access to customers.

The Head of Product will have a bigger Product department to manage and spend more time in 1:1’s but — let’s be honest — since the current structure undermines the flow of value these extra Product people are a cost.

This is not to say that the Product Owners are not trying to add value: they are doing their best within the current structure but find themselves in a difficult position: they’re doing all the tactical work to get stuff over the line without having any real access to the market and customer feedback. They are Delivery Managers disguised as Product Owners.

Context switching in Engineering

Sooner or later the Product Managers — who might be line-managing some of these Product Owners — will be wondering why things take so long to deliver. In fact they might conclude that the Engineering department has a “predictability issue” and that the Developers “don’t understand the business, can’t estimate accurately and don’t feel enough pressure to deliver”.

On the other hand, the Technical Leads and the Developers will be hit by escalations and changes of priorities and think that they’re never given the opportunity to work on something from beginning to end and do a good job. With priorities changing all the time, technical debt accumulates and the organisation thinks that Engineering cannot be trusted to deliver.

In our simple example we have shown three component teams with focus on Product and Engineering. In practice, you must have worked with larger companies with more functions (Design, Business Analysis etc.) and twenty component teams: can you recall what the impact on Flow was and how these functions would end up siloed from one another?

Scaling nightmare

Our component teams don’t deliver fast enough because of asynchronous work, high WIP and high cycle time.

What do managers typically do when they think the teams need to deliver faster? They throw more people at the problem: they hire where they think they have a bottleneck. Since Flow is the issue here, not capacity, hiring more people doesn’t make you faster, it just makes you more expensive.

What happens if we hire more Developers? At some point we’ll have enough to create more delivery teams and we’ll assign Product Owners to these teams. Then we’ll have more component teams doing more asynchronous work which makes our problem worse, doesn’t it?

In our configuration, Product and Engineering are siloed — even though we think we have connected them by assigning a Product Owner to each delivery team. In fact Product and Engineering (and other functions they work with) are still growing “vertically” while business value flows “horizontally”

In a follow-up blog post, From structure to culture, we’ll complete the picture by discussing the impact component teams have on culture. And finally, in The road to customer centricity, we’ll discuss how to improve this structure to support business agility. Thank you for making it this far and let us know what you think!