July 2018 Archives

This is the third article in the series of seeing system dynamics in organizational change. Even though we have agreed on the change vision and is progressing during the norm, we lose the plot when crisis comes.

During the norm

There is always a gap between our change vision and the reality, which is expected.

For example, we envision feature team who would:

  • clarify requirements directly with users and stakeholders
  • self-organize to coordinate directly with other teams
  • develop the feature across components

However, the reality is:

  • the quality and efficiency of clarification done by feature team is low
  • the quality and efficiency of coordination done by feature team is low
  • the quality and efficiency of some component work done by feature team is low

The suggested long-term solutions are:

  • build team's capability in clarification via coaching by PO and SM (B2-loop)
  • build team's capability in coordination via coaching by SM (B4-loop)
  • build team's capability in some component work via coaching by traveller (B6-loop)

Note: traveller is arranged to help feature team increase the knowledge on certain components.

Seeing system dynamics in organizational change - 3.1.jpg

Seeing system dynamics in organizational change - 3.2.jpg

Seeing system dynamics in organizational change - 3.3.jpg

During the norm, we make progress, but it is still not enough to fill in the gap. Then, we hit the crisis.

During the crisis

During the crisis, our survival need increases. We need quick fix, thus we:

  • reintroduce an analyst role, in the name of team PO, feature owner, etc. Essentially the old business analyst role comes back. (B1-loop)
  • reintroduce a coordinator role, in the name of feature manager, feature coordinator, etc. Essentially the old project manager role comes back. (B3-loop)
  • redefine a traveler role, so that the traveller would simply do the component work. Essentially the dynamic resource allocation in traditional project management comes back. (B5-loop)

If only they were temporary solutions!

Unfortunately, over time, we get addicted to:

  • external analyst (R1-loop)
  • external coordinator (R2-loop)
  • external traveller (R3-loop)   

Seeing system dynamics in organizational change - 3.4.jpg

Seeing system dynamics in organizational change - 3.5.jpg

Seeing system dynamics in organizational change - 3.6.jpg

We see the same "shifting the burden" archetype in all of those.

Therefore, the change vision is lost:

  • team never becomes cross-functional
  • team never becomes self-organizing
  • team never becomes cross-component

The leverage

For "shifting the burden", the leverage lies in two aspects.

  1. During the norm, we shall increase the effectiveness of the long-term solution, i.e. build team's capability via teaching and coaching. As it is long-term solution, we often lose the urgency and focus. We may break the long-term goal into sub-goals, and set time table to achieve those sub-goals.
  2. During the crisis, we shall first challenge ourselves - is it really a live-or-die situation? Even if the answer is yes, we make it clear that only do the quick fix to buy time. In order to avoid being addicted, we may put "temporary" in the name of the role, and set specific time limit for the role to expire.

Watch out on how the survival need fails our change efforts!

This is the second article in the series of seeing system dynamics in organizational change. We shall learn where the local optimization comes from, and how important it is to define a clear system optimizing goal and use that to guide the change.

Local optimization

"It is more cost-efficient to test many requirements at once." This is a typical local optimization. Why do we do this? 

Seeing system dynamics in organizational change - 2.1.jpg

B1-loop: Test many requirements at once to save cost

Once there is cost pressure, we increase the number of requirements in one test run, so as to reduce testing cost. Then, cost pressure is relieved.

We do this because the fixed cost of one test run is high, e.g. it takes much effort to set up the test environment. So, we do not make local optimization on purpose, but just try to solve a problem.

Why is it a local optimization? Let's zoom out.

Seeing system dynamics in organizational change - 2.2.jpg 

In the upper left side, it is the original B1-loop. Now, we pull more variables into the picture. When we increase the number of requirements in one test run, we increase the waiting time. On one hand, this directly increases cycle time. On the other hand, this delays the feedback, and causes more rework. The rework increases development cost (here we apply the traditional distinction between development and testing). The total cost is the sum of testing cost and development cost, thus, it may increase too. Meanwhile, the rework also increases cycle time.

In summary, if we look at the "global" effect from increasing the number of requirements in one test run, while it reduces testing cost, it increases development cost, and possibly total cost as well; and it increases cycle time.

There are actually two different kinds of local optimizations here.

  1. Reducing testing cost may increase total cost. This reflects that "optimizing the parts does not optimize the whole".
  2. Reducing cost may increase cycle time. This begs the question - what do we optimize for as a whole? I.e. what is our system optimizing goal?

System optimizing goal

If we reduce cost but increase cycle time, is it a local optimization? We could not really answer it, before we are clear about our system optimizing goal. If our goal is cost efficiency, it may be a global optimization; but if our goal is cycle time, it is clearly a local optimization.

System optimizing goal should be defined in our change vision, otherwise, we do not have solid foundation to guide the change. One of the common change efforts these days is the agile movement, what does it optimize for? It is for agility and adaptiveness, as well as maximizing customer value and reducing cycle time; but not for throughput, resource utilization, compliance, cost efficiency, etc. If the goal is not clearly set, our change effort is doomed, as local optimization would be "natural".

