The Odd-e Blog

 
The Authors
 

Limits to one Product Backlog - 5

In the previous two articles, we explored the limits from PO (Product Owner) on clarification and prioritization respectively. In this article, we shall look at the limit from teams.

Team's capability on development

Similar to the limit from PO, we are also limited by team's capability on development, as illustrated in the below diagram.

Limits to one PBL 5 - 1.jpg

There is a gap between what team can do and what team needs to do, which creates the anxiety for team. In response to that, more PBLs (Product Backlogs) are created, thus, team needs to do less. This is the rough logic, but let's dive deeper.

How does team's anxiety increase #PBLs (number of PBLs)? There are actually two different scenarios, illustrated as two distinct links in the below diagram.

Limits to one PBL 5 - 2.jpg

  1. Teams decide on their own to only select certain items, which they are more capable of developing. This creates implicit backlogs.
  2. Teams raise their incapability of developing some items to PO, and PO agrees that they can only select other items. This creates explicit backlogs.

What may indicate team's capability on development? "#items a team can develop" is an option. Then, "#items in one PBL" actually means "#items a team needs to develop". Please note that #items here is not about velocity, but about variety.

In the series of "Number of backlogs and multi-learning", we described three types of specialization on various development capabilities - functions, technologies and customer domains. The one directly limiting one PBL is the development capability on customer domains, though, developing in various customer domains often requires different technologies and familiarity with different technical components. So, we may refine the variable into more narrowly focused "#domains in which a team can develop". The updated diagram is as below.

Limits to one PBL 5 - 3.jpg

Limited by team's development capability on customer domains, we create RAs (Requirement Areas), which are customer domains, to accommodate it. Thus, a team only belongs to one RA, and all teams in the same RA share one backlog and one priority. Though, the RA that the team belongs to will change, as the business and market change over time.

Sufficient but not necessary

Within the product (LeSS) and the RA (LeSS Huge), teams should have broad knowledge and are thus adaptive, being able to take any item from the one shared backlog. This sounds as if every team can develop any item. However, it is a sufficient but not necessary condition to keep one backlog and one priority.

There is a LeSS guide called "Prefer specialization in customer domain", and we applied it in an adoption at Huawei. The below diagram (slightly modified to emphasize the domain dimension) and text is an excerpt from the case study.

Limits to one PBL 5 - 4.jpg

"There were 4 noteworthy domains (such as extended OS, patching), and there would be 6 teams. We tried to support the two factors of broad knowledge (for adaptiveness) and good throughput, via (1) having each team able to work in at least 2 domains, and (2) with each domain having at least 3 capable teams. This change made each team still possible to have some level of specialization for throughput, while at the same time enabled the whole group to work on the highest priorities of the Product Owner, without distorted prioritization to meet the limited constraints of rigid teams that could only do one thing."

In this case, we had one product, containing 4 domains. In how many domains did a team need to develop? The simple answer would be 4, as it is likely that all high-priority items come from any of these 4 domains at one time. Then, any team should be able to develop in 4 domains. However, the constraint we set was at least 2 domains. How come? Because in actuality, there were at most 50% of high-priority items from any domain at any time, thus we needed at least 3 teams (half of 6 teams) capable of developing in each domain. This meant 4 domains * 3 teams / 6 teams = 2 domains, in which a team could develop.

If we look at the previous experience where we had 12 teams sharing one backlog, our teams were not homogeneous either. They specialized in smaller domains inside the RA, but when the specialization became limiting, we broke loose by having other teams learn in needed domains.

Postpone RA and keep one PBL

With the above insight, we discover an alternative to RA that would better accommodate the limit of team's development capability, in the sense that it would still keep one PBL. Let's illustrate this with an example.

Suppose that a product contains 4 domains (A/B/C/D), and there are 12 teams developing the product. Our limit is that each team can develop only in 2 domains.

1. Two RAs, two backlogs

The usual approach is to create two RAs, with 2 domains in each. For instance, RA1 with domain A/B and team 1-6; RA2 with domain C/D and team 7-12. This is illustrated as the table below. "x" in the table indicates that the team [1-12] can develop in the domain [A/B/C/D].

Limits to one PBL 5 - 5.jpg

2. No RA, one backlog

With the limit that each team can only develop in 2 domains, can we still keep one PBL? It depends. If one backlog means that every team needs to develop in any of these 4 domains, then, we can't. However, one backlog may only require 8 teams on A (i.e. at most 8/12 of high-priority items from domain A at one time) , 6 teams on B, 6 teams on C and 4 teams on D, then, we can. One possible configuration is illustrated as the table below.

Limits to one PBL 5 - 6.jpg

How do we put this into practice? We first try to understand what we need by asking PO - what is the estimated maximum percentage of high-priority items from each domain at one time? or what is the maximum number of teams that you would likely invest in each domain at one time? We essentially learn about the extent of adaptiveness we need, in terms of how many teams should be able to develop in each domain.

Then, we turn that into the constraint about how many domains in which each team needs to develop. This becomes the input for self-designing team workshop. The constraint may be met through composing teams appropriately or following learning or both. In either case, we mark the team as "can develop". We may make the further distinction between "can develop/skilled" and "can develop/learning". With a new domain emerged, not a single team can, or every team can! Teams decide which teams will first jump in to develop capability in that domain. All those teams are in the sate of "can develop/learning". Nevertheless, do not over-complicate it, as this is just a snapshot, and it is evolving constantly.

Conclusion

