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.
