Seeing the underlying resource thinking

Creating stable teams and having teams work from one priority are two critical ideas in large-scale product development. This means when we discover some work, we put it into the overall backlog with appropriate priority; then, all teams share same priority, and any team may do the work.


However, two common counter ideas often pop up.


1. Change work priority to match team skill


Only the team with matched skill will be considered for the work, while other teams will not, even they are available. What will other teams do? Because they should not be idle, they do work that has lower priority but matches their skill.


2. Create project team to match individual skill


When the work requires skills across groups, people from those groups are pulled into a short-term team only for this work, so that individuals can do the part matching their skills. This is the traditional project team approach.


I felt a bit frustrated when I heard those ideas again during my recent consulting. It seems so deeply held, thus I decide to make a deep analysis resulting in the below CLD (Causal-Loop Diagram).


Resource thinking.jpg


The two counter ideas, which are in fact solutions on how to organize people for work, are illustrated by two B-loops (B1 and B2).


The B1-loop reads like this:


the more delivery pressure ->

the more consideration for skill in prioritization ->

the more match between work and skill ->

the more efficiency ->

the more value delivery ->

the less delivery pressure


The B2-loop reads like this:


the more delivery pressure ->

the more consideration for skill in forming team ->

the more match between work and skill ->

the more efficiency ->

the more value delivery ->

the less delivery pressure


They both try to create the match between work and skill, thus optimize for efficiency.


However, they also create intended/unintended consequences illustrated by other loops in the diagram.


1. Less value delivery


This is illustrated by the R1-loop, which reads like this:


the more delivery pressure ->

the more consideration for skill in prioritization ->

the less value delivery (as it constrains prioritizing high value items) ->

the more delivery pressure


As the value delivery is affected by both value in items and the number of delivered items (efficiency), R1 and B1 together create an economic tradeoff. Depending on which loop is dominant, it may deliver less value, even though the efficiency goes up.


2. Lower team performance


This is illustrated by the R2-loop, which reads like this:


the more delivery pressure ->

the more consideration for skill in forming team ->

the less stable the team is (as the work is dynamic) ->

the less efficiency at the team level (as it takes stability to perform at the team level) ->

the less value delivery ->

the more delivery pressure


R2 shows the fix (create project team to match individual skill) that backfires, as those teams exist only in short term while the stability is essential for team performance.


3. Less learning


This is illustrated by the R3-loop, which reads like this:


the more delivery pressure ->

the more consideration for skill either in prioritization, or in forming team (actually two loops) ->

the more match between work and skill ->

the less learning ->

the less efficiency (in the long term) ->

the less value delivery ->

the more delivery pressure


R3 shows the fixes (change work priority and create project team) that backfire, as they both create more match between work and skill, which reduces learning!


What we are seeing in the diagram is really the underlying resource thinking.


  • Skill utilization is more important than value delivery
  • Team is no more than sum of individuals
  • People are fixed in one skill and they cannot learn


As learning is essential in any product development, the mismatch between work and skill is not something nice to have, but must have. By creating stable teams and having teams work from one priority will you create the mismatch to promote learning!

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