Till now, we have explored the limits to one PBL with the following topics.

  1. PO on team or PO on feature?
  2. Experience with FO and sub-APO
  3. Limit from PO on clarification
  4. Limit from PO on prioritization
  5. Limit from teams on development in domains

In the end, I would like to give you a challenge - experiment to have 10-15 teams share one PBL with the ideas from this series. I look forward to your sharing of experience and learning!

 

Limits to one Product Backlog - 4

In the previous article, we explored one of the two limits from PO - the fake limit on clarification. In this article, we shall explore the other limit from PO - the real limit on prioritization.

Real limit on prioritization

Besides the limit on clarification, the other limit is PO's capability on prioritization. Unlike that team can do the clarification, thus PO's capability on clarification is a fake limit; it is generally considered that PO has to do the prioritization, thus PO's capability on prioritization is a real limit. This can be illustrated as the below balancing loop.

Limits to one PBL 4 - 1.jpg

The dynamic on prioritization is similar to the one on clarification. PO's capability on prioritization can be metrified as "#items a PO can prioritize". The gap between the capability (e.g. a PO can prioritize 100 items) and the need (e.g. there are 200 items in one PBL) creates the anxiety for the PO. The most common response is also to increase the number of PBLs, and accordingly, the number of POs, so that each PO needs to prioritize fewer items, as there are fewer items in each PBL.

Limits to one PBL 4 - 2.jpg

When we put these two limits together in the same diagram as above, we find that the main difference lies at which limit comes to effect first. In other words, which number - "#items a PO can prioritize" or "#items a PO can clarify" - is lower? As we know, we need to clarify those items in order to prioritize them. However, the extent for clarification is different when our purpose is for prioritization vs. for delivery. We need to clarify more when for delivery, thus, "#items a PO can clarify" is lower than "#items a PO can prioritize". For instance, a PO can clarify 50 items, but can prioritize 100 items.

In fact, this is the main assumption behind the magic number "8" defined in LeSS and LeSS Huge frameworks. We assume that the limit to one product backlog comes from PO's capability on prioritization, i.e. a PO can prioritize 100 fine-grained items. Other assumptions are: 1) how fine-grained are they? 4 items per sprint per team; 2) how far do we look ahead, i.e. for how many sprints do we keep those items in fine granularity? 2-3 sprints. Based on these, roughly we need to prioritize 12 fine-grained items for one team. Then, 100 / 12 = "8", that is the whole logic.

Prioritize together

However, in our previous experience, we had 12 teams sharing one product backlog, which clearly broke the limit. How did we achieve that? The key lay at FOs (Feature Owners).

"FO tries to maximize the ROI for the feature. He maintains an overview for the feature, prioritizes backlog items inside it, together with APO decides whether to continue the development of this feature or move to other features."

In fact, with FOs participating in the prioritization, we increased our capability on prioritization. The PO together with a group of FOs could prioritize more items.

In our practice, the PO led the prioritization in coarser granularity, while the FOs in finer granularity. However, they prioritized together still in one product backlog, and still inspected & adapted on sprint basis to globally optimizing for customer value. During the regular meeting among the PO and FOs, the PO set the overall priority in coarse granularity, like a priority guideline; while the FOs shared the priority inside respective features in fine granularity and made suggestions about which part of the feature should be done now and which part could be done later, comparing to other features.

There are other ways of prioritizing together. For instance, PO provides the vision and facilitates the prioritization with FOs. This way, they co-create one priority, while the vision acts as the guideline for prioritization.

Limits to one PBL 4 - 3.jpg

In the above left diagram, it shows the change over time on how much PO and FOs decide while prioritizing together. Initially, PO decides the priority all by himself. Then, PO steps back and creates space for FOs to decide. In the end, it is possible that PO mostly facilitates, while the prioritization is done mostly by FOs. PO still owns product vision, but the capability on prioritization increases when FOs decide more in prioritization.

In the above right diagram, FOs is replaced with teams. In the previous article, we explored how the FO role may transition from an external role designated by PO or manager to an internal role emerged through team self-organization. When this happens, it becomes teams or part of them who prioritize together with PO.

According to the LeSS guide "Prioritization over Clarification", PO should mostly focus on prioritization, but delegate detailed clarification to teams. However, this does not necessarily mean that only PO can prioritize. When PO and teams prioritize together, the capability on prioritization becomes less limiting.

Further thought

So far, we have explored the limits from PO, including both the fake one on clarification and the real one on prioritization. Even for the limit on prioritization, we can make it less limiting by prioritizing together.

However, the vision is still provided by PO. Is the capability on visioning an ultimate limit from PO? We have actually explored the topic of shared vision on product. It is possible, though hard, to co-create the vision! While vision provides the guideline for prioritizing together, prioritizing together also enables shared vision. So, there seems not any absolute limit from PO towards one product backlog.

 

Limits to one Product Backlog - 3

What are the limits to one PBL (Product Backlog)? Two major areas are from PO (Product Owner) and team, respectively. We shall first focus on the limits from PO. When people claim that it is impossible for one PO to manage one PBL shared by many teams, there are actually two different limits behind. One is on clarification, based on the assumption that PO needs to clarify items in the PBL; the other is on prioritization, based on the assumption that PO needs to prioritize items in the PBL. We shall focus on the first limit in this article, and the second one in the next article.

Fake limit on clarification

One PBL leads to optimal organizational adaptiveness, however, it is limited by a few factors, one of which is PO's capability on clarification. This can be illustrated as the below balancing loop.

