How does LeSS optimize organizational ability to learn?

In my previous series of article "#backlogs and multi-learning", I wrote that "the agility is to deliver highest customer value in uncertain environment. With uncertainty, the ability to deliver is not sufficient, we need the ability to inspect and adapt, in order to deliver highest customer value". Inspect, adapt and deliver is the essential cycle.

To achieve higher agility, we need to optimize for inspectability, adaptability and deliverability. LeSS optimizes adaptability via one product backlog; LeSS optimizes deliverability in terms of end-to-end cycle time via feature team; then, how does LeSS optimize inspectability, i.e. organizational ability to learn?

I have been pondering on this question for a while. In the "fifth discipline" book, there are three disciplines closely related to learning - team learning, mental model and systems thinking. I try to look for insights from them.

Scrum/LeSS has built-in events for product learning and process learning in the sprint cycle. Therefore, let's look at product learning and process learning separately.

Product learning

The most related event to product learning is sprint review. In Scrum, during sprint review, team, PO and stakeholders including users and customers together inspect the current product increment and explore the ideas for improving the product further. In LeSS, with the whole-product focus, there is one sprint review for all teams. Review bazaar is the recommended practice for the joint sprint review.

The sprint review institutionalizes the discipline of team learning - for product learning. Furthermore, in order to deepen the learning, we also need the other two disciplines - mental model and systems thinking.

Lean startup popularizes the concept of validated learning. First make hypothesis, then design experiment to test core assumptions, then learn from the validation or invalidation. This reflects the discipline of mental model. We make our mental models explicit while making hypothesis, so as to examine and improve them both before and after running the experiments.

Impact mapping shows the logic connection between product goal and features. It explicitly asks to expand the view - who else and how else would impact the goal? This reflects the discipline of systems thinking - in the space dimension. Unfortunately, impact mapping does not highlight the time dimension, i.e. short-term vs. long-term impact.

Business seeks for growth and product needs growth engine. This is the reinforcing loop. The growth is inevitably limited by certain factors. This is the "limits to growth" system archetype. I could see the merits in applying systems thinking in the product domain, but I have rarely seen its comprehensive application - through the explicit use of systems thinking tools such as behavior-over-time, causal-loop diagram, stock&flow diagram, computer simulation - in the field. It is worth experimenting to leverage its potential.

Process learning

The most related event to process learning is sprint retrospective. In Scrum, during sprint retrospective, team and PO reflect on way of working and strive for improvement. In LeSS, besides team retrospective (i.e. team does the sprint retrospective on their own), team representatives, PO, SMs and managers will have an additional overall retrospective, which has the focus on improving systems.

The sprint retrospective - both team retrospective and overall retrospective - institutionalizes the discipline of team learning - for process learning. Same as in product learning, in order to deepen the learning, we also need the other two disciplines - mental model and systems thinking.

There is a LeSS guide called "improving the system". It explicitly recommends doing systems modeling to understand the system and have a conversation to reach shared understanding. As overall retrospective has the systemic focus, applying systems thinking there is a natural fit.

In fact, every improvement action is an experiment. We first model to make our logic behind the experiment explicit for critical thinking. While modeling, the whole team practices "balancing advocacy and inquiry", and exposes different mental models. We examine those underlying assumptions via "the ladder of inference", and improve them via reflection. Then, we return to our model and learn more after running the experiment. This is the combination of systems thinking, mental model and team learning.

Conclusion

I find that there are many similarities in product and process learning, when they are elevated into higher abstract level.

Every feature is an experiment; every improvement action is an experiment. Therefore, we make hypothesis (i.e. make the logic explicit) for critical thinking; we balance advocacy and inquiry with the whole team; we examine mental models and reflect with actual result to improve them.

In short, we aim for double-loop learning, rather than single-loop learning, for both product and process, via practicing systems thinking, mental model and team learning.