Alternative to Reorganization

Reorganize to adapt

Uncertainty causes the need to adapt, but the current organization structure is a drag for adaptation. It seems inevitable to reorganize to adapt. Let's elaborate.

The current organization was set up based on certain (pun intended) assumptions. We looked at what needs to be done, then, organized our people into various teams of business areas and technical areas, be it function or component based. The size of each team accorded to the understanding about work at that moment, and we made it as right as we could.

Then, change always comes. This leads to certain areas having more work of high value than initially assumed, while other areas having less work of high value than initial assumed. How do we adapt?

More often than not, we don't, at least not promptly. This seems surprising - why don't we adapt? On one hand, as we have invested in creating the current structure, we unconsciously follow the plan over responding to change. On the other hand, the intricate structure of teams in various dimensions makes it hard to see the big picture. Although the situation has gradually deviated from the assumptions, only until much later do we see the consequence - deliver less value and become less competitive over time.

Or we adapt partially. We grow people in those areas having more work of high value, but we change nothing in those areas having less work of high value. It is desired that we move people from low-value area to high-value area. However, the structure makes it hard to do so. Thus, we simply tackle only half of the problem, while ignore the other half. This makes development organization grow bigger and bigger, as illustrated in my old article. Furthermore, this only works in good times.

Can we adapt fully, based on new assumptions? Yes, but only through reorganization, as the current organization was set up based on old assumptions. However, the next change will come again, thus we need to reorganize often in order to catch up changes. This can be costly.

Alternative to reorganization

Is there any alternative to reorganization? Yes, we can design organization with the aim of optimizing for adaptiveness. This is exactly what LeSS is about. Let's see a couple of design ideas from LeSS.

One idea is to decouple line organization from requirement area. The coupling makes it difficult to adapt, because the adaptation means at least some reorganization. However, when we decouple them, the adaptation only means reallocating certain teams into different areas, without changing the reporting line.

Another idea is to promote multi-learning thus develop more of multi-specialists rather than single-specialists. This is done through multi-team PBR (Product Backlog Refinement), CoP (Community of Practices), mob/pair programming, etc.

We must deliberately design our organization to optimize for global adaptiveness, rather than local efficiency. Systems thinking plays an important role in this organizational design. This is why I often introduce LeSS as using systems thinking to design a large-scale product development organization aiming for adaptiveness.

What about "if it hurts, do it more often" - does it apply onto reorganization? The idea of doing painful things more often appears a lot in agile thinking. Continuous integration is probably the most well known application of this idea - integration is painful, thus integrate continuously. Martine Fowler explained three forces behind this effect. Would the reduced amount help? Yes, partial reorganization concerns fewer people, thus less painful for the whole organization, though not much for the people involved. Would more learning associated with more frequent feedback help? Would more practices help? Yes, both learning and practices would improve our skills of doing this thing. So, if we do reorganization more often, we possibly do it better, thus it becomes less painful. In other words, we keep asking - how can we reduce the cost of reorganization? The answers will lead us to experiment with different organizational designs.

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