Even though we set cycle time as our system optimizing goal, some people may still have the cost concern. They say: "Yes, cycle time is important, but we also need to consider cost. It is simply too costly to test one requirement at a time, thus, we have to stick with the current practice of testing many requirements at once." Other people nod and the group dismiss. Craig Larman calls this "losing the plot".

In the organizational change, we need to make clear distinction between system optimizing goal and secondary concerns. We shall not solve secondary concerns at the expense of system optimizing goal. Secondary concerns should be addressed in other ways.

In this case, it means that we should break the B1-loop, while introducing an alternative B2-loop to solve the cost concern. 

Seeing system dynamics in organizational change - 2.3.jpg

B2-loop: Reduce the fixed cost in one test run

Once there is cost pressure, we increases the effort on automating test setup, which reduces the fixed cost in one test run, thus testing cost. Then, cost pressure is relieved.

In summary, it is important to set clear system optimizing goal for our change, which helps discern all sorts of local optimizations. Then, we address secondary concerns in ways that do no harm to our system optimizing goal.

I have written a series of blogs focusing on seeing system dynamics in organizational design. Now, i'd like to start a new series, focusing on organizational change.

In this first one, let's understand three common problems in organizational changes:

  1. change stalls after it is initiated, due to change resistance;
  2. change stalls after it is "done", due to goal seeking behavior;
  3. change stalls after it grows for a while, due to limits to growth.

Change resistance

Why is change resisted? A basic balancing loop is at work.

Seeing system dynamics in organizational change - 1.1.jpg

B1-loop: Change is resisted to keep status quo

Once we increase change effort, the actual increases, moving away from the goal. This increases the gap, thus, another "change" effort starts, which brings the actual back to the goal (as shown in the small arrow line at the right hand), then gap is reduced.

The goal is the status quo, and the "change" effort is change resistance. What is called change resistance is simply a force to bring the system into the stable state. Notice that there are two change efforts in the diagram. Change effort moves the actual away from the goal, while "Change" effort moves the actual back to the goal. From system perspective, they are both change forces, and neither good nor bad.

Instead of exerting more change effort, which invokes more "change" effort (i.e. change resistance), one leverage is to elevate the goal. As will be discussed in next sections, the change resistance disappears when the goal is kept above the actual continuously. This explains why many change attempts failed due to change resistance. Without the common change goal, people in the organization would naturally try to keep the status quo.

Change done

Once the goal we seek is higher than our status quo, the dynamic changes. 

Seeing system dynamics in organizational change - 1.2.jpg

B2-loop: Change is done to achieve the goal

The goal increases the gap. Change effort starts to increase the actual, which brings it towards the goal (as shown in the small arrow line at the right hand), then gap is reduced.

This balancing loop actually is no different than the B1-loop, and they both seek goal. However, as the goal in B1-loop is the status quo, thus, we see the resistance to change; while as the goal in B2-loop is the higher state than the status quo, thus, we see the support to change, till the point that the goal is achieved.

After the goal is achieved, the change is done. The goal state becomes the new status quo. How could we continue the change towards even better state? One leverage is again to elevate the goal.

Grow the change

After the original goal is achieved, we elevate the goal again to grow the change. 

Seeing system dynamics in organizational change - 1.3.jpg

R1-loop: Elevate the goal to grow the change

Once the actual increases to reach the goal through B2-loop (as shown in the first small arrow line at the right hand); we elevate the goal. Now, the B2-loop is at work again, until the new goal is reached (as shown in the second small arrow line at the right hand), we elevate the goal again. This is the essential continuous improvement.

Ideally, we would grow the change indefinitely. However, the change still stalls after a while, as there are limits to growth.

Limits to growth

In order to change the actual, it requires not only the effort, but also the capability. Capability here refers to all kinds such as organizational, technical, collaboration, and etc. 

Seeing system dynamics in organizational change - 1.4.jpg

B3-loop: Capability shortage to limit the change growth

Once the goal is elevated, the required capability increases. While the available capability is the constraint, it leads to the increasing capability shortage, which decreases the actual.

R1-loop and B3-loop create the typical "limits to growth" system archetype. In order to keep growing the change, one leverage is to build the capability earlier, as it will take time. Various constraints will be exposed along the way, but in the context of product development organizational change, some are well known. One of them is the technical weakness unfortunately seen in many development organizations. This is why for example in LeSS, it is recommended to start technical coaching for a few months before doing organizational redesign. This is to remove the constraint before we hit it.

In summary, in order to grow the change forever (i.e. continuous improvement), the main leverages are as following:

  • create the common goal to be higher than status quo, in order to avoid the change resistance
  • elevate the goal to grow the change, in order to avoid the change being stalled after it is "done"
  • remove the constraints earlier, in order to avoid the change being stalled when hitting the limits

About this Archive

This page is an archive of entries from July 2018 listed from newest to oldest.

June 2018 is the previous archive.

August 2018 is the next archive.

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