March 2023 Archives

It seems self-evident that story is only about change - when it gets done, it becomes part of the baseline. However, in practice, I often observe that people don't make the distinction between change and baseline, which causes pains.

Mixing change and baseline

Let's look at the below example.

create a person with same name

• response with success or failure
• failure includes reason
• attributes include name and title
• name begins with letter and has less than 20 characters
• if the name already exists, create a variant (lv yi -> lv yi.1)
• title is either developer or coach

This is a story from an application of people management. It is about creating a person with same name. While it looks good, there is confusion about what the change is. Is it the whole functionality of creating a person, or is it only the part dealing with same name?

As story is about change, let us only describe the change. The updated story could be as below.

deal with same name

• if the name already exists, create a variant (lv yi -> lv yi.1)

Isn't it easier to understand this story than the first one? It only focuses on the change, while leaving out the existing part.

But, isn't the first one more self-contained, thus more convenient in the way developers can learn about related parts - both existing and new - all at once? Indeed, changes are scattered, and they are not friendly for learning the big picture. This calls for baseline.

Missing baseline

Baseline accumulates all changes till now. Once we implement a change, the change becomes part of the baseline.

It is surprisingly common that we don't maintain a baseline, only changes along the way. Missing baseline is the deep issue, and it causes various pains.

How do we learn about the application? We should learn from the baseline, but we haven't maintained it except the application itself or user manual.

How do we make a full regression? We should test against the baseline, but all the details especially expected results are described in the changes. In order to do it properly, we have to re-establish the baseline from the changes, but in practice we seldom do it, because doing it all at once is painstaking. Instead, we do a little bit, for example, creating a set of smoke tests, which is essentially a minimum baseline. Of course, the better way is to establish the baseline from the beginning, and maintain it all along. This can be something as below.

create a person

• response with success or failure
• failure includes reason
• attributes include name and title
• name begins with letter and has less than 20 characters
• if the name already exists, create a variant (lv yi -> lv yi.1)
• title is either developer or coach

Notice that this is not a story, but a baseline functionality of creating a person. Several stories may have changed this functionality, but this is what it is now.

Although this can be a baseline document we maintain all along (the stories can be thrown away after it is developed), the better form is automated tests, which becomes living documentation. You may learn more from "Specification By Example".

I believe that understanding this distinction can help make our product development more sustainable.

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.