Seeing system dynamics in organizational change: 7) incremental structural change

This is the seventh article in the series of seeing system dynamics in organizational change. In the last article, we concluded that incremental structural change was more appropriate for huge organizations. In this article, we shall look at the different approaches for incremental structural change.

Two approaches

There are mainly two different approaches for incremental structural change. For the ease of explaining, I shall refer to the LeSS terms, but the thinking behind goes beyond LeSS and applies to the incremental structural change in general.

Seeing system dynamics in organizational change - 7.1.jpg

The above diagram illustrates these two approaches for a typical telecom product. The product consists of 3 main subsystems - O&M (Operations & Maintenance), CP (Control Plane) and UP (User Plane). In each subsystem, there are several components. Before we start the change, all teams are organized around components and functions. The change vision is that all teams will be cross-functional and cross-component, i.e. all are feature teams. How are we going to make incremental structural change?

  1. Gradual expanding

This is the approach used with LeSS guide: feature team adoption map. We first expand the scope of component team and move it closer to feature team. For each subsystem, we make structural change to create "feature" teams inside subsystem. The expansion happens in parallel in all subsystems.

  1. Cutting through

This is the approach used with LeSS guide: one requirement area at a time. We cut through all subsystems and create the first requirement area, with a few real feature teams. In the meantime, the major part of the organization remains with the old structure.

There are similarities and differences between these two approaches.

What's the same

Both are incremental structural change. Thus, both are only the first step towards the change vision. As described in the last article of "the scope of structural change", we limit the change scope to decrease the complexity, but it extends the change period, which increases the complexity. Therefore, it is a balance.

There are a couple of challenges for incremental structural change.

  1. The initial success is critical, as there involves a reinforcing loop.
Seeing system dynamics in organizational change - 7.2.jpg

R1-loop: Result speaks

Better result, more commitment, more investment, leading to even better result. Note that it works in other direction too. Worse result, less commitment, less investment, leading to even worse result.

This is probably the most fundamental dynamic for any change. We must have the initial success and let the result speak. This applies to both approaches.

2. The change may stall after the initial success, as described in the article of "from change resistance to limits to growth". In order to grow the change, we have to set the next goal immediately after the initial success, until the change vision about organizational structure is fully achieved.

What's different

In order to have the initial success, these two approaches make different trade-offs, as summarized in the below table.

Seeing system dynamics in organizational change - 7.3.jpg

Let's elaborate in more details.

  1. Organization

We would only have real feature teams with the second approach. The change there is more disruptive, as it cuts through the whole organization. However, it does not affect everybody immediately, instead, the initial change is based on volunteering.

The second approach also leads to parallel organizations, in which one requirement area works in the new mode, while the rest of the organization remains in the old mode. This increases the complexity for change management.

  1. Customer value

Individual teams in the second approach would deliver real customer value in every sprint, while inside-subsystem "feature" teams still need to coordinate and integrate their work together for customer value delivery. In essence, inside-subsystem "feature" teams are still component teams, thus, they suffer from the same problems as component team, but to a lesser extent.

  1. Learning

Learning from a component to a subsystem is more gradual in the first approach, while broad learning is usually required immediately in the second approach. The broad learning could mean a big challenge if team members have narrowly focused on small components in the past.

In summary, both approaches are incremental, thus share the same basic reasoning and dynamic. However, they make different trade-offs for the initial success, thus take different first step.

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