Shared backlog with one priority

In the context of multiple teams working on one product, I try to figure out where priority is set.

I first ask, "do we have one priority at product level and shared by all teams, or do we have priority at team level?"

The answer is often, "we set priority at product level".

Then I ask further, "what names do your teams have?"

I often get names associated with domains, such as "production, shipping, and finance".

"So, what if we have most of high-priority items in production? what would shipping and finance teams do?"

"Well, they still do shipping and finance items."

"Even when those items are not in high priority?"

"..."

Do you see the inconsistency between one priority and team names associated with domain? Sometimes, I give sarcastic comment to make the point, "so, you do ask your customers to change requirement because our production team is pretty occupied but our other teams are available, don't you?":-)

Agility is about responding to customer change, rather than changing priority because of our own constraints.

The below diagram shows the shift, at least on the paper.

The name such as Wei/Shu/Wu from Three Kingdoms detaches from domains, while it can still associate with the product, i.e. product x/Wei, product x/Shu, product x/Wu.

In this case, as long as the item is high priority, any available team will work on it. Chances are, in one sprint, two teams are working on production items, and none of them is working on finance item, if that is the priority. The key is, the whole organization - 3 teams - can work on any item from any domain, according to priority. That's where agility lies at.

How do we achieve this? The easy part is to remove the label associated with product domain. The hard part is to develop the skills necessary to work across domains.

If you happen to reorganize your teams (e.g. create long-lived teams during your LeSS adoption), you incorporate this while designing new teams. During the recent self-designing workshop, we simply put an additional constraint - every team needs to cross domains. This constraint can be met by forming new teams with members who used to work in different domains.

While the most flexibility comes from any team being able to work on any domain, we also get the most (short-term) challenge in getting items done as skills are scattered the most. To balance this, we may choose a more gradual approach by setting the constraint of any team at least crossing two domains, rather than all 3 domains. In many cases, this has already helped achieve sufficient flexibility.

A final note, when we do not label teams with domains, they may still develop domain speciality over time. However, when we detach specialization and responsibility, we do not overly develop constraint.