(this article is part of the upcoming “97 Things every Scrum practitioner should know” by Gunther Verheyen (editor))

When applying Scrum to a product with more than one Development Team, there is really little guidance in the Scrum Guide. The Scrum Guide seems focused on one-team Scrum for the most part. The only hint you get is in the Product Backlog section:

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed. (Scrum Guide November 2017)

We learn that, with multiple teams, we are advised to still use a single Product Backlog. Nothing is mentioned regarding the roles of Product Owner, Development Team, or Scrum Master other than “multiple Scrum Teams” working on the same product.

But how do you decide over priorities? If we take the Scrum Guide literally, there could be more than one Product Owner in each of the Scrum Teams on that product, or it could be the same person for all the teams involved.

Generally, this is the distinction between “Multiple Scrum Teams” and “Multi-Team Scrum”.

Multiple Scrum Teams

“Multiple Scrum Teams” typically holds that each Development Team has a Product Owner, yet there is a single Product Backlog. That means that potentially different people in the role of Product Owner need to coordinate with each other regarding their individual priorities, and come up with the most valuable items to be worked on.

Sometimes this set-up seems connected to having different specializations in the Development Teams. This works well if the workload on each of the specialist topics is evenly distributed across the different teams - and will stay that way for the near future. If that is not the case (which is highly likely), then one team might end up working on lower-priority, and thus lower-valuable, work for the product, just because that type of work is their specialty.

This setup generally also complicates the transparency of insights into the whole product. Not only is the in-depth knowledge about the product split across the different Scrum Teams, but also across the different Product Owners. After development on particular features has finished, additional coordination is needed on the different partial results of the product in order to have them integrated into a whole product that can be released to the customer and user. Unfortunately a Multiple Scrum Teams setting provides little incentive for cross-team collaboration, since everything will be taken care of by the additional coordination overhead that it produces.

Multi-Team Scrum

In a “Multi-Team Scrum” setting, there is not just a single Product Backlog but also a single Product Owner who works with the multiple Development Teams. The sole Product Owner makes product-wide decisions that are fully transparent via the single Product Backlog, and the product versions created.

This setting demands a cross-functional approach from the teams. Specialization in the customer domain may still happen, but will have to dissolve once priorities and demands start to shift. For example, one team working on accounting functionality will have to shift from accounting features to another type of features if there are no longer any accounting features at the highest priority in the Product Backlog.

This setting therefore lays the demand for coordination with the teams themselves. They have to make sure to deliver an integrated product Increment at the end of every Sprint. Depending on where you start, this may result in a steep learning curve.

(Originally published on Odd-e’s blog)

It is natural that people specialize in various things, but when they do it too much, it becomes over-specialization. Over-specialization wastes our potential. We shall try to understand why it happens, and how the adoption of LeSS avoids it.

Eroding goals

“Eroding goals” is a system archetype consisting of two balancing loops. Think of any problem as the gap between the goal and the actual state. There are two types of solutions. One is to improve the actual state so that the gap is reduced (i.e. problem is solved), the other is to lower the goal. Over time, this evolves into “eroding goals”, and can lead to a “boiling frog” situation. This is a very simple, but powerful dynamic. Let’s see a few examples at work.

PO specializing in a domain

I have described this topic in the article about “team PO as anti-pattern”. Here we don’t talk about fake POs who are not responsible for the product. The real PO may still specialize in some product domain. This is often a response to the capability gap.

The B1 loop illustrates the solution of lowering the goal. By having more POs, the scope of every PO would be narrower, which requires lower capability.

The B2 loop illustrates the solution of improving the actual state. By increasing the learning, the available capability improves. However, it will take time, which makes B1 loop dominant - the goal erodes. This is what we have observed. While growing a company, each PO gets narrower and narrower scope to be responsible for. Also note that we get more and more POs in this dynamic.

Team specializing in a function, component or domain

Let’s look at the team. Team may specialize in some function, component or domain. They become a functional team, a component team and a specialized feature team, respectively. Specialized feature team here means that it is able to deliver end-to-end feature, but it has its own product backlog only containing features of the partial product, i.e. specializing in a product domain.

This is essentially the same dynamic as with PO specialization. The B1 loop lowers the goal by having more teams and each team responsible for the narrower scope, be it function, component or domain. The B2 loop improves the capability, but takes time. This is why we observe that teams get more and more specialized, and meanwhile we get more and more teams.

