(Originally published on Odd-e’s blog)
In our industry of product development, it is common that we try to learn from success. Successful people summarize a few factors from their experience, often presented as best practices, then others would learn to apply them. For example, if it is believed that “A” leads to success, then learning is focused on how to do “A” well. However, in reality, others often fail miserably after adopting “A”.
Why “A” does not lead to success for others, and what goes wrong?
Let’s first understand the difference between correlation and causation. One popular example is “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 activity.
Sometimes we mistake correlation for causation. “A” may just be correlated with 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 a successful experience, we examine the full chain of reasoning. We should learn about the causation, not about the result.
We also need to understand what type of causation it is. Is “A” sufficient for success, or is “A” necessary for success?
It is rarely the case that “A” is 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 more important for success.
It is also rarely the case that “A” is necessary for success. When “A” is necessary, not doing “A” always leads to failure. However in reality, alternatives to “A” are often available.
So, it is more likely that “A” is contributory for success; it is neither sufficient nor necessary. “A” simply provides one path. We fail miserably when treating “A” as the only answer. Instead, we should learn about it as one of the ideas for experimentation.
Seeing the causation is a good step towards real learning, but it is not enough. Product development is dynamically complex, which means that causes and effects are often distant in time and space. It is common to see only the local short-term effects, while the global long-term effects are not examined. We fail miserably when taking a static view and treating “A” as the only valid answer.
Instead, we should apply systems thinking while learning from success. Systems thinking is powerful for understanding a dynamic complex system. It is not only a problem-solving tool, but also a learning tool. We ask the following questions: Does it influence other parts of the system? What is the behavior over time? What are the underlying structure and mental models? We learn how those factors interact with each other, and how the effects evolve over time.
The most important learning is not “A” itself, but the reasoning behind it. Once you understand the logic, you must do your own reasoning. Only then, you can shift your focus on how to do “A” well. After adopting “A”, you inspect and adapt along the way, as it neither remains certain nor lasts forever.
This applies to learning about LeSS as well. LeSS framework consists of a set of practices - one backlog, one product owner, feature teams, requirement areas, 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 :)
RSS feed