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.

Team name.jpg

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.

Read more



ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai