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.
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.
More backlogs, lower transparency, lower motivation to adapt, lower adaptiveness.
More backlogs, smaller work scope for any team, stronger local identity, lower motivation to adapt, lower adaptiveness.
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.
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.
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.
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.
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 :)
(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:
A series of choices
LeSS is a series of choices for large-scale product development. We could make any choice if we are not clear about the optimizing goal. The choices made by LeSS are optimized for agility and adaptiveness. Among others, two choices stand out:
To get the informed consent about adopting LeSS, i.e. making a series of choices, we should explore and see the system dynamics behind those choices. This is why systems thinking is critical in understanding LeSS.
Systems thinking
Systems thinking sounds great, thus, it could be claimed to be relevant anywhere. LeSS applies it concretely to evaluate the choices you make. What is the system optimizing goal? What are your choices? What are the causes behind them? What are the consequences? Are they consistent with your system optimizing goal?
I am often asked to compare LeSS with SAFe and other frameworks. I don’t have an answer, but would like to offer an exercise of system modeling on the different choices those frameworks offer. We evaluate those by applying systems thinking.
When a team gets big, we split it into two. How? Typically by dividing into components or sub-components. Why do we split this way? What are the consequences? What are the alternatives? Often, we did not think it through. That is the typical manifestation of fast thinking. However, those choices are so important that they deserve slow thinking. System modeling helps us do slow thinking, and critical thinking.
Learning organization
If you practice systems thinking on your choices, you are free to do experiments that may not be consistent with LeSS. Eventually, you “own” what you do, rather than “rent” ideas from others. Less copying, more learning.
Systems thinking is the cornerstone (i.e. the fifth discipline) for a learning organization. LeSS opens up the stairway to a learning organization in the field of product development. By experimenting and practicing the five disciplines, we move toward the learning organization, while LeSS is a starting point in the journey.
This is my view of LeSS.
P.S. I had to ask my daughter for help in doing this graphical representation. I noticed a small detail afterwards. There are two paths to the house representing the learning organization. One is through the back door, which is the shorter route; the other is through the front door, which is the longer route. They happen to be a good representation of fast thinking and slow thinking.
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!
Implicit Backlogs
When the Scrum Team keeps the goal of making people busy, it has multiple implicit backlogs, not one. The typical phrase that you can hear is, “I will do this feature because I am familiar with X technology.” The Product Owner is forced to change the order of the Product Backlog to make people busy in Sprint. Thus, the team doesn’t work on the most critical features from a customer perspective and sub-optimizes the value delivery. Let’s take a look at this from a Systems Thinking perspective (see Figure 1).
We obtained the first balancing loop “B1: Making people busy”. The more perceived skill gap to develop the most critical features from a customer’s perspective, the more team stress, the more pressure to increase the number of implicit backlogs (“these are my features, those are yours”). That makes developers locally efficient at the cost of sub-optimizing the whole.
Developers are efficient at the cost of sub-optimizing the whole!
Pay attention to the mental models:
“I don’t know this stuff. I’m not a ‘XXX’ developer.”
“It’s the best and most efficient when everyone is busy and doing ‘his/her work’”
This dynamic doesn’t happen at a single team level only. When the knowledge gap becomes really large, then new teams with separate backlogs emerge. Let’s investigate this dynamic further.
More Backlogs Implies More Work-In-Progress (WIP)
One company of a friend of mine started as a small startup a few years ago. Five people were sitting in the same room, working on one product. They worked as a real Scrum Team swarming all day long. They were nimble and agile in those days. Everyone was engaged in the most crucial work, regardless of the primary specialization. What happened after several years? As the company grew, the number of backlogs increased dramatically. They ended up with 13 “Product Backlogs”: iOS Backlog, Android Backlog, UI/UX backlog, and many more. Homogeneous teams were composed of narrow specialists that worked very efficiently from their perspective. The average Work-In-Progress (WIP) of the whole system increased significantly because developers were focused on starting and finishing their own work in their local backlogs. This amplified the lead time and caused organizational stress. The product organization wasn’t able to deliver value to the market early. Management reacted to this stress in a predictable way; they asked people to work harder. This led to even more backlogs, more Work-In-Progress (WIP), and more organizational stress. The above mentioned dynamic is shown in Figure 2:
Pay attention to the mental model:
“People don’t work hard enough.”
The system diagram illustrates how focusing on making people busy impacts the speed of delivering value early in the long-term. More backlogs also mean more dependencies which also impacts value delivery. Let’s investigate this in the next section.
More Backlogs Implies Dependencies and Reduced Value
When an organization introduces more backlogs, the teams become less cross-functional. This inevitably leads to dependencies (shown in Figure 3).
The organization starts managing dependencies instead of eliminating them. The more dependencies, the smaller the probability that an end-to-end customer-centric feature will be “Done” in a Sprint. Dependencies affect the lead time, which in turn introduces a new form of organizational stress. Furthermore, teams working from multiple backlogs do not even realize that they are not working on the most critical pieces from a customer’s perspective.
Multiple teams working from multiple backlogs do not realize that they are not working on the most critical pieces from a customer’s perspective!
Why? Let me illustrate this concept with a short story. In 2019 I started working with a product group that was developing a complex banking solution. When I joined them, they already had three cross-functional feature teams working from three separate backlogs. I asked the “Product Owners” and the “Chief Product Owner” to create a single Product Backlog instead. You can see the result below:
It was not evident that work was not distributed evenly until they examined it in one queue. The colors of the stickies represent different parts of the product from the customer’s perspective. Having three backlogs meant that teams were sub-optimizing the whole while working on less critical features. If we look at the resulting system diagram, we can see three reinforcing loops R2, R3, R4 that create a “Fixes That Backfire” archetype with B1 (shown in Figure 5):
The central theme of the pattern “Fixes That Backfire” is that people make a reasonable attempt to remedy an unwanted situation. Still, after the ‘fix’, the problem comes back – sometimes in a different form – often more prominently than before. Doing more of the same actions just worsens the situation. More backlogs lead to bigger problem, longer lead time, and more organizational stress.
Now let’s see how to redesign the system to optimize value delivery instead of making people busy.
Optimizing Value Implies One Backlog and Multi-Functional Learning
As I mentioned before, the fundamental problem in a complex environment is uneven distribution of work.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. – The Scrum Guide
You can consider optimizing value strategy in the context of two steps:
Create a single customer-centric Product Backlog that reflects the most important features from the customer’s perspective. Of course, those features are our speculations of what we think is the most valuable.
Ask the team(s) to respect, in general, the order of the customer-centric Product Backlog.
Unfortunately, working from a single queue of requirements creates a painful gap in knowledge. The bigger the skill gap, the bigger the need for developers to help others to acquire new skills. But this strategy pays off after some time and leads to the development of multi-functional specialists and Agility. Look at Figure 6:
Pay attention to the mental models:
“We need to respect the order of the Product Backlog.”
“People may learn and acquire new skills over time’”
“Agility requires multilearning.”
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. – The Scrum Guide
Frankly, there is nothing new in the concept of multi-functional specialists and cross-functional learning. The origins of Scrum can be found in “The New New Product Development Game” paper, with multilearning being one of the main characteristics of effective teams. Multi-functional specialists were introduced in Toyota a long time ago:
In 1947, we arranged machines in parallel lines or in an L shape and tried having one worker operate three or four machines along the processing route. We encountered strong resistance among the production workers, however, even though there was no increase in work or hours. Our craftsmen did not like the new arrangement that required them to function as multi-skilled operators. They did not like changing from “one operator, one machine” to a system of “one operator, many machines in different processes.” – Taiichi Ohno, The Toyota Production System, 1988
I often hear the argument: “We understand the idea behind that. But still, a deep specialist will be more effective and knowledgeable than a cross-trained one”. And I agree with the argument. But we do not train people to create an efficient resource. Instead, we create a team capable of dealing with bottlenecks by themselves.
We do not train people to create an efficient resource. Instead, we create a team capable of dealing with bottlenecks by themselves!
Remember, when the system is heavily loaded, even a small change in capacity can lead to a significant difference in cycle time. In “Managing the Design Factory” Donald G. Reinertsen writes:
This ability of autonomous teams to align resources to bottlenecks is extremely important because it minimizes queues in the development process. Since these bottlenecks can shift rapidly and unpredictably during a program, the flexibility of team members to work outside of speciality is a critical tool for dealing with such bottlenecks. – D. G. Reinertsen
Dealing with a Culture of Narrow Specialists
Unfortunately, many teams prefer applying fixes and follow the resource utilization strategy. This approach is not a good idea if we want to optimize the whole. The quick fix of increasing the number of backlogs has a side effect that weakens the system’s natural ability to implement a more fundamental correction. When a Scrum Team adopts the resource utilization strategy and keeps doing it for some time, it creates a culture of narrow specialists. It takes a lot of effort, leadership support, and patience to overcome the resistance to change from the team, and to apply the fundamental solution instead. If we look at the final system diagram, we can see the reinforcing loop R6 that corresponds to the culture of narrow specialists:
Pay attention to the mental model:
“This is weird. Multi-functional people do not exist. It’s a myth”.
Therefore, with the help of system diagrams, we investigated the implications of learning disability in teams. Quick fixes have long-term consequences. The act of increasing the number of explicit or implicit backlogs spawns lots of problems: more Work-In-Progress, more queues, longer lead times, organizational stress, less delivered value. The fundamental solution is multi-functional learning.
Multi-Functional Learning is the Heart of Agility!
How to Enable Learning and Increase Agility?
There are many options for dealing with the situation when the Scrum Team(s) are used to work in the “make people busy” mode. Here are some of them:
Point out the tendency of the Scrum Team to focus on resource utilization instead of increasing Agility.
Conduct a system modeling workshop and let people have their insights regarding the “making everyone busy” strategy and the consequences associated with it. Use the system diagrams presented in this article for inspiration.
Create an awareness that people are working on less critical stuff from the customer’s perspective by creating a single queue of requirements. When possible, use the “cold turkey” strategy and move to a single Product Backlog overnight.
Gradually reduce the number of backlogs over time if there is a painful knowledge gap.
Point out that, in Scrum, the Product Backlog is ordered. You can use a simple rule that in general, the items at the top should be “Done” before the team proceeds to less important ones.
Establish a Perfection Vision that would take precedence over responding to the pressure of local optimization.
Use the Competency Matrix for inspecting and adapting the team’s cross-functionality. Update it regularly.
Create an agreement on how the team(s) would deal with the knowledge gap. For instance, it could consist of several points: a) help your teammates; b) remove technical debt; c) learn something valuable; d) start new work (last and worst option).
Try implementing the pattern “Swarming: One-Piece Continuous Flow.” The best Development Teams I have collaborated with, worked using three modes: pair-programming, mob-programming, and swarming continuously.
Try to change HR-practices to enable the development of multi-functional specialists in an organization.
In the next article, we shall dive deeper into tips and tricks for enabling multi-functional learning and increasing Agility.
Takeaways
In complex environments, work is never distributed evenly in Sprints. When developers are working on customer-centric Product Backlog Items, they experience a knowledge gap. There are two primary responses to this challenge. The first is to follow the path of resource utilization and to increase the number of implicit or explicit backlogs. Developers become individually more efficient, but at the cost of sub-optimizing the whole system. The solution is to respect the order of one Product Backlog by helping others and embracing multi-functional learning. Over time this strategy creates a flexible team. You train people to deal with bottlenecks. The culture of narrow specialists stays in the way of multi-functional learning. There are many ways to fight this culture and to preserve the long-term strategy. Getting teams to work continuously in pairing, mob-programming and swarming modes is one of the most effective approaches for this.
RSS feed