Seeing system dynamics in organizational change: 2) local optimization and system optimizing goal

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.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai