With or without shared-component team

In many organizations, there is dedicated team responsible for shared components. Meanwhile, there are multiple business/product teams, and they all request work from the shared-component team. The below diagram shows a typical case.

The most pain associated with shared-component team is the waiting, leading to longer end-to-end cycle time. We can improve the situation through better prioritization of the work in shared components and/or further adoption of feature teams.

Prioritize work (with shared-component team)

The work in shared components usually does not have standalone customer value; it needs to be integrated together with the feature work in the businesses/products using these shared components. Therefore, while prioritizing the work in shared components, we naturally consider the priority of relevant features in the businesses/products.

In practice, the request from more important businesses/products usually gets the priority, thus they suffer less from having to wait. For them, even though there is cross-team dependency, the related work can still be done more or less synchronously. However, those less important businesses/products suffer more, and they sometimes feel no hope in getting the priority at all. Is it reasonable?

Suppose that there is one overall backlog including all businesses/products, at some time possibly there is no high-priority work at all from some businesses/products, thus it is reasonable that they do not get any priority in shared components accordingly. However, the reality is that each business/product has its own backlog and people. Even though some businesses/products are less important, they still proceed on their own. In this case, not getting any priority from shared components impedes them from getting their features done, thus creates WIP and waste. Then, is there any better way to prioritize the work in shared components?

When businesses/products have different importances but meanwhile have their own backlogs, how are the different importances reflected across businesses/products? It is actually in the pie chart showing the number of people in each business/product. We should take this information into account while prioritizing the work in shared components. We can fix the work amount for each business/product based on the distribution in pie chart, but this way we ignore the nature of shared components - they are used by multiple businesses/products. How else?

"Buy a feature" is an innovation game by Luke Hohmann, and it fits nicely here. We allocate virtual budgets for multiple businesses/products based on the distribution in pie chart; and we estimate the cost for candidate requests. Then, we decide what requests to take into the next sprint. There is an example in the "Incremental LeSS Adoption at SolarWinds" case study - see the section "Try ... Buy a feature game when you have many stakeholders." If we play the game, businesses/products would have representatives to collaboratively decide. Even not, we can still use this model in the prioritization for shared components. This model intends to align the priorities at the global scale, i.e. between businesses/products and shared components, and thus reduce the waiting caused by different priorities.

Adopt feature teams (without shared-component team)

While it helps reduce waiting time through better prioritization for shared components, the deep cause of waiting is the mismatch between skills and needs. As long as we assume that skills are static - people are fixed in specialized areas, while needs are dynamic - work amount in various specialized areas fluctuates, waiting is inevitable. The fundamental solution is to adopt more feature teams, whose members multi-learn various skills to match the ever-changing needs.

It is important to note that with feature teams, there are still shared components. New shared components emerge and existing ones evolve. Feature teams collaborate to make it happen. By the way, this is what Bas Vodde promotes about maximizing dependencies between teams; I wrote about this aspect also in a related article. Then, how can we move away from shared-component team and towards feature teams?

The first step is to simply distribute the people in shared components to various business/product teams. The number can again be based on the distribution in pie chart. Suppose that we already have partial (not including the work in shared components) feature teams in various businesses/products, we essentially expand the scope of those teams. Those shared-component people continue the collaboration regardless of the change in their team identity - they used to collaborate inside shared-component team, and they now collaborate across feature teams.

Then, as the real integration within feature teams proceeds, the boundary between business/product members and shared-component members gets blurred. Furthermore, the people working on shared components are not limited in those old shared-component people any more.

Eventually, we don't need to consider the pie chart at the level of shared components any more. Only feature teams adapt as part of their normal life - they may move to different businesses/products when priority changes.

Conclusion

In LeSS organizations, the majority of teams are feature teams, and feature teams share components without having dedicated shared-component team. However, as the majority does not mean all and feature team adoption is a gradual process, shared-component team may exist even in LeSS organizations.

With shared-component team, we can still improve its prioritization and gradually reduce its size. The pie chart provides a useful view about global priority; it can help both prioritization and feature team adoption.