Why product development group ever grows

I have seen ever-growing development group over and over again, whether it is a component team, a specialized feature team, or a Requirement Area (RA). There is an intriguing dynamic behind.

Ever-growing people

Work vs. People.jpg

This is my first time writing a dynamic with Stock & Flow Diagram (SFD) rather than Causal Loop Diagram (CLD). The reason is that for this dynamic, the distinction between stock and flow is important, and it makes the dynamic more clear and easier to understand.

In CLD, all are identified as variables. In SFD, there are three types of variables - stock represented by the rectangle, flow represented by the oval, and auxiliary variable represented by the diamond. Flow is further defined as inflow and outflow. Inflow increases the stock, while outflow decreases the stock. Thus, while you count the number of links to identify the polarity (Reinforcing or Balancing) of a loop, you treat inflow to stock as +, and outflow from stock as -.

B1-loop: hiring for people gap

  • the more customer work coming
  • the longer work backlog
  • the more people gap
  • the more hiring or moving in people
  • the more people for work
  • the higher velocity
  • the more work done
  • the shorter work backlog

In short, B1-loop illustrates that we hire people to complete growing work.

The customer work fluctuates. This happens naturally in one part of the product, either components or customer domains, if we prioritize the work for the whole product.

When the customer work decreases (i.e. there is work gap), there are two solutions illustrated by B2-loop and B3-loop.

B2-loop: moving people out for work gap

  • the less customer work coming
  • the shorter work backlog
  • the more work gap
  • the more firing or moving out people
  • the fewer people for work
  • the lower velocity
  • the less work done
  • the longer work backlog

Assuming that firing is not desired, B2-loop illustrates that we move people out from this part of the product, in response to work gap.

However, in reality, what is more often seen is the B3-loop.

B3-loop: create internal work for work gap

  • the less customer work coming
  • the shorter work backlog
  • the more work gap
  • the more internal work created
  • the longer work backlog

When there is people gap, we go for B1-loop; when there is work gap, we go for B3-loop. The intriguing thing happens, as there is no outflow for the stock of "people for work", it ever grows.

Fixed group vs. Variable work

What makes B2-loop difficult to happen in reality? Once the group is fixed on certain part of the product, the emphasis on the responsibility for that part builds silo mentality, which puts maintaining the group above the actual work situation.

Think about a couple of cases where we fix a group on certain part of the product.

  1. Component team

We fix teams on components. As the original customer work is based on features, the work going to certain components fluctuates. The above dynamic indicates that component team will ever grow. To break this, we shall adopt feature team.

  1. Specialized feature team

We fix teams on specialized area. As we set the priority for the whole product, the work going to certain areas fluctuates. The above dynamic indicates that specialized feature team will ever grow.

Isn't specialized feature team the same as RA? Yes and no.

If feature team is specialized further within RA, and they have their own team backlog, rather than one shared backlog for RA, this is not the same as feature teams in RA. The above dynamic could happen in the short term, and make the RA unnecessarily big. To break this, we shall adopt generic feature team (not constrained by the specialization and always follow one priority) within RA.

If feature team is specialized on RA, assuming that RA's work is stable during relatively long period, the dynamic happens more slowly. However, if we never change RA, the RA will ever grow too. To break this, we shall adopt dynamic RA.

In LeSS, RA is defined as dynamic area. We move teams across areas based on the long-term trend. However, in practice, the choice of whether coupling RA with line organization or site makes a big difference. Once they are coupled, the silo mentality gets stronger. It is almost doomed that RA will ever grow in the long term.

In summary, when we create fixed group for variable work, the underlying dynamic will make the group ever grow.

Endnote

What about ownership? This is the reason to create fixed group in the first place. Ownership and silo are two sides of the same coin. We shall develop the ownership for the whole product, rather than part of it.

What about outsourcing to make B2-loop happen? This is indeed the traditional response to this problem. However, it creates much more problems than it solves.

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