Limits to one PBL 3 - 1.jpg

PO's capability on clarification can be metrified as "#items a PO can clarify". The gap between the capability (e.g. a PO can clarify 50 items) and the need (e.g. there are 200 items in one PBL) creates the anxiety for the PO. The most common response is to increase the number of PBLs, and accordingly, the number of POs, so that each PO needs to clarify fewer items, as there are fewer items in each PBL. If we accept this logic, probably one PBL can only be shared by no more than 2-3 teams.

However, this is a fake limit, as we don't need to let PO clarify all items for teams. Instead, teams can clarify items for themselves, while PO focuses more on the prioritization. This is described in the LeSS guide "Prioritization over Clarification", and can be illustrated as the below balancing loop.

Limits to one PBL 3 - 2.jpg

Team's capability on clarification is the key factor to make it work. It is common that teams at first lack the product knowledge and skills to do the clarification well. Does this mean that it is at least temporarily a real limit to one PBL? Not really, because even in that case we can still keep one PBL.

Keep one PBL

When teams are not ready to take over the clarification immediately, we can still keep one PBL but have some people help the PO on clarification. As those helpers are only for clarification, they don't maintain separate PBLs. Thus, they are not POs, but more like FOs (Feature Owners) described in the previous article. The below part is related to clarification.

"FO does high-level clarification and leads the splitting of the feature into smaller backlog items. Then, he collaborates with teams during PBR (Product Backlog Refinement) to do detailed clarification and define acceptance tests for those backlog items."

This approach can be illustrated as the below balancing loop.

Limits to one PBL 3 - 3.jpg

Instead of having multiple PBLs, we keep one PBL, but have a few FOs to help the PO on clarification. However, please keep in mind that teams will at least participate in the detailed analysis during PBR.

Where do those FOs come from? Let's look at two scenarios, one used to have "team PO" maintaining a separate PBL for its own team, the other without.

  • In the first scenario, "team PO" may not be willing to join the team immediately for valid or invalid reasons. Under this circumstance, we can turn "team PO" into FO, and get rid of its separate PBL. Meanwhile, they still lead the clarification through their product knowledge and skills. This creates one PBL right away, as well as makes a next step towards the vision of PO on prioritization and teams on clarification.
  • In the second scenario, some members may take the lead in actively developing the product knowledge and skills for effective clarification. Is it necessary to introduce FO as a new role, when there was no "team PO" before? Probably no. In general, this relates to the interaction of FO vs. team in clarification.

Feature Owner in transition

Is FO inside or outside team? In our previous experience, it was not clearly defined, but hinted as being outside team. It had the negative impact on the rest of teams.

Limits to one PBL 3 - 4.jpg

The danger with the FO role is shown in the above "shifting the burden" dynamic. FO approach in B1 is the short-term symptomatic solution, while team approach in B2 is the long-term fundamental solution. Furthermore, there is an addiction R loop that drives our dependency on the FO solution. B2 represents the vision, without shared vision, we will stick with B1 forever.

Once we agree on the shared vision, we leverage by decreasing B1 as well as increasing B2. The below are a few possible next steps in tactics.

  • Make FO a role inside team, and let team decide who takes FO for which feature (decrease B1)
  • Facilitate teams to learn and grow product capability during PBR led by FOs (increase B2)
  • Have different team members take FO for various features (decrease B1)
  • Try no explicit FO for one feature and let teams self-organize to clarify (increase B2)

Should we remove the FO role eventually? In fact, I am fine if team decides to keep FO as a dynamic role inside team. As long as team members take FO at various time for various features through self-organization, this role is not any more limiting.

 

Limits to one Product Backlog - 2

The previous article was written in an analytical manner, while in this article I will supplement it with an experience during the time of Nokia Networks. As it happened more than ten years ago, some details may not be as accurate as I would like them to be, but I hope that I still capture the essence. Moreover, I will add my reasoning as an afterthought, while the reality is that we did not reason thoroughly about those changes when they were introduced. Today, I would suggest to first reason about the change by doing system modeling, then get back to the model after the change for learning and adaptation.

One Area

It was an area called TT (Traffic & Transport) in a 3G-based network product. There were 4-5 areas like that in the whole product. We had 12 teams, one area backlog and one APO (Area Product Owner) in TT.

This happened before LeSS had its name, so we didn't actually call it RA (Requirement Area), and there was also some difference from RA. However, it matters little for understanding the changes if you just treat it as a RA, or even a product. All the following changes happened within the scope of TT area.

Two main changes happened, one after the other. Some tensions were developed before them, and the most obvious one was the workload of the APO. As you can imagine, it is a challenge to have one APO for this size of an area.

Feature Owner

APO was overloaded, and he desperately needed someone to help. We introduced the CIO (Content Item Owner) role to lead the development of Content Item, which was just a fancy name for big feature, its development mostly across multiple teams and many sprints. To ease the cognitive load, I will use more generic term FO (Feature Owner) for this role, but keep in mind that those features are rather big.

There are two aspects defined and emerged in this role.

  • Product leadership

FO tries to maximize the ROI for the feature. He maintains an overview for the feature, prioritizes backlog items inside it, together with APO decides whether to continue the development of this feature or move to other features.

FO does high-level clarification and leads the splitting of the feature into smaller backlog items. Then, he collaborates with teams during PBR (Product Backlog Refinement) to do detailed clarification and define acceptance tests for those backlog items.

  • Technical leadership

