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.


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.

About this Entry

This page contains a single entry by Lv Yi published on October 23, 2017 1:27 PM.

Change starts before it starts was the previous entry in this blog.

Team PO as anti-pattern is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.