Limits to one Product Backlog - 2

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

One Area

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

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

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

Feature Owner

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

There are two aspects defined and emerged in this role.

• Product leadership

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

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

• Technical leadership

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

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

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

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

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

How on earth should we understand this role?

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

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

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

Sub-Area Product Owner

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

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

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

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

Summary

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