Unlike PO, FO also exerts technical leadership by organizing the group of senior developers from teams for joint design of the feature and facilitating the coordination of teams working on the feature.

Initially, FO was just a part-time role, and he was still working in the team as team member. Was FO inside or outside of team? I believe that it was not clearly defined, and the team boundary was blurred after the role was introduced. Who selected FOs? By APO and line managers, not by teams themselves. This hinted that it was a separate role outside team.

The part for product leadership was similar to the mode of PO on feature described in the previous article. Teams would work with different FOs as they developed different features.

The part for technical leadership happened more accidentally than designed. When the feature spanned multiple teams, teams simply looked for someone to lead across teams, instead of relying on teams' self-organization.

Over time, some FOs became full-time, as they worked on feature by feature, and spent less and less time working in the team, until none.

How on earth should we understand this role?

  • First, FO is not really PO, because their prioritization is limited in the feature, thus they have limited influence on the overall ROI. In fact, there is no such thing as PO on feature. In that case, the most essential part of the PO role - identify the valuable features - has already gone.
  • Second, FO's main focus is on high-level clarification and splitting, while they work together with teams on detailed clarification to define acceptance tests during PBR. In this regard, it is similar to the BA (Business Analyst) role, which should have been incorporated into teams. Furthermore, it is more like the SE (System Engineer) role, since he works on both product and technical sides. This is not surprising at all, as SE is part of the status quo, while the force to bring us back to status quo is always lurking.

Let's see the subsequent effects from introducing the FO role in the area.

  • How many product backlogs were there in the area? Still one area backlog and one priority decided by the APO. The inspection and adaptation around the area backlog still happened at every sprint in TT.
  • A group of people (those FOs) in the area had actively developed product knowledge and leadership. Regardless of whether they would move towards APOs or back to teams, the capability improvement was real.
  • The rest of teams got less space to develop their product knowledge, and the transparency decreased as well, when APO started to work more with FOs, rather than directly with teams.

Sub-Area Product Owner

At some point in time, we introduced the sub-APO role. We had mainly two sub-areas: TT-IP for IP-based Traffic & Transport, and TT-ATM for ATM-based Traffic & Transport. Back then, some people had taken the FO role for several features, and over time developed strong product leadership in a sub-area. In fact, they were already full-time FOs. Thus, it felt natural to take the next step and turn them into a more permanent sub-APO. It seemed also a natural career path leading to APO. Two additional factors influenced the decision of introducing the sub-APO role. One was that it would make the prioritization easier when we split into sub-areas, because the number of items became fewer in each sub-area. The other was that the reporting structure of teams also evolved into sub-area based, e.g. 6 teams specializing in TT-IP reported to one manager, while 6 teams specializing in TT-ATM reported to another manager. It all seemed quite fitting together.

However, this reflected our sloppy thinking at the time and the lack of deep analysis for the change. For example, we did not see clearly about its impact on the number of product backlogs and further on organizational adaptiveness.

How many product backlogs were there after introducing two sub-APOs for TT-IP and TT-ATM respectively? We tended to say still one, as there was still one APO for TT area. But if we looked at the situation more closely, we found that there were actually two backlogs. Regardless of whether those two backlogs were maintained as views in the same TT backlog or separately, the prioritization mostly happened within each backlog by the sub-APO. In addition, the coupled reporting structure made the teams attached to a sub-area, first psychologically then in ability as well. Subsequently, the more backlogs decreased the overall organizational adaptiveness.

Meanwhile, the need for FOs became less, especially when senior developers in teams could provide the technical leadership.

Summary

The overall journey looks like this: first only APO, next APO plus a few FOs, then APO and a couple of sub-APOs. When I was adding the reasoning for this experience, it felt somewhat messy. I guess that it is because our thinking at that time was somewhat messy. After clarifying the thinking over the years, I shall provide a new perspective in the next article.

 

Limits to one Product Backlog - 1

Recently, I ran across my old article "PO on team or PO on feature?" written about ten years ago, and found that it could be connected to the topic of limits to one product backlog. My thinking at that time touched some factors, but was still vague. Over the years, I have been improving my thinking on this topic, thus decide to write a series about it. Meanwhile, I also decide to take this old article as the first one in the series.

PO on team or PO on feature?

Product Owner is responsible for the product success. Product Owner is the single interface about team's work. In a single-team environment, PO works with that team constantly. It's all very clear.

However, in a multiple-team environment, it gets more complicated. It gets problematic to have one PO work with all teams in the product, when the number of teams goes too big. It leads to multiple POs working with different teams. There is still one PO at product level, who creates PO team with multiple POs. One PO will normally work with more than one team, but not all teams. Since one (big) feature may be developed by multiple teams together, two modes of relating PO and team come up.

  • PO on team

Fix the relation between PO and teams. For each PO, he constantly works with a few teams. Naturally, he manages the part of product backlog that relates to his teams' work.

  • PO on feature

Not fix the relation between PO and teams, but change it depending on the feature that the teams are working on. In this case, PO is responsible for features in the product. Which teams work on those features, PO works with which teams.

I have been suggesting PO on team all along, and I don't feel right about PO on feature. This post tries to clarify why, not only for you, but also for my own.

Benefits and problems of PO on feature

Let's first understand the benefits that PO on feature tries to get. There are mainly two.

  1. PO can specialize on part of the product and some features. For any team to be able to work on any part of the product, though ideal, it may not be feasible to beginning with. The same applies to PO. PO on feature makes it possible for them to specialize on part of the product.
  2. The overall feature can be managed by one PO, so that it reduces the coordination efforts among related teams.

