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:)

Read more



ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai