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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- 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.
- 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.
- 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.
- 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.?
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
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
- 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.
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.
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.
- critical customer bugs
- product A release 2.0
- other customer bugs
- product B feature 12
- critical/major internal bugs
- customer project A1 (based on product A)
- product A release 2.5
- product B other features
- product A prototype based on new hardware architecture
- 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.
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.
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.
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
- 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
- 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.
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.
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.
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
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.
- 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.
- 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
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.
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.
- Try - one product backlog shared by multiple teams.
- 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.
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.
- Daily Scrum is the empirical process applied towards sprint goal
- Sprint review is the empirical process applied towards product goal
- 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.
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?
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.
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.
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.
Shared vision on product
Shared vision is one of the five disciplines practiced in learning organization. I shall write two articles on how this discipline relates to product development organization. This one is on product vision, and the next one will be on organizational vision.
Let's look at how shared vision relates to product in both one-team Scrum context and multi-team LeSS context, especially considering that both Scrum and LeSS have the role of PO, who sets product vision and priority.
In this context, there is one team and one product.
Regarding product, there are why, what and how. PO and team are responsible for them altogether, with the below division.
It is clear that the how responsibility is completely owned by team, and the why responsibility is mostly owned by PO. However, the what responsibility is shared by PO and team. The specific division is decided by themselves and context dependent. Usually when team matures, team takes over more of them. It includes two parts. One is requirement clarification. The teams that need to be fed by PO with all requirement details at best work for product delivery. The other is solution creation. The great teams take the problem from PO and create solution for it, and they truly work for product creation.
Shared vision relates to the why. Why this product defines product vision, and why this feature defines feature value. Prioritization is based on both the vision of the whole product and the value of the specific feature. How can PO make the product vision a shared vision? How can PO make the prioritization a shared decision?
The above diagram comes from the book "The Fifth Discipline Fieldbook" and shows the degree of shared-ness. PO can simply tell the product vision and the priority, but as team has almost no active involvement, there is the lowest degree of shared-ness. On the other hand, if the product vision is co-created and the priority is co-defined, there is the highest degree of shared-ness.?
How can we make co-creation work? Through collaboration and participatory decision making. A coach or facilitator like ScrumMaster would be of great help. Many product envisioning techniques such as design thinking are built upon the divergent and convergent pattern, while the book "Facilitator's Guide to Participatory Decision-Making" is one of the classics to facilitate this process.
When PO and team co-create the vision and co-define the priority, there is really no separate role, it is just one team. In the book "Leading Teams", this is the self-governing team setting overall direction on its own, which is simply a natural progression from self-managing team. Do we have this kind of team in reality? Yes, great startup teams often work this way.
In this context, there are multiple teams, but one product.
?In LeSS, product creation is already defined as teams' responsibility. As one PO works with many teams, it is practically impossible to leave teams in the delivery mode. Teams not only work on requirement clarification but also product creation. What remains for PO is still vision and prioritization. See the below diagram from the LeSS guide "The LeSS Organization" for details.
While PO "provides" vision and direction, similar to the one-team context, he could create various degrees of shared-ness by doing it differently - from telling all the way to co-creating. The additional challenge with co-creating is the size of the group. One team is within 10 people, while multiple teams may be dozens, hundreds and thousands of people. Is it feasible to co-create with everybody? Large-group facilitation techniques are helpful. Nevertheless, it does take more time and effort. Is it desirable to co-create with everybody? The active involvement from co-creating would help set free the collective aspiration. However, in order to create a better product vision, it also requires that those people involved have the necessary capabilities such as understanding of users and markets, critical thinking, and etc.
An alternative to co-create with everybody is through product community, where team representatives would participate. In a way, PO team in LeSS Huge could be viewed as the beginning of product community. We may gradually expand PO team and turn it into a product community.
In this case, we don't really have any PO either - neither overall PO nor APOs. Teams and communities co-create product vision, with the support from coaches and facilitators. Do we have this kind of organization in reality? Yes, check out those teal organizations described in the book "Reinventing Organizations".
In the next article, we shall look at how shared vision relates to organization.
There is a rule in the LeSS Huge framework - "LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach".
In the 3rd LeSS book, there are three related guides for LeSS Huge adoption.
- "evolutionary incremental adoption"
- "one requirement area at a time"
- "parallel organizations"
The "evolutionary incremental adoption" guide is an overarching one, which describes two approaches.
- gradual incremental adoption over the whole product group
- focused deeper adoption at a part of the product group
The "parallel organizations" guide provides a major technique to support the 2nd approach, while the "one requirement area at a time" guide is an instance of "parallel organizations".
What is a parallel organization?
"This means you keep your existing organization as it is and gradually build the new organization next to it, starting with a few feature teams or one requirement area."
"A parallel organization is not a pilot, and one consequence is that the line of organizational reporting must be separate from the traditional organization."
This guide was developed from the below experiment.
Try...Transition from component to feature teams gradually (in the 2nd LeSS book)
"Note!--Team Red is not a temporary project group formed only for the purpose of feature-M. We are not suggesting the traditional practice of resource management with resource pools for short-term work groups. Rather, Team Red is a new stable team that will stay together for years; feature-M is but the first of many features they will eventually do."
Therefore, parallel organizations here mean two different structures in reporting line.
There are a couple of risks or weaknesses associated with the approach of parallel organizations.
1. without common vision
Parallel organization is a change strategy, rather than a pilot to test whether this is the direction we would like to go. Thus, parallel organizations happen after you have established a common vision - eventually the whole organization will move into the new mode.
"Communicate very clearly that eventually everyone will be in the new organization. That's an important message so that people in the old organization do not focus on rivalry."
However, shared vision is not a one-time process, but a continuous process. The extent of the commitment to the new vision would vary among the people in the current organization. This is also why using volunteering is a powerful adoption principle. We provide a chance for people who are more ready to volunteer into the new organization now, while for people who are less ready to temporarily stay in the old organization. However, it is not an option to forever stay in the old organization. The really available option is getting some extra time to learn and digest the new mode so as to get more ready (or eventually decide to leave the organization). This fits the nature of various paces that different people have, thus, shows the respect for people.
2. additional complexity
Parallel organizations do introduce additional complexity. The complexity of making two modes co-exist may be more than the complexity of making the new mode work.
At the code level, the individual code ownership simply prevents the adoption of feature teams, while the adoption of feature teams simply breaks the individual code ownership. Continuous integration is not continuous integration any more when only part of the organization is practicing it. "Don't let the parallel organization branch the codebase as that will lead to merge-hell. They are separate organizations but work on the same product and the same codebase."
As there are two different organizations, each involves its own organizational design. In light of Star mode, they may have different strategies, structures, processes, rewards and people practices. These add complexity on the management too.
LeSS or LeSS Huge seem binary, while in fact it is a continuum. We may split LeSS Huge into small LeSS Huge and big LeSS Huge to explore the alternatives. Let's get back to the root of LeSS - experiments, as we shall experiment to explore.
1. Small LeSS Huge
Small LeSS Huge is perhaps between 50 and 200 people.
Try...Feature teams - transition (in the 1st LeSS book)
Reorganize into broad cross-component feature teams
This is an "all-at-once" approach. In the LeSS framework, it becomes a rule. While in the LeSS Huge framework, it is recommended to take an evolutionary incremental approach. However, it doesn't mean that you could not experiment it in the context of LeSS Huge, especially when it is a small LeSS Huge case. It avoids parallel organizations, thus, reduces the associated complexity. Meanwhile, it increases the risk of either superficial adoption (the law of raspberry jam - the wider it is spread, the thinner it gets) or overwhelming problems from everywhere.
Try...Feature teams from single-specialized to multi-specialized
Try...Feature teams from being led by Team Leader (TL) to self-organization without TL
I worked with an organization of ~150 people to adopt LeSS. When presenting them with parallel organizations, they disliked it. They concerned that it would be confusing to maintain two different reporting structures. They used to be structured in functional and component teams. They wanted to form cross-functional feature teams, and change the reporting structure all at once.
However, considering that the challenges could be overwhelming, we thought about limiting the change scope elsewhere. We still had product backlog per feature team, still had Team Leaders (no ScrumMasters) in some teams, and etc. Over time, we reduce the number of product backlogs and nurture the self-organization. Along the way, we don't have parallel organizations in the sense that there are two different reporting structures. Nevertheless, this is still an evolutionary incremental approach.
2. Big LeSS Huge
Big LeSS Huge is perhaps above 200 people.
Try...Feature teams - transition (in the 1st LeSS book)
Gradually expand teams' responsibility
This experiment could mean to merge small-component teams into big-component teams. Suppose that we have four component teams - A, B, C and D, instead of creating full feature teams by mixing all components, we take smaller step to first create bigger-component teams - A/B and C/D, each having two teams sharing one bigger-component backlog.
This experiment could also mean to expand the Definition of Done (DoD) over time. The expansion of DoD and product definition often goes hand in hand. This experiment was actually developed into the guide of feature team adoption map.
Try...Reduce #component backlogs and #functional backlogs over time
The essence of adopting cross-functional feature team could be boiled down to the reduction of #functional backlogs and #component backlogs. Please refer to "number of backlogs and multi-learning" for more details.
While we merge small-component teams into big-component teams, we reduce the number of component backlogs. Besides that, we merge fine-grained functional teams into course-grained functional teams. For example, UX, UI and BA teams could be merged into a product design team; various specialized testing teams could be merged into a generic testing team. While doing this, we reduce the number of functional backlogs.
Try...Feature areas having teams with various extents of functional, component and customer domain specialization
To avoid parallel organizations, try to establish feature areas all at once at the highest organizational level. Feature areas consist of multiple teams, and can complete customer features from end to end. However, team structures within the areas vary. In some areas, those are still functional and component teams. In other areas, those are feature teams, but single-specialized, thus having their own product backlogs. In still other areas, those are multi-specialized feature teams sharing one product backlog. In that case, those areas are already requirement areas, though static. The adaptiveness would increase further by making those requirement areas dynamic.
We continue to experiment towards perfection.