The most obvious problem with PO on feature is, what if one team need to work on multiple features at the same time? If you would allow multiple POs to interface with same team, it would've brought back all traditional problems such as conflicting priority, partial allocation, etc.

But PO on feature does not have to be so. It can still be clear who is the PO for the team at any time. If team works on two features, the PO responsible for the more significant feature (in terms of value, size, etc.) will be the PO for that team in relevant sprints. Other POs need to work with that PO in order to get their stuff done in those sprints. Then, there will be PO switch, as team works on different features. Two POs may work together for transitional period, though only one of them is PO towards team at any time.

Is the above approach ok? I do not think so. There are two deeper problems with PO on feature.

  1. PO on feature creates strong focus on current feature, and does harm to the flow and long-term sustainability. If we'd like to get team high performance in the sprint, we need to make the feature ready before putting it into sprint. That requires progressively grooming the backlog and future features. If we'd like to get our release more predictable, we need to proactively address risks and uncertainties. That requires investing earlier by having spikes. If we'd like to sustain in delivering good quality product release, we need to lower the cost of change. That requires gradually paying off the technical debts from legacy. However, PO on feature favors short-term project thinking.
  2. PO on feature breaks the feedback loop, which is critical for learning and continuous improvement. It is less likely for PO on feature to learn from mistakes such as wishful commitment, sacrifice done, ineffective collaboration on requirements, etc., together with former teams.

In short, PO on feature often leads to imbalance between short-term and long-term thinking and focus, while for the role of Product Owner, it is not enough to be able to maximize ROI for one sprint or one feature, but do that sustainably for the life of product.

PO on both team and feature

How can we realize those benefits from PO on feature into the mode of PO on team? Working in product areas is the key.

On one hand, area should be big enough to accommodate most of features, even though those features are spread into multiple teams. Then, the overall feature is still managed by one area to ease the coordination. On the other hand, big enough area is still smaller than the whole product, thus, PO still possibly specializes in the area.

Regarding the number of teams one PO can work with, some say no more than 2, others say up to 10, my sweet spot is around 5. The size of 5 teams per PO is good for both having some specialization and easing the feature coordination.

Written in 2011.4

 

Follow value in defining RAs

[RA = Requirement Area; PBI = Product Backlog Item.]

In LeSS Huge, there is an additional scaling technique called RA. How to define RAs has confused many practitioners. This article tries to open a perspective.

By which dimension?

By which dimension do we define RAs?

We know that RA is customer centric. RAs are not defined from the dimension of technology or functions, but customer/business domains. However, there could be multiple customer views, which one is more appropriate?

Let's illustrate this question with the following example. The product for development is an e-commerce site. There are two dimensions for consideration while defining RAs.?

Follow value in defining RAs - 1.jpg

1. Process steps

Engage/Find/Buy/Followup are areas based on normal process steps for shopping customers.

  • Engage: engage customers for awareness, example PBIs - home page improvement, live streaming
  • Find: find desired product, example PBIs - product details page improvement, recommendation
  • Buy: buy product with ease, example PBIs - guest checkout, new payment method
  • Followup: provide after-sales service, example PBIs - product review, return handling

2. Cross-cutting

Standard/Special are cross-cutting areas serving different customer needs and scenarios.

  • Standard: standard product & process, example PBIs - home page improvement, product details page improvement, new payment method
  • Special: customized and personalized product & process, example PBIs - recommendation, live streaming, embossing, special packaging, gifting card, group gifting

In the cross-cutting dimension, a variant could be gifting area, grouping all gifting related PBIs.

As you can see, some PBIs fit in both dimensions, while other PBIs fit one dimension better than the other. Nevertheless, assuming that the skeleton is already in place, both process-step and cross-cutting dimensions could reflect customer value. Then, which one is more appropriate?

Think about PBIs

Let's return to the definition of RA. What is a RA? There are three aspects: 1) there is an Area backlog; 2) there is an Area PO; 3) there are 4-8 feature teams in the Area.

The first aspect is the fundamental one, and the other two are derived from it. Area backlog is a subset of the product backlog, and consists of a group of PBIs. Therefore, we can change the question from "by which dimension to define RAs" to "by which dimension to define PBIs".

The below is a snapshot of the product backlog for the e-commerce site.

  • product review
  • shipping status update
  • product details page improvement
  • new payment method
  • embossing
  • guest checkout
  • return handling
  • gifting card
  • group gifting
  • live streaming
  • AR try-on
  • home page improvement
  • ...

All PBIs are customer centric, but some are in the process-step dimension while others are in the cross-cutting dimension. We define PBIs by whatever dimension that carries value. The dimension of PBIs varies as value changes. Sometimes valuable PBIs appear in the process-step dimension, other times valuable PBIs appear in the cross-cutting dimension.

As RAs are essentially a group of PBIs, the same holds true for RAs. We define RAs by whatever dimension that carries value. In other words, we follow value in defining RAs.

The below is an example of how the RAs may evolve in the e-commerce site over time.

Follow value in defining RAs - 2.jpg

One last hint, when many PBIs are cross-RA (or have to be split into multiple RAs), it is the time to consider adapting the RAs.

 

Priority guideline

Our goal is to have one product backlog and all teams are working in its priority order to maximize the customer value. Our current reality is that each team has its own backlog and the so-called one product backlog is actually a collection of many backlogs.

