(Originally published on Odd-e’s blog)

(Originally published on Odd-e’s blog)

A mental model reflects an individual’s beliefs, values, and assumptions. As those are internal, we need to somehow express them in order to learn and improve. Causal Loop Diagram (CLD) is a powerful technique from Systems thinking. Models created using CLD often reflect the mental models of people creating them. We could explore different mental models by simply doing advocacy and inquiry with CLD. Balancing advocacy and inquiry is one key practice for the discipline of mental models, among the five disciplines from the classical “The fifth discipline” book.

In this article I’d like to share with you an example. It came from my CLP when we were doing system modeling for the number of backlogs and its impact on adaptiveness.

(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?

(Originally published on Odd-e’s blog on Jun 15, 2018.)

As part of the LeSS trainer application, I was asked to give a graphical representation of LeSS. Here’s the result showing my view of LeSS:

In this article, we shall investigate why the learning and development of multi-functional specialists in Scrum is the core of organizational Agility and value optimization. Many Development Teams are not collaborating as real teams, but as a collection of narrow specialists focused on “their” tasks (QA, Backend, iOS, Android, etc). This leads to an ever-increasing number of explicit and implicit backlogs, “dependencies”, more Work-In-Progress (WIP), queues, and unsatisfactory lead times. How does it affect organizational Agility and what to do about it?

Making People Busy is Not the Goal

Recently I observed a few teams in a large service company during an extended enterprise Go See effort. I attended various Scrum Events, followed teams collaborating daily, noticed how they dealt with conflicts, and much more. We have done it for a very sound reason - to uncover the underlying system structures and come up with deep interventions. What immediately caught my attention was the focus on resource utilization during Sprint Planning. Some of the phrases that caught my attention:

• “Do we have enough work for the designer in this Sprint?”
• “Seems like testers are already filled up with work.”
• “Can we pull another item for our iOS developer to make her busy?”

The fundamental issue in complex environments is that work is never distributed evenly for a cross-functional team in a Sprint. Over the years, my observation has been that many teams do not respect the order of the Product Backlog because it means facing a painful skill gap.

Respecting the Product Backlog order means facing a skill gap!