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.
Conclusion
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!