A desired backlog

In the article "The path of least resistance towards one backlog", I suggested to create a desired backlog, which defines the priority that we want assuming no constraint. The actual backlog defines the priority we really follow by taking our constraints (e.g. this team can only do this work) into consideration. The gap between them creates the tension, which drives towards one backlog through reducing the number of backlogs, disrupting the current team boundary, and etc. However, we face two major challenges in creating the desired backlog.

One challenge is lack of motivation to do it, as the actual backlog is sufficient to keep teams busy. This indicates lack of organizational vision to maximize customer value and continuously improve. Therefore, the status quo with collection of backlogs remains and we even pretend that it is the one backlog.

The other challenge is lack of ability to do it, as what is important from the whole product perspective is difficult to answer. This indicates lack of shared product vision and lack of product leadership. A priority guideline could be a first step for the change.

A priority guideline

Comparing to a desired backlog, a priority guideline is easier to create while still serves our purpose, which is to create the tension necessary to drive towards one backlog.

What is a priority guideline? It is a priority list with the whole product focus. Here is an example.

  1. critical customer bugs
  2. product A release 2.0
  3. other customer bugs
  4. product B feature 12
  5. critical/major internal bugs
  6. customer project A1 (based on product A)
  7. product A release 2.5
  8. product B other features
  9. product A prototype based on new hardware architecture
  10. product C ...

In this list, there is more than one product involved. The reason is that many organizations define their products too narrowly and in LeSS they are all parts of a broader product definition.

In essence, the priority guideline is a backlog of coarse-grained items, which is dynamic and updated regularly to reflect the current priority. Moreover, this is a simplified version of desired backlog, rather than actual backlog, as the order of real work is not exactly following the one in priority guideline, which is anyway a guideline.

The key is ... the tension

We could further evolve priority guideline into desired backlog. We make the items in priority guideline more fine-grained, e.g. in terms of epics. By the way, in practice I try to avoid the term epic, as it often introduces unnecessary complexity and confusion. To me, those are all stories or just items, big or small.

tension.jpg

On the other hand, it may be sufficient to let priority guideline drive towards one actual backlog, as the gap between priority guideline and actual backlog may already serve the purpose of creating the tension. Referring to the above picture from the "The fifth discipline" book, both desired backlog and priority guideline act as your vision, while actual backlog is your current reality. The gap between them creates the tension necessary to drive towards one backlog.

Product backlog and Area backlogs

Taking the above view, let's look at product backlog and area backlogs in LeSS Huge.

1. Simple case - items in product backlog and area backlogs have the same granularity.

Area backlog - simple.jpg

As the real work is done according to the priority in those area backlogs, the collection of area backlogs is in fact the actual backlog. Then, what is the product backlog? It is in fact the desired backlog. The gap between them is very visible, which creates the tension for change - requirement areas are dynamic!

2. Complex case - items in product backlog and area backlogs have different granularities.

Area backlog - complex.jpg

Similar to the simple case, the collection of area backlogs is the actual backlog, while the product backlog is the desired backlog. The difference is that items in product backlog are more coarse-grained than those in area backlogs. Nevertheless, it still shows the gap thus creates the tension for change. What's interesting is, as items in product backlog get more coarse-grained, the product backlog devolves into a priority guideline!

 

Percentage of people in special roles

In large-scale product development organization, %(people in special roles) is a good indicator for the degree of self-organization in teams.

Special roles in this measure are outside teams. There is no special role inside teams, as everybody takes the role of team member. Sometimes, the team may define "special roles" inside it, e.g. interface towards other teams. I consider this as their working agreement, because the team has the full authority to decide and change as they wish. The impact of having those internal "special roles" on their self-organization is a separate topic we may explore in the future. In this article, we focus on special roles outside teams.

Please be noted that %(people in special roles) is essentially the same as %(people in teams), as %(people in teams) + %(people in special roles) = 100%.

Its value in LeSS organizations

LeSS organizational design leads to low value in this measure. This is in line with the LeSS principle "More with LeSS" - the less (fewer) roles, the more responsible teams. Let's look at LeSS organization and LeSS Huge organization respectively.

1. LeSS organization

%people in special roles - LeSS org.jpg

Assume that

  • there is no undone department, which is the preferred case
  • there are 5 teams, 7 people in each, that is 35 people in teams
  • there are 1 PO, 3 SMs and 1 manager, that is 5 people in special roles

Then, %(people in special roles) = 5/(35+5) = 12.5%.

2. LeSS Huge organization

%people in special roles - LeSS Huge org.jpg

Assume that

  • there is no undone department, and no support as it is done by normal feature team
  • there are 20 teams, 7 people in each, that is 140 people in teams
  • there are 5 POs (PO team consisting of 1 overall PO and 4 APOs), 10 SMs (competence & coaching), 5 managers, that is 20 people in special roles

Then, %(people in special roles) = 20/(140+20) = 12.5%.

There is usually still undone department and support in LeSS Huge organization, and we consider them as people in special roles too, then its value is often higher in LeSS Huge organization.

Its impact on self-organization

Why "More with LeSS" - fewer roles leading to more responsible teams?

There are mutual effects between special roles and self-organization. Having more people in special roles outside teams leads to lower degree of self-organization in teams, which in return leads to more people in special roles. This is shown in the below diagram as a reinforcing loop. It could be either a virtuous cycle of leading to ever higher degree of self-organization in teams and ever fewer people in special roles, or a vicious cycle of leading to ever lower degree of self-organization in teams and ever more people in special roles.

