It seems that product development organizations care about productivity the most. This is reflected by the common misunderstanding about adopting agile development for higher productivity while agile development is about flexibility and adaptiveness. In this article, we will take a look at why focusing on productivity is often not a good idea, and surprisingly, focusing on others, such as value, quality, speed and flexibility, eventually leads to higher productivity.
There are a few challenges for productivity focus. Firstly, what is the measure of productivity? For knowledge work, it is not as simple as counting the number of items produced in the factory. We have tried the lines of code, the number of features, and so on, produced per time unit. These are useful to some extent, but focusing on them often leads to local and short-term optimization. In order to deliver more features or lines of code, we select only those familiar features or tasks, and we take shortcuts. We may get higher productivity in the local view and short term, while we suffer in the whole and long term.
What are other focuses in product development organizations? Let's look at value, quality, speed and flexibility, as well as how they relate to productivity.
Value vs. Productivity
This is about outcome vs. output. Outcome is the value, while output is the feature. Usually, we define productivity in terms of output. There is a sense of futility when talking about that we should focus more on outcome. Everybody on the development side agrees easily that this is a major problem, but unfortunately they can't do anything about it.
The silo between product/business and development seems the thickest and deepest, however, this is also where change can have the most leverage. We simply develop too much low-value stuff, partly because it is inherently difficult to identify value, partly because that we are not disciplined enough while exploring and validating value. By the way, agile product development is supposed to increase our discipline via short feedback loop. If we can stop developing half of the low-value stuff, we will have more time to develop those high-value ones with higher quality.
Quality vs. Productivity
It is common that development organizations sacrifice quality in order to meet schedule. The productivity seems improving in the short term, however, productivity deteriorates further in the longer term, exactly because of bad quality. How do we respond by then? We sacrifice quality even more. This is perhaps the most ubiquitous vicious cycle in our industry.
We seem always lacking time to produce quality, but always having time to fix quality. While the defects shipped to users impact quality, the defects found then fixed internally impact productivity. Actually, as there is no easy way to directly measure productivity, I usually suggest to take the number of internal defects as one of the proxies for productivity, because it indicates rework. So, instead of sacrificing quality for productivity, we ensure quality for productivity. In my old days as the quality manager, there was tremendous pressure on meeting schedule in our organization, and my favorite comment was "when we focus on schedule, we don't meet schedule (as our quality suffers, then schedule slips further); while when we focus on quality, we meet schedule too".
Speed vs. Productivity
People often mix up these two concepts - speed and productivity. When they say that they want to go faster, they really mean that they want to produce more. The former is the speed in terms of cycle time, and the latter is the productivity in terms of throughput.
The end-to-end cycle time is critical for product development, not only because it decides when the value is delivered to end customers, but also because it decides when we get feedback for adaptation. How can we reduce cycle time, even with the same throughput? By focusing on the high value work and limiting WIP.
In the book "this is lean", it introduces the above efficiency matrix, which distinguishes flow efficiency and resource efficiency. Behind it is customer focus (speed) vs. resource focus (productivity). Interestingly, the strategy advocated in the book is first focusing on flow efficiency. As improving flow efficiency can reduce a lot of superfluous work and waste, it improves resource efficiency too.
Flexibility vs. Productivity
In my experience, flexibility is not something most organizations focus on, even though It is the means to maximize value in uncertain environment, thus the essence of agile development.
Over-specialization in various dimensions is probably the biggest obstacle for flexibility. It is perceived more productive to keep working in specialized areas, however, it is a local optimization, leading to delivering many features with low value - rarely or never used; or even worse, high amount of WIP - partly done features never delivered to users. How do we break down the over-specialization? Via multi-learning. I have described this topic in the series "Number of backlogs and multi-learning". Although multi-learning is aimed for flexibility, the broad knowledge coming out of it also enables more effective collaboration and integration, which helps productivity as well.
The focus on learning s worth further pondering. Don't we need to learn and improve in order to get more productive? Indeed, if our focus on productivity means the focus on learning, then, it is a good idea. We train and coach developers to write clean code and tests, and help them adopt modern engineering practices. However, this is not what most people usually mean when talking about productivity. Upon a bit reflection, it is common that focusing on productivity means to deliver more by adding more pressure and working longer hours, rather than learning and removing impediments.
In summary, if the productivity focus means to help developers learn and improve, go for it! Otherwise, we'd better focus on:
- value: because only doing high-value work, we have the time needed to do our job properly
- quality: because producing fewer defects, we have less rework
- speed: because flowing better, we have less waste
- flexibility: because expanding knowledge scope, we have more effective collaboration and integration
then, productivity takes care of itself.
Practice Systems Thinking: 2) from Fishbone Diagram to Causal-Loop Diagram
The previous article talked about how to introduce systems thinking in product learning, and this one is about introducing systems thinking in process learning.
In contrast to product learning, practicing systems thinking in retrospectives has been more widely advocated. However, it is rarely sustained in my experience - when introducing system modeling with CLD (Causal-Loop Diagram), it might provoke much enthusiasm in the beginning, but it was seldom picked up regularly, often died out completely after a while. I reflected upon this and supposed that practicing systems thinking was too big a challenge for many organizations, as far as their current reality was concerned. Over time, I realize that RCA (Root Cause Analysis) in the context of PDCA (Plan-Do-Check-Act) could be a stepping stone to systems thinking.
Fishbone Diagram vs. Causal-Loop Diagram
Fishbone Diagram is a common tool for RCA, while CLD is a basic tool in systems thinking.
How does RCA fit into PDCA? In the above A3 report, the left part is the Plan, consisting of the following elements.
- Theme: summarizes the problem or the improvement topic
- Background: why does the problem matter?
- Current condition: describes the current condition for the problem
- Goal: describes the goal condition for the problem
- RCA: analyzes the potential causes
Let's elaborate on the fishbone diagram commonly used in RCA.
- Problem statement is the effect, illustrated as the fish head
- There are categories for potential causes, illustrated as those main branches from the spine.
- Potential causes are written underneath the main and further branches, illustrated as layers of fishbones
How does fishbone diagram relate to CLD? The fishbone diagram is also called Ishikawa cause-and-effect diagram, layers of branches indicating causal relationships. Therefore, it has the same causal foundation as in CLD.
Let's look at the other elements in the Plan. Background describes the effect of the problem, why does the problem matter? What are the consequences of the problem? Current condition and Goal define the problem with more clarify and rigor. The problem can be stated as the gap between current condition and goal. Combining all these elements, it becomes akin to CLD.
What are further benefits through the practice of systems thinking with CLD? This reminds me of a LeSS post-course test question. "System modeling (aka CLD) is a tool used to analyze and find the root cause of a pre-defined problem" - this statement is NOT true. The explanation is "...In Systems Thinking we avoid falling in the trap of simple cause-effect thinking and understand there are always many perspective to a systems and many direct and indirect causes of problems." Indeed, by modeling all causes and effects in RCA as variables, and looking for how they interact with each other, it promotes to think of multiple causes, rather than one root cause; as well as think of leverages, rather than absolute causes.
Convert and Expand
Let's use an example to describe how to transition from RCA to systems thinking.
Here is the brief Plan:
- Theme: adopt UT (Unit Test) practice
- Background: Why UT? better product quality with fewer defects; higher developer productivity due to less rework
- Current condition: few people practicing UT in our development organization
- Goal: all people practicing UT in our development organization
- RCA: see the following fishbone diagram
- The categories are derived from the influencer model. There are two dimensions - motivation/ability and personal/social/structural, thus, we get six categories as main branches.
- In real practice, the causes under "own bad experience" should be asked further, e.g. why not useful. Skip here for brevity.
- "..." under "others' bad experience" is the same as those under "own bad experience".
The process of converting and expanding fishbone diagram (together with other elements in Plan) to CLD is as following.
1. Derive variables from theme, current condition and goal to describe the problem. In this case, I define the variable "#developers practicing UT" for the problem.
2. Model for consequences. We derive the variables and corresponding links from background. There are two main drives for adopting UT practice - product quality and developer productivity. How does practicing UT lead to them? CLD illustrates more granular causal relationships, as shown in the below diagram.
- UT reduces defects from regression, which increases product quality as well as productivity (due to less rework).
- UT's effect on refactoring thus internal code quality is more subtle, while code quality acts as a key leverage for both productivity and product quality.
3. Model for causes. This is an iterative process. I usually take a group of related causes to convert and expand, exploring their relationships with consequences and with each other. For this example, I shall model the causes in three aspects - motivation, time and ability.
3.1 Motivation - do we have the motivation to practice UT?
- R1-loop is to increase motivation via better perceiving the value. There are actually a few similar loops here, through either higher product quality or higher productivity, while they all increase the "perception for the value of UT" thus the "motivation to practice UT".
- R2-loop is to increase motivation via peer pressure; while R3-loop is to increase motivation via organizational recognition.
3.2 Time - do we have the time to practice UT?
- B1-loop constrains the available time to write UT; while B2-loop constrains the available time to maintain UT.
- R4-loop is to reduce time pressure by having fewer defects. We invest time to do UT, but we save time by having fewer defects, can we have net saving on time?
3.3 Ability - do we have the ability to practice UT?
- "Developer skill on UT" is a key variable to understand the dynamic around ability.
- R5-loop shows often a vicious cycle - no time to learn. In fact, there are two similar ones in the diagram, causing no time to write and maintain UT, respectively.
- Thus, "effectiveness of learning UT" becomes an important leverage. Common tool/process, training/coaching are ways to improve the learning effectiveness.
- R6-loop can become a virtuous cycle to increase the learning effectiveness via peer help. In fact, R2-loop and R6-loop provide social motivation and social ability, respectively.
Do you see the advance in thinking with the expanded CLD? That's the motivation behind moving from RCA to systems thinking.
When do we do all these? We practice systems thinking as part of PDCA - we model during Plan, find leverages to Do, then update the model during Check, and design next leverages to Act. As this is on process learning, the natural fit is Sprint retrospective in Scrum as well as both team and overall retrospectives in LeSS.
If practicing systems thinking in process immediately seems too big a challenge for you, RCA could be a stepping stone. Beginning from RCA, perhaps one day we will be practicing systems thinking without notice.
Practice Systems Thinking: 1) from Impact Map to Causal-Loop Diagram
A few years ago, I wrote about "how does LeSS optimize organizational ability to learn?". I saw the potential of practicing systems thinking to enhance both product and process learning, but lacked the concrete steps to make it happen. Now, I gather more thoughts and experience, thus mean to write two follow-up articles - this one is on product learning, and the other will be on process learning.
I always feel hesitant to introduce systems thinking in product domain, because even though it can help in theory, it seems not enough empirical evidence to support its adoption. In contrast, impact mapping is a more recognized technique, and they are both based on logical thinking underneath, so I wonder if we could use it as a stepping stone to systems thinking. While practicing impact mapping, I suggest to do it in a freer manner and focus on establishing the influence path between features and goal - how every feature is expected to cause and has actually caused achieving the goal. In my recent experience, the client one day discovered that it was akin to CLD (Causal-Loop Diagram) - aren't we actually practicing systems thinking? Yes, this approach - from impact map to CLD - could indeed work!
Impact Map vs. Causal-Loop Diagram
Impact map is the outcome from impact mapping. It is a structured mind map, having a goal in the center, with features connected to the goal. CLD is a basic tool in systems thinking. It consists of variables, links and loops to illustrate system dynamics.
They both show causal relations, and both encourage to broaden the space - who else and how else to influence the goal in impact mapping, what other variables influence the dynamic in systems thinking.
However, there are some further benefits through the practice of systems thinking with CLD.
- By loosening the structure in impact map, we are freed to create as many causal links as needed, usually leading to more granularity, thus more clarity and rigor.
- With more variables explicitly being added into the picture, it provides an opportunity to broaden the space further, as we can ask for each variable - what else causes (drives or limits) its change; what else its change leads to.
- With systems thinking, it explicitly asks to extend the time as well - how each variable changes in both the short term and the long term.
- Loops may emerge, and provide further insights for leverage, e.g. exploit reinforcing loops for growth, remove the limits from balancing loops.
Next, I will use an example to describe the process of moving from impact map to CLD, and demonstrate the advance in thinking out of it.
Convert then Expand
This is an example of impact map.
Let's see how each structural element in impact map relates to CLD.
- Goal could be represented as a variable that we would like to optimize, i.e. a variable as system optimizing goal.
- Actor provides perspectives to broaden the space. While modeling with CLD, they are not variables, but can help us think of more variables and see more dynamics.
- Impact is the most critical piece to connect deliverables and goal. We can extract it to create a causal link between each deliverable and goal, with as many intermediate variables as needed.
- Deliverable may or may not be directly represented as a variable in CLD. They can be actions to change variables.
Without much difficulty, we can convert the example impact map into the below CLD.
Here are a few notes:
- "revenue from ads" is a variable directly from the goal.
- I add quite a few intermediate variables, such as "#impressions", "CTR" (Click-Through Rate), "frequency of visits", "length of visits", etc., for more clarity and rigor.
- Among the 5 deliverables, I add corresponding variables for 3 of them (push updates, special offers and better pagination), but the other 2 (forums, chats) are just actions to change the variable "ways to engage". This is to better illustrate the possible relations between deliverable and variable.
Then, we work this initial CLD further by expanding time and space, and discovering interactions and loops, i.e. practicing systems thinking. The below is one expanded version.
Here are a few notes:
- About push updates, there is a limit for the "#push updates", as high number of updates will increase "user annoyance". I add a variable "relevance of updates", then discovered R1-loop that drives the "frequency of visits" through better "understanding of users", thus more relevant updates.
- About special offers, though it drives more visits, thus, more revenue and profit, more budget to fund even more special offers (shown in R3-loop), it increases cost as well, thus puts a limit (shown as B1-loop). I add a variable "relevance of offers", which brings about a similar dynamic (shown in R2-loop) as "relevance of updates".
- Forums and chats provide ways to engage users, so that they can stay longer during their visits. I add a variable "content quality". There are two related reinforcing loops. R4-loop is to drive the "length of visits" with higher-quality content by the company through better understanding about users. R5-loop is to drive the "length of visits" also with higher-quality content but by active users themselves.
Do you see the advance in thinking with the expanded CLD? That's the motivation behind moving from impact mapping to systems thinking.
When do we do all these? Same as impact map, there are as-is and to-be views for CLD too. It is an iterative process to keep exploring, learning and updating. As this is on product learning, it mainly happens during PBR and Sprint Review.
If practicing systems thinking in product sounds too far, impact mapping could be a stepping stone. Beginning from impact mapping, perhaps one day we will be practicing systems thinking without notice.
"Maximize dependencies between teams"
This is an interesting quote by Bas Vodde - "we should maximize dependencies between teams". As it seems contradicting with our conventional thinking, we shall elaborate on it in this article.
Isn't feature team supposed to deliver features independently?
Yes, it is. As illustrated in the above diagram, each feature team develops various items from end to end - team Red for item 3/4/5, team Green for item 1/7/9, and team Blue for item 2/6/8/10. They don't depend upon other teams to deliver those items. In other words, they have separate sprint backlogs.
However, feature teams also seek opportunities to collaborate with one another, as all of them develop the same product and they are not silos. How does it work in practice? Let's look at the below three aspects.
1. Shared backlog
Feature teams share one product backlog. To boost broad learning and increase adaptiveness, we encourage teams to do multi-team PBR (Product Backlog Refinement). Instead of having each team refine specific items, we have multiple teams together refine a group of items, or even all items. In the multi-team PBR, we create the mixed groups consisting of people from different teams, then, make diverge-merge cycles to refine those items. In the sprint planning part 1, feature teams self-organize to agree on which items each team will take, in order to maximize the value delivered in the coming sprint, as well as the learning for sustaining the future value delivery.
2. Shared components
Feature teams share product components. When each feature team develops its selected items independently without collaborating with other teams, chances are they create duplicated work, or the component structure deteriorates. Isn't it supposed to work that way, as we transition from component team to feature team? Not at all. Shared component and component team are two different concepts. LeSS advocates not only feature teams, but also shared components. Feature teams self-organize to create shared components. In the sprint planning part 2, they may discover that they all need to make changes on certain component, thus decide to have a joint design session. They may later form cross-team pairs to implement some changes together. During the sprint, feature teams continuously integrate their work to expose any conflict and collaborate to resolve them earlier.
3. Shared increments
Feature teams share product increments. Sprint review bazaar is a LeSS guide about how to run an effective sprint review. During the sprint review, those stations are usually organized around teams. I find it better to organize them around meaningful increments. Perhaps a set of items form a customer journey, or all contribute to a desired impact. If they are developed by multiple teams, great! Then, relevant teams need to collaborate together, which fosters the whole product view and promotes cross-team learning.
Whole product focus
Putting all these together - although feature teams have their separate sprint backlogs, they share product backlog, product components and product increments. For the good of whole product, the teams need to span their boundaries. This is in line with the case that individuals need to span their boundaries when they form a team. Even though individuals may have different skill levels in various areas, they cross learn and help each other to focus on the whole team. LeSS expands the whole team (one team) focus to the whole product (multiple teams) focus.
In essence, "maximize dependencies between teams" is to encourage collaboration and learning across team boundaries for the whole product focus!
"Component Product Manager"
During the past half year, I have seen the similar situation at least three times in various organizations. This probably means that it is worth an elaboration.
"Component Product Manager"
We know of component team, but what on earth is "component PM (Product Manager)"? Doesn't it sound absurd? I did not really hear the exact term being used, while it came out from the people whom we together ponder over the situation - "we have not only component team, but also component PM"!
We were discussing about how to transition from separate backlogs to one shared backlog. As shown in the below diagram, they currently have respective PMs and development teams responsible for certain areas (A/B/C) within the product. In order to move towards one backlog, besides the teams, the PMs also need to change.
This term contains two parts - Component and Product Manager, and let's understand them separately.
- The component responsible by PM is to some extent customer oriented, as a customer or business area inside the whole product.
- It may depend on other areas to together create value, but it is occasionally valuable on its own, as illustrated in the shared backlog on the right side of the above diagram.
- Product Manager
- Its alternative name is Product Owner, but they are actually more like BAs (Business Analysts). In some organizations, they are also called so.
- They specialize in certain area. As they are coupled with teams, the corresponding teams specialize in the same area.
In short, "Component PMs" are the BAs specialized in dependent areas.
When we have all teams share one backlog, the generic teams (1/2/3) who work on whatever features with highest value simply can't continue to couple with the specialized BAs. Therefore, these BAs need to decouple with the teams and somehow connect to the one backlog, as shown in the below diagram.
It is common that the same technical stack is used across those areas, thus, the teams usually feel comfortable in expanding their scope to develop features from end to end. So, this time, the limit is more on the specialized BAs. They see it a big challenge to learn and analyze broadly across the whole product, for whatever features with highest value in the one backlog. You may argue that developers can learn broadly, why can't BAs do the same? It is of little avail if you encounter a view that developers only need to code for specification, while it is much more difficult for BAs to learn broadly, thus they have to specialize in some area. So, the better strategy is to focus on the system optimizing goal, which is to discover and deliver the most value as the whole organization.
What further complicates the change is that specialized BAs are often located in the product department, rather than the development department. As BA is a part of feature team, the necessary organizational redesign (aka organizational flip) for feature teams is bound to span both product and development departments.
According to the LeSS framework, it is actually one-step change to create both one product backlog and feature teams.
- (one product backlog) All teams follow one priority, not constraint by current skills. When work and skill do not match, it triggers learning.
- (feature teams) Each team includes dedicated BA, and BA will cross-learn in the same way as other members do. All team members have the same reporting line.
It is possible to have more gradual steps, i.e. gradually break down BA's specialization on areas and change the organizational structure as well.
- (one product backlog) BAs are still specialized in areas, then, they are de-coupled from teams. However, BAs follow the same priority from one backlog, and are not allowed to analyze features in lower priority just in order to keep busy. (hint: observe what they will do then)
- (one product backlog) BAs break down the specialization on areas, as shown in the below diagram. They learn broadly to be able to work according to one priority.
- (feature teams) BAs join feature teams, and any BA belongs to one team stably.
- (feature teams) BAs and developers align performance measures across product and development departments, so as to break down functional silo and really have common goal.
- (feature teams) Reporting structure is changed so that all feature team members have the same reporting line, as shown in the below diagram. This further promotes cross-learning within the teams.
Eventually, we evolve into the LeSS structure - multiple feature teams share one product backlog.
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.
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.
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).
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.
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)?
I have recently encountered two different configurations, and let's explore them one by one.
1. Teams are responsible for elements in the product
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?
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
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?
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.
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.
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.
Different rules in LeSS and LeSS Huge
"We have 5 teams. We are doing LeSS, and we have 3 APOs (Area Product Owners)." Wait, this is NOT LeSS!
Motivated by this kind of common misunderstanding, I am writing this article to describes the different rules in LeSS and LeSS Huge, and why they are different.
LeSS vs. LeSS Huge
First, what is LeSS? I have to admit that the word LeSS is an overloaded term. It means several things. Let me try to clarify.
I can't actually find a proper word to describe LeSS in general, including experiments, guides, rules and principles, as shown in the LeSS complete picture. I will just call it a system.
When we say that "LeSS is Scrum applied to many teams working together on one product", it probably refers to LeSS also as a framework, as Scrum is a framework. Then, LeSS framework is only part of LeSS system - the rules. What makes it more confusing is that when we say LeSS framework, it can again mean two different things.
- LeSS framework as a whole, including both smaller LeSS and larger LeSS Huge frameworks
- Only the smaller LeSS framework
These different meanings behind the word LeSS unnecessarily add the cognitive load for people learning about LeSS. I agree that we need to fix it, and will work on it further.
With the above clarification, we are in a better position to explain LeSS vs. LeSS Huge.
LeSS and LeSS Huge are smaller and larger frameworks respectively inside the LeSS system. The creation of LeSS frameworks was a response to novice practitioners in large-scale product development in need of something more specific than experiments to start their journey. This something became the rules in LeSS system and they form the two frameworks.
When we say that "this is or is NOT LeSS" or "we are or are NOT doing LeSS", we usually refer to the fact that we are or are NOT following the rules in the LeSS and LeSS Huge frameworks.
The larger LeSS Huge framework differs from the smaller LeSS framework in two significant ways. One is the introduction of RA (Requirement Area), and the other is using the evolutionary incremental approach in adoption. We will elaborate both.
1. Requirement Area
What are RAs? RAs are foremost area backlogs, which are subsets of the whole product backlog. Then, there is one APO and a few (usually 4-8) feature teams associated with a RA. You may learn more about RA from the following articles.
Why RAs in LeSS Huge? The introduction of RA is a response to those limits to one product backlog, especially the ones from PO. Please find more analysis from the following articles.
What is or is NOT LeSS?
On one hand,
- in the smaller large-scale context with 2-"8" teams, there is no RA, and all teams share one product backlog. This is LeSS!
- in the larger large-scale context with "8"+ teams, there are RAs - area backlogs, and a few teams share one area backlog. This is LeSS!
On the other hand,
- in the smaller large-scale context with 2-"8" teams, there are RAs - area backlogs, i.e. not all teams share one product backlog. This is NOT LeSS!
- in the larger large-scale context with "8"+ teams, there is no RA, i.e. all teams share one product backlog. This is NOT LeSS!
Objection! Isn't it great if all teams can share one product backlog even in the larger large-scale context with "8"+ teams? Yes, indeed. However, this is not following the rules in the LeSS Huge framework, thus NOT LeSS. Certainly, we can and should experiment on it!
2. Evolutionary incremental approach
What is evolutionary incremental approach in the larger LeSS Huge framework? This is in contrast to the all-at-once approach in the smaller LeSS framework.
LeSS rule: For the product group, establish the complete LeSS structure "at the start"; this is vital for a LeSS adoption.
LeSS Huge rule: LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach.
Why evolutionary incremental approach? LeSS adoption is not simply process change, but deep organizational change. Thus, the change could be overwhelming in the larger large-scale context. Therefore, an evolutionary incremental approach is prescribed for LeSS Huge adoption. Please find more analysis from the following articles.
What is or is NOT LeSS?
On one hand,
- in the smaller large-scale context with 2-"8" teams, we change the structure all at once. This is LeSS!
- in the larger large-scale context with "8"+ teams, we change the structure with an evolutionary incremental approach. This is LeSS!
On the other hand,
- in the smaller large-scale context with 2-"8" teams, we change the structure with an evolutionary incremental approach. This is NOT LeSS!
- in the larger large-scale context with "8"+ teams, we change the structure all at once. This is NOT LeSS!
Again, NOT LeSS simply means that we don't follow the rules in the LeSS and LeSS Huge frameworks. It is encouraged to experiment on different approaches than what is prescribed.
Should we care?
Should we care whether this is or is NOT LeSS? Yes and no.
Yes. We should learn about the rules and their differences, more importantly, the reasoning behind them. Breaking rules with proper understanding is experimental, while breaking rules without proper understanding is simply ignorant.
No. Rules are for novice practitioners, while experiments are at the heart of LeSS. We can turn those "NOT LeSS" cases into meaningful experiments.
- In the smaller large-scale context, these are NOT LeSS: 1) RA, and 2) Evolutionary incremental approach. We can run the below experiments:
- gradually increase the number of feature teams, thus change the structure with evolutionary incremental approach.
- gradually decrease the number of backlogs, thus, still have multiple product backlogs (essentially RAs - area backlogs), until it is reduced to one product backlog eventually.
- In the larger large-scale context, these are NOT LeSS: 1) No RA, and 2) all-at-once approach. We can run the below experiments:
- break the limits to one product backlog, and keep one (no RA) for 10-15 teams.
- change the structure all at once to avoid parallel organizations in a 150-person organization.
These are both NOT LeSS (about following rules) and LeSS (about running experiments). We understand rules by adopting frameworks, then, break rules by running experiments!
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.
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.
- Teams decide on their own to only select certain items, which they are more capable of developing. This creates implicit backlogs.
- 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.
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.
"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].
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.
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.
Till now, we have explored the limits to one PBL with the following topics.
- PO on team or PO on feature?
- Experience with FO and sub-APO
- Limit from PO on clarification
- Limit from PO on prioritization
- 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.
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.
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.
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.
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.
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.