October 2021 Archives

Domain Teams and Product Definition

A bunch of teams are responsible for various domains, be it systems or services. Each domain team has its own backlog. For example, in an e-commerce company, there are domain teams responsible for website, OMS (Order Management System), WMS (Warehouse Management System), payment system, etc. They develop features from those domains, such as adding a payment method, managing shared order, tracking shipping status, etc.

What change do we bring onto these teams in LeSS adoption? There are two essential elements in LeSS organizational design - feature team and one product backlog. How does this domain team structure differ from LeSS structure?

One Product Backlog or Feature Team?

At first glance, these domain teams seem like feature teams, as they are customer oriented to some extent. Then, the change would be towards one product backlog. Instead of each team focusing on one domain (team A/B/C for domain A/B/C respectively), all teams will work on whatever features at the top of the backlog.

Let's look at a product backlog as below - all items belong to only one domain. A/B/C in the backlog indicates the domain each item belongs to.

domain teams and product definition - 1.jpg

In this case, the domain teams are indeed feature teams, while the main change would be to share one product backlog for maximizing the value delivery globally, i.e. among all domains. In order to share one product backlog, the teams need to transition from single-domain to multi-domain.

Furthermore, let's look into customer value. Does value come from one domain or across multiple domains? How much percentage from one domain, and across domain? Let's look at another product backlog as below - many items are cross-domain.

domain teams and product definition - 2.jpg

In this case, the (single-)domain teams are essentially component teams. If we keep them intact, teams can't deliver many items from end to end. Therefore, the first change would be to create cross-domain feature teams 1/2/3. Team 1/2/3 can be fully cross-domain, each team covering A+B+C; or partially cross-domain, e.g. covering A+B/B+C/A+B+C by team 1/2/3 respectively.

Often, we don't introduce another dimension of specialization for these feature teams any more. Instead, we let them share one product backlog. However, if necessary, we can still take smaller step in first creating cross-domain feature team specializing in some customer dimension.

In either case of the above backlogs, we will create multi-domain teams, but for different reasons. When values come from single domains, those (single-)domain teams are feature teams, multi-domain teams are created to globally maximize value delivery (further refer to Number of backlogs and multi-learning: 4) specialized feature team). When values come across domains, those (single-)domain teams are component teams, multi-domain teams are created to first speed up end-to-end delivery (further refer to Number of backlogs and multi-learning: 2) functional team and component team).

Product Definition

The deeper meaning of feature team connects to the product definition. "The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product." (further refer to Is team in Scrum feature team?) So, when single domains are defined as products, those (single-)domain teams are feature teams. When multiple domains all together are defined as a product, those (single-)domain teams are not feature teams anymore; the feature teams in the new context need to be cross-domain teams.

This change relates more to the LeSS guide "feature team adoption map" as below.

domain teams and product definition - 3.jpg

In fact, Y-axis shows the gradual expansion of product definition. The scope of feature team gets broader - from single-domain to multi-domain - when the product definition gets broader. In fact, by creating one product backlog to include multiple domains, we implicitly expand the product definition.

In the LeSS guide "define your product", one of the questions that expands product definition is "our product is part of? what problem does the product solve for end-customers?". Let's apply this question in the example of e-commerce. Initially, we may treat OMS as a product, and OMS team is a feature team. Then, as OMS product is part of the e-commerce solution, we expand our product definition to e-commerce. OMS becomes a component in the expanded product, thus OMS team becomes a component team. To make it a feature team, we expand its scope to e-commerce.

In the same guide, there are also questions that restrain the product definition as practical. One of them is "what is the product vision? who are the customers? what is the product's customer domain?". Applying this question here, it is also possible that the company decides to focus on developing an OMS or payment system rather than the whole e-commerce solution, then, OMS or payment system becomes the product. Accordingly, OMS or payment teams become feature teams.

In conclusion, the change on the domain team structure is closely connected to product definition. A feature team often becomes a component team when product definition expands, while product definition may be implicitly expanded when creating one product backlog. In fact, the fundamental change is the expansion of product definition!

The Necessity for a Product Group Owner

There are a few teams each having its own PO (Product Owner), is there a need for an overarching PGO (Product Group Owner)?

Blog - PGO 1.jpg 

I have recently encountered two different configurations, and let's explore them one by one.

1. Teams are responsible for elements in the product 

Blog - PGO 2.jpg

In the above configuration, each team is only responsible for elements in the product, but not the complete product. Is there a need for a PGO? 

Blog - PGO 3.jpg

Those element teams are essentially component teams. Their POs are not real POs, as they are not able to maximize customer and business value on their own. So, the answer would be yes - an overarching PGO is necessary for the complete product. Meanwhile, those POs should not exist. Then, isn't the PGO really the PO? Yes, indeed. We don't need a PGO, but a real PO. Therefore, in this configuration, there is one PO with three element teams (illustrated in the above diagram). While there is one product backlog for the complete product, however, as those teams can only develop elements, some product backlog items will inevitably be across teams. You may consider an alternative structure - feature team.

2. Teams are responsible for complete products

Blog - PGO 4.jpg

In the above configuration, each team is responsible for a complete product. The difference from the last configuration is that POs here are responsible for maximizing customer and business value on their own. Is there a need for a PGO? 

Blog - PGO 5.jpg

The first answer would be no (illustrated in the above diagram). Each PO works with one team to develop own product independently. There is no need for an overarching PGO, but only three POs working in parallel. 

Blog - PGO 6.jpg

What if we have five teams, how many teams should work on each product? Each PO can't decide on its own. It is possible that they form a committee to deal with this kind of portfolio question, but it is more common to introduce an overarching role to decide. So, the second answer would be yes (illustrated in the above diagram). The PGO is essentially a product portfolio manager. He together with POs regularly reviews the portfolio and adapts. For instance, the portfolio this year is: product 1/two teams, product 2/two teams, product 3/one team; but the portfolio next year becomes: product 1/three teams, product 2/one team, product 3/one team. Within each product, POs still have the complete authority to decide the work priority and are responsible for maximizing value. 

Blog - PGO 7.jpg

When those portfolio decisions need to happen more frequently, we can move toward one shared product backlog, so as to embrace the change on sprint basis. Then, the third answer would be yes - an overarching PGO is necessary for the overall product group. Do we still need those POs? Because there is only one product backlog and one priority, we don't. In LeSS, this is called expanding the product definition. Product group becomes the expanded product. The PGO really is the PO (illustrated in the above diagram).

One last question, what is product group? In some cases, those products in the product group sell independently. Product group is just a group of independent products, but it optimizes the value of the whole group by prioritizing together within the product group. In other cases, the product group sells the system, consisting of those products. In fact, each product becomes an element in the complete system. This goes back to the first configuration.

About this Archive

This page is an archive of entries from October 2021 listed from newest to oldest.

September 2021 is the previous archive.

December 2021 is the next archive.

Find recent content on the main index or look in the archives to find all content.