The trap in learning from success
In our industry of product development, it is common that we try to learn from success. The successful people summarize a few factors from their experience, often in the name of best practices, then others would learn to apply. It is believed that A leads to success, thus the learning is focused on how to do A well. However, in reality, others often fail miserably after adopting A.
Why does A not lead to success for others, and what went wrong?
Correlation vs. Causation
Let's first understand the difference between correlation and causation. The most popular example is perhaps "does ice cream cause drowning?". They are correlated - when ice cream sales are high, so is the number of drownings. However, ice cream does not cause drowning. In fact, it is the hot summer that boosts both ice cream sales and swimming.
Sometimes we mistake correlation as causation. A may just be correlated to success, but does not cause success. Of course, we would not get the desired effect when adopting A.
How can we get the causation right? It is hard indeed. What helps is while learning from success, we examine the full chain of reasoning. We should learn about the causation, not the result.
Types of Causation
We also need to understand what type of causation it is. Is A sufficient for success, or is A necessary for success?
It is hardly the case that A would be sufficient for success. When A is sufficient, doing A is enough for success. However in reality, there are often other hidden factors, and they may even be necessary for success.
It is hardly the case either that A would be necessary for success. When A is necessary, not doing A always leads to failure. However in reality, there are often alternatives to A.
So, it is more likely that A is contributory for success - neither sufficient nor necessary. A simply provides one path. We fail miserably when treating A as the certain answer. Instead, we should learn them as the ideas for experimentation.
Systems Thinking
Seeing the causation is a good step towards real learning, but it is not enough.
Product development system is dynamically complex, which means that cause and effect are often distant in time and space. It is common that we only see the local effect and the short-term effect, while the global effect and the long-term effect are not examined. We fail miserably when taking the static view and treating A as the forever answer.
Instead, we should apply systems thinking while learning from success. Systems thinking is powerful in understanding dynamically complex system. It is not only a problem-solving tool, but also a learning tool. We ask the following questions. Does it influence other part of the system? What is the behavior over time? What is the underlying structure and mental models? We learn how those factors interact with each other, and how the effects evolve over time.
The Point is ...
The most important learning is not A itself, but the reasoning behind.
Once you understand the logic, you do your own reasoning. Only then, you shift your focus to learn how to do A well. After adopting A, you inspect and adapt along the way, as it is neither certain nor forever.
This applies to learn about LeSS as well. LeSS framework consists of a set of practices - one backlog, one product owner, feature team, requirement area, etc. However, the most important learning should come from the reasoning. If you simply copy LeSS as "certain and forever" best practices, I bet that you will fail miserably too:)