Individual specializing in function, component or domain

Let’s look at team members. An individual team member may also specialize in some function, component or domain too. They become specialists in the team.

This is actually a generalisation of PO specialization, and we see the same dynamic. Individuals get more and more specialized until they become single specialists. It causes creation of a dynamic (non-stable) team to match the work and ultimately feature group or project in a matrix organization. Likewise, we get more and more people.

This is something I have observed in many organizations. Over time, people specialize more and more, and the company grows bigger and bigger in size, while people’s potential is not fully realized!

LeSS promotes learning

Interestingly and perhaps accidentally, LeSS avoids “eroding goals”.

Which one is better, being comfortable but not reaching the potential, or “painfully” growing and realizing one’s full potential? This gets philosophical and surely everybody has their own answer.

(Originally published on Odd-e’s blog)

In my previous article on Number of backlogs and multi-learning, I wrote: “agility is delivering highest customer value in an uncertain environment. With uncertainty, the ability to deliver is not sufficient, we need the ability to inspect and adapt, in order to deliver the 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. 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 models 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. Let’s look at those 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 models and systems thinking.

Lean startup popularized 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 growth and product needs growth engine. This is a 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-and-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 ways 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 models 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 to a 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 on actual results 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 models and team learning.

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

The above figure provides the setting. Suppose we have 3 feature teams for one product. We could have 1 backlog and let 3 teams share it (the left side) or we could have 3 backlogs and let 3 teams have their own backlogs (the right side). Adaptiveness means team’s capability of changing to do other higher-value work. It is affected by both the motivation and the ability to adapt.

We came up with the below CLD representing one mental model.

There were three causal paths indicating the relations between the number of backlogs and adaptiveness.

1. More backlogs, lower transparency, lower motivation to adapt, lower adaptiveness.
2. More backlogs, smaller work scope for any team, stronger local identity, lower motivation to adapt, lower adaptiveness.
3. More backlogs, smaller work scope for any team, higher specialization, smaller knowledge breadth, lower ability to adapt, lower adaptiveness.

One student shared that in her organization, they had more backlogs (i.e. the case of 3 teams and 3 backlogs), but it did not seem to lead to lower adaptiveness. What happened? We then reasoned about each path and explored other possible mental models, by doing both advocacy and inquiry.

1. More backlogs, lower transparency, lower motivation to adapt, lower adaptiveness.

   [me] Did more backlogs lead to lower transparency?

   [student] What is transparency here, could you elaborate more?

   [me] Transparency here means the chance of knowing the value of their work, relative to other work on the same whole product by other teams. When each team has their own backlog, teams may not know that they might be doing globally lower-value work. Does this happen in your organization?

   [student] Not really. We have pretty fast feedback for our work. If one team does lower-value work, the business impact would be lower, which would be visible for them quite soon.

   [me] Interesting, so, then, the motivation to adapt stays high?

   [student] Yes. We are always motivated to adapt to higher-value work.

2. More backlogs, smaller work scope for any team, stronger local identity, lower motivation to adapt, lower adaptiveness.

   [me] How about local identity? Having their own backlog limits the work scope for the team, thus the team develops stronger local identity, which demotivates them to work on any other work outside of their scope. Do you see this in your organization?

   [student] Not really. It is the norm in our organization that if the business impact is low, we gotta change. Our team never sticks with the local identity. I guess this is because we are always driven by business success.

3. More backlogs, smaller work scope for any team, higher specialization, smaller knowledge breadth, lower ability to adapt, lower adaptiveness.

   [me] How about the ability to adapt? As each team gets specialized in their work scope, their knowledge breadth gets smaller and thus decreases the ability to adapt. Do you see this in your organization?

   [student] Indeed, the adaptation is always painful for the team. They are motivated to adapt, but they don’t prepare for it in terms of knowledge. We have been struggling with this.

   [me] Yes, in LeSS, there is only one backlog and multi-team PBR is specially designed to maximize broad learning optimizing for the adaptiveness.

We updated the original CLD, reflecting the different mental models that we explored.

For their organization, strong reliance on business feedback increases the motivation to adapt, while the limited broad learning due to specialization decreases the ability to adapt.

One challenge in working with mental models is that they are implicit. CLD helps to express it, and doing both advocacy and inquiry on the causal links is a powerful way to explore different mental models.

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

Correlation vs. Causation

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.

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 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.

Systems Thinking

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 Point is …

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