(Originally published by Lv Yi on Sep 22, 2018)

The number of backlogs is the ultimate lever for agility.

This is the insight we gained from the systems modeling exercises in my recent CLP course. I used to think of two main designs from LeSS: 1) one product backlog, and 2) feature team. I realized that these two were just different applications of the same lever, which is the number of backlogs. Please note that backlogs here include all kinds: product backlog, team backlog, individual backlog, etc. Some are explicit and others maybe be implicit.

How many backlogs do we have in an organization? Does one product have one backlog? Does one team have one backlog? Or, does one person have one backlog? When all teams in the same product share one priority, there is only one backlog for the whole product. When every member in the same team has its own priority (e.g. his priority follows his speciality), there are actually many backlogs even for one team.

When we actively look for backlogs, we will find plenty.

The Essence of Scrum

Unfortunately, many so-called Scrum adoptions keep missing the essence of Scrum. They are too preoccupied with the mechanics of Scrum; process, roles, meetings, and certifications. Or, even worse, they are obsessed with non-Scrum practices such as stories, points, velocity, task boards, or product boxes.

(this article is part of the upcoming “97 Things every Scrum practitioner should know” by Gunther Verheyen (editor))

When applying Scrum to a product with more than one Development Team, there is really little guidance in the Scrum Guide. The Scrum Guide seems focused on one-team Scrum for the most part. The only hint you get is in the Product Backlog section:

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed. (Scrum Guide November 2017)

We learn that, with multiple teams, we are advised to still use a single Product Backlog. Nothing is mentioned regarding the roles of Product Owner, Development Team, or Scrum Master other than “multiple Scrum Teams” working on the same product.

But how do you decide over priorities? If we take the Scrum Guide literally, there could be more than one Product Owner in each of the Scrum Teams on that product, or it could be the same person for all the teams involved.

Generally, this is the distinction between “Multiple Scrum Teams” and “Multi-Team Scrum”.

(Originally published on Odd-e’s blog)

It is natural that people specialize in various things, but when they do it too much, it becomes over-specialization. Over-specialization wastes our potential. We shall try to understand why it happens, and how the adoption of LeSS avoids it.

(Originally published on Odd-e’s blog)