"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.

Independent teams?

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!