%people in special roles 1.jpg

If we elaborate on the links in both directions, we get the below diagram. Having fewer people in special roles opens up more space for teams to self-organize, leading to higher degree of self-organization in teams. This in turn decreases the need for special roles, leading to fewer people in special roles.

%people in special roles 2.jpg

Of course, there are other factors too. We add a couple of more variables in the below diagram.

  • Job safety: when job safety is low, even if the need for special roles is little, people would still fight hard to keep their special roles so as to keep the job.
  • Coaching effectiveness: when coaching effectiveness is low, even if much space has been created for teams, they would still be unable to reach high degree of self-organization.

%people in special roles 3.jpg

By now, we have explained why %(people in special roles) would be a good indicator for the degree of self-organization in teams.

Its reality and goal

In reality, many large-scale organizations have a much higher value in this measure. Besides those in LeSS organizations, they may have more of the below special roles.

  • business analyst, including those in the name of team PO
  • project manager, including those in the name of SM
  • technical leader or architect
  • team leader, in addition to SM and manager
  • etc.

What these special roles are doing largely belongs to the scope of self-organizing teams. The most helpful way to proceed is for them to join feature teams, as team members. In fact, this is what is going to happen in LeSS adoptions - simplify the organization to scale up.

Are we going to further reduce special roles after adopting LeSS? In LeSS organizations, self-organizing teams are the basic building block, while special roles are mainly in two kinds.

  1. PO for product vision and direction. If we consider shared vision, it is possible that vision is co-created by teams and product community. See more in Shared vision on product.
  2. SM and manager for team and organizational capability improvement, as coaches and facilitators. Even with team maturing, it is very likely that they still benefit from having some coaches and facilitators around every now and then, if not all the time.

Therefore, the goal is to have low - perhaps not zero - %(people in special roles) outside teams, and have high degree of self-organization in teams.

 

Experiments are at the heart of LeSS

less-complete-picture.png

Frameworks as starting point

If you look at the LeSS complete picture, you see that the frameworks - defined by the rules - and the principles are at the heart of LeSS. However, this is not completely true.

In fact, the LeSS frameworks emerged out of the experiments, in response to the need of novice group in large-scale product development domain. In the first two LeSS books, hundreds of concrete experiments are shared. Those experiments are insightful but do not fit for novice group. We may start from the frameworks, then still move towards experiments. Therefore, experiments are really at the heart of LeSS.

Then, what is the essence of experiments? How do they differ from best practices and patterns?

Best practices and patterns

At a glance, experiments look similar to best practices. The below is the description for best practice in Wikipedia.

"A best practice is a method or technique that has been generally accepted as superior to any alternatives, because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things."

With best practices, we focus on adopting and spreading them as they are already proven. Best practices both cater to and nurture copying mindset.

However, using experiments in LeSS is to emphasize that "there are no such things as best practices in product development. there are only practices that are adequate within a certain context". This is meant to encourage a culture of leaning, questioning, engagement and continuous improvement.

Are rules best practices, if experiments are not? Rules and frameworks were created to help novice group get started and form the foundation to support empirical process control for the whole product and organization. Would it encourage following and copying mindset, as these are stated as rules? Probably. To mitigate it, in the CLP (Certified LeSS Practitioner) course, we explore the rules via systems modeling to understand various factors and dynamics behind them.

How about patterns - are experiments patterns? A pattern is a general, reusable solution to a commonly occurring problem within a given context. In a way, patterns are formalized best practices, and they differ in patterns emphasizing the context. With patterns we focus on solving problems within a given context. This helps shift the focus away from the copying. While focusing on problem solving in a context, we are more likely trying to understand how the solution is supposed to solve the problem, and how the context matters. In this sense, experiments and patterns are close, as they both present logic and depend on context. However, they differ in putting which one first - the solution or the reasoning?

Focus on reasoning in experiments

In my view, reasoning is at the heart of experiments. When we learn about experiments, we don't focus on copying the solution, we don't even focus on learning the solution itself, we focus on learning the reasoning about the solution - how this solution is created, what factors and dynamics are involved, etc., so as to reason about our own problem and context then create our own solution.

reasoning.jpg

This view made me think that the current format of experiments - try/avoid - does not promote enough the focus on reasoning. Let me use two different formats for one experiment to illustrate the difference.

  1. Try - one product backlog shared by multiple teams.
  2. Understand - the impact of number of product backlogs on adaptiveness

With the first format, the focus is immediately on the practice or the solution (share one product backlog) itself; while with the second format, the focus is on the problem/goal (adaptiveness) and the potential leverage (number of product backlogs), thus, the reasoning.

I have to admit that it is unappealing to focus on "understanding" for many people. Unfortunately many people often just want to copy something, thus, any attempt to reason about factors and dynamics with them is seen too slow. However, this is exactly what we need in the complex domain such as large-scale product development.

The experiments are evolving, and never-ending because of continuous improvement. The first two LeSS books documented only those experiments collected till that time. Although we can wait for a revision of those two books, considering the nature of experiments, we would benefit from having a more dynamic collection of experiments made by and for the community of LeSS practitioners.

In summary, here is the shift of focus from best practices to pattens further to experiments:

  • with best practices we focus more on copying the solution than understanding the logic
  • with patterns we focus on learning the solution as well as understanding the logic - its problem and context
  • with experiments we focus on learning the logic - factors and dynamics, then creating solution on our own

 

Shared vision on organization

Shared vision is one of the five disciplines practiced in learning organization. This is the second article on how this discipline relates to product development organization, and it is about organizational vision. You may want to read the first one about product vision as well.

Let's look at organizational vision again in one-team Scrum context and multi-team LeSS context respectively.

One-team Scrum

In this context, organizational vision is actually team vision.

Scrum is based on empirical process control, while empirical process is guided by goals. There are three instances of empirical processes in Scrum.

  1. Daily Scrum is the empirical process applied towards sprint goal
  2. Sprint review is the empirical process applied towards product goal
  3. Sprint retrospective is the empirical process applied towards process goal

While sprint goal and product goal are straightforward, what is process goal? The embedded "process goal" in Scrum is to get potentially shippable at the end of every sprint. This lies at the heart of Scrum. Initially team may not be able to achieve this, and they use sprint retrospective to reflect and improve towards it.

Thumbnail image for shared vision - 4.jpg

Another common source of process goals comes from some assessment frameworks, either created by other people or on our own. The assessment framework is usually associated with questionnaires or checklists. The above diagram is a checklist I created many years ago for my own usage to assess team and organization. Its scope is bigger than one team, but the idea is the same. This kind of framework or checklist implies that team aims to achieve the ideal state indicated by getting full score in all dimensions and questions. If all questions are written as statement and the scores are marked based on the extent that team or organization has realized, the overall statement is essentially a team vision. Team vision describes more than processes, while getting potentially shippable at the end of every sprint is one of those processes.

Similar to product vision, here we set time-bounded team goals based on team vision, and work towards them mainly through sprint retrospective.

Who owns team vision? Though it is clearly defined in Scrum that PO owns product vision, it is less clear about who owns team vision. ScrumMaster certainly plays an important role as change agent, because team vision is closely connected to change vision. On the other hand, as team is self-managing, how much should they own team vision themselves?

Thumbnail image for shared vision - 2.jpg

This relates again to the above diagram from the book "The Fifth Discipline Fieldbook", which shows the degree of shared-ness. Similar to PO sharing product vision, SM could tell/sell/test/consult/co-create team vision with the team. These various ways of engaging team will also achieve different degrees of shared-ness. Let's elaborate on this.

Suppose that we would like to create a team vision that describes what an ideal team would look like. It could happen in the following ways.

  • [Telling] SM creates a full version and simply tells the team that this is what great Scrum team would look like. SM may borrow it from others, create it based on her own experience and aspiration, or mix multiple sources.
  • [Selling] SM creates a full version and explains why to the team in trying to convince them that this is a great team vision.
  • [Testing] SM creates a full version, explains why, and asks feedback from the team about what excites them and what does not. Then, she refines the vision.
  • [Consulting] SM creates a draft version, and asks the team to contribute. However, SM still reserves the role of judge, and she chooses to accept or ignore what the team says.
  • [Co-creating] SM does not create any version at all, and asks the team to co-create. SM may prepare some inputs for the team to reference, if they want. In this case, team fully owns the decision making, and SM only acts as the facilitator.?

The co-creation is often done through a series of team visioning workshops, which leads to shared team vision. Please note that it is not a one-time effort, but an ongoing process. Every quarter or half-a-year, perhaps during normal sprint retrospectives, team shall revisit and evolve its shared vision.

Multi-team LeSS

In this context, organizational vision spans across multiple teams.

In LeSS, there is an additional event called overall retrospective, which is the empirical process applied towards organizational goal. Organizational goals support to achieve organizational vision.

What is organizational vision? There is a LeSS guide called "Organizational Perfection Vision". Even though "a perfection vision is different from a vision. The goal of a vision is to achieve it, whereas the goal of a perfection vision is to channel improvements", the general idea of organizational vision still holds true. The vision describes a future state of organization, e.g. "able to deliver or change direction at any time without additional cost", "special coordination roles are avoided and teams are responsible for coordination", etc.

In the book "The Fifth Discipline", it defines learning organizations as "organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together". In fact, this describes a future state of organization, thus, learning organization itself is an organizational vision too.

In the book "Reinventing Organizations", it describes the advance of organizational models, and the emergence of teal organizations. Teal organization operates as a living organism or living system, with three major breakthroughs: self-management, wholeness, and evolutionary purpose. Teal organization is another organizational vision that we may aspire to.

Thumbnail image for shared vision - 3.jpg

In the above diagram from the LeSS guide "The LeSS Organization", we learn that PO provides product vision. Then, who provides organizational vision? Managers and SMs focus on organizational capability improvement, while organizational and team vision guides the improvement. Therefore, manager plays a similar role in organizational vision as SM in team vision. Managers together with SMs may provide organizational vision, by telling all the way to co-creating. Co-creation would lead to the highest degree of shared-ness. Nevertheless, the quality of organizational vision is also dependent on the quality of individual's personal vision. This is why shared vision better starts with personal vision, which is the focus of another discipline "personal mastery".

How do we co-create organizational vision? It could be similar to team visioning process, but with larger group. In those sessions, divergent and convergent steps are planned to facilitate large group. Alternatively, team visioning - what do we want to create as a team - may happen first, then, we organize the sharing sessions for teams to listen to one another, and let the shared vision emerge over time. You may find more from "shared vision" section in the book "The Fifth Discipline Fieldbook".

In product development organization, shared vision is applied to both product and organization. We have explored them in the previous article and this one respectively, and hope that it will help you practice the discipline of "shared vision" in product development organization.