#backlogs - the ultimate lever
#backlogs is the ultimate lever for agility.
This is the insight we gained from the systems modeling exercises in my recent CLP course. I used to think of two main designs from LeSS: 1) one product backlog and 2) feature team. I found that these two were just the different applications of the same lever, which is #backlogs. Please be noted that backlogs here are all kinds, including product backlog, team backlog, individual backlog, etc. Some are explicit, and the other are implicit.
How many backlogs do we have in an organization? Does one product have one backlog? Does one team have one backlog? Or, does one person have one backlog? When all teams in the same product share one priority, there is only one backlog for the whole product. When every member in the same team has its own priority (e.g. his priority follows his speciality), there are actually many backlogs even for one team.
When we actively look for backlogs, we will find plenty.
Effects on agility
When we find many backlogs, there are two kinds.
- Parallel/independent backlogs
This is the case when each feature team specializes in one customer domain and has its own backlog. What if there is more high-value demand from one of those customer domains? As other teams have their own backlogs, we won't be able to adapt based on the shifting demand and maximize the customer value.
The more parallel/independent backlogs, the less adaptiveness.
- Sequential/dependent backlogs
This is the case when each component team specializes in one technical domain and has its own backlog. What if the feature requires the change in all those technical domains? As each team has its own backlog, chances are that not all of their work will be in sync, thus the end-to-end cycle time will increase.
The more sequential/dependent backlogs, the longer cycle time. Eventually it does harm to the adaptiveness.
Agility means adaptiveness. In short, the more backlogs, the less agility.
Constraints from specialization
Why do we create many backlogs? We want specialization. Why do we create backlog for each customer domain? We want specialization on customer domain. Why do we create backlog for each technical domain? We want specialization on technical domain.
The more specialization, the more efficiency and the higher quality. It must be good, right? However, it becomes our constraints over time, and does harm to our agility. When it happens, is it our conscious decision? Most likely not, it is just based on our fast thinking. Instead, we should do more slow thinking here, so as to see its consequence.
Having everyone able to do everything is a sufficient but not necessary condition to enable one backlog in the team. Similarly, having every team able to do everything is a sufficient but not necessary condition to enable one backlog in the product. The key is, there should be no constraints when we say that those people or teams have one backlog. Once we could not adapt to maximize customer value, we are over-specialized.
How do we reduce the constraints? We learn, and we cross-learn. When we are less constrained by our specialization, we are more agile. Learning effectiveness should become our focus in order to reduce #backlogs and achieve agility.
LeSS or less
How much specialization is over-specialization? It depends. It depends on our need - how much agility do we need? It depends on our capability - how much broad learning provides the right amount of challenge for our people?
LeSS provides a reference point for our consideration, which is for roughly 50 people, we want to strive for one product backlog with multiple feature teams. Feature team means that we do not create separate backlogs for each technical domain/component; while one product backlog means that we do not create separate backlogs for each customer domain.
What if this step is too big for us? Our first step could be to combine backlogs for two technical domains/components, or for two customer domains, therefore, have one less backlog. That is the minimum step we could take.
When we reduce #backlogs, we increase agility. Indeed, #backlogs is the ultimate lever.
Seeing system dynamics in organizational change: 7) incremental structural change
This is the seventh article in the series of seeing system dynamics in organizational change. In the last article, we concluded that incremental structural change was more appropriate for huge organizations. In this article, we shall look at the different approaches for incremental structural change.
There are mainly two different approaches for incremental structural change. For the ease of explaining, I shall refer to the LeSS terms, but the thinking behind goes beyond LeSS and applies to the incremental structural change in general.
The above diagram illustrates these two approaches for a typical telecom product. The product consists of 3 main subsystems - O&M (Operations & Maintenance), CP (Control Plane) and UP (User Plane). In each subsystem, there are several components. Before we start the change, all teams are organized around components and functions. The change vision is that all teams will be cross-functional and cross-component, i.e. all are feature teams. How are we going to make incremental structural change?
- Gradual expanding
This is the approach used with LeSS guide: feature team adoption map. We first expand the scope of component team and move it closer to feature team. For each subsystem, we make structural change to create "feature" teams inside subsystem. The expansion happens in parallel in all subsystems.
- Cutting through
This is the approach used with LeSS guide: one requirement area at a time. We cut through all subsystems and create the first requirement area, with a few real feature teams. In the meantime, the major part of the organization remains with the old structure.
There are similarities and differences between these two approaches.
What's the same
Both are incremental structural change. Thus, both are only the first step towards the change vision. As described in the last article of "the scope of structural change", we limit the change scope to decrease the complexity, but it extends the change period, which increases the complexity. Therefore, it is a balance.
There are a couple of challenges for incremental structural change.
- The initial success is critical, as there involves a reinforcing loop.
R1-loop: Result speaks
Better result, more commitment, more investment, leading to even better result. Note that it works in other direction too. Worse result, less commitment, less investment, leading to even worse result.
This is probably the most fundamental dynamic for any change. We must have the initial success and let the result speak. This applies to both approaches.
2. The change may stall after the initial success, as described in the article of "from change resistance to limits to growth". In order to grow the change, we have to set the next goal immediately after the initial success, until the change vision about organizational structure is fully achieved.
In order to have the initial success, these two approaches make different trade-offs, as summarized in the below table.
Let's elaborate in more details.
We would only have real feature teams with the second approach. The change there is more disruptive, as it cuts through the whole organization. However, it does not affect everybody immediately, instead, the initial change is based on volunteering.
The second approach also leads to parallel organizations, in which one requirement area works in the new mode, while the rest of the organization remains in the old mode. This increases the complexity for change management.
- Customer value
Individual teams in the second approach would deliver real customer value in every sprint, while inside-subsystem "feature" teams still need to coordinate and integrate their work together for customer value delivery. In essence, inside-subsystem "feature" teams are still component teams, thus, they suffer from the same problems as component team, but to a lesser extent.
Learning from a component to a subsystem is more gradual in the first approach, while broad learning is usually required immediately in the second approach. The broad learning could mean a big challenge if team members have narrowly focused on small components in the past.
In summary, both approaches are incremental, thus share the same basic reasoning and dynamic. However, they make different trade-offs for the initial success, thus take different first step.
Seeing system dynamics in organizational change: 6) the scope of structural change
This is the sixth article in the series of seeing system dynamics in organizational change. We shall examine the topic of structural change in this and next articles. We first look at the scope of structural change - how big structural change is appropriate, and what factors and dynamics are involved in the choice.
Structure is a first-order factor
I have referred to Richard Hackman's work on how structure and coaching jointly affect team performance in various articles, e.g. Team-first or Organization-first, Huawei - LeSS without Scrum. I do not repeat his diagram here, but present it as a "limits to growth" dynamic.
R1-loop: Coaching for performance
We improve the coaching effectiveness, which improves organizational performance. Then, we further improve coaching. We expect to create a virtuous cycle.
B1-loop: Structure limits performance
The current structure becomes a limit, as it is inconsistent with the goal. Once the organizational performance is high, the structural change is small. This keeps the structural consistency low, which eventually limits the growth of the organizational performance.
The leverage in "limits to growth" system dynamic is to break the balancing loop, preferably in early time. This means to work on the structural change from early on.
Then, how big structural change is appropriate?
The scope of structural change
Let's first understand the scope of structural change and look at it as a continuum.
- No structural change. In traditional project setting, the group is formed virtually and temporarily. There is essentially no structural change.
- Structural change for one team. This one team is formed permanently, and the reporting line is changed accordingly; while the other teams remain in the old structure. There exist parallel organizations - one part in old structure and the other part in new structure.
- Structural change for all teams. All teams are formed at once, and the whole organization is in new structure.
Once the organization is huge, consisting of many teams in many areas, we may take intermediate step and change the structure for multiple teams - more than one team but fewer than all teams. This could mean structural change for (3a) all teams in one area, or (3b) one team in all areas. We could still change all teams in all areas at once, as shown in (4).
In summary, we could define the scope of structural change as a variable, from (1) smallest to (4) biggest.
- No structural change
- Structural change for one team
- Structural change for multiple teams
- Structural change for all teams
Structural consistency vs. stability
Suppose that the current structure is not consistent with our change goal, we need to increase the consistency in order to succeed the change.
B1-loop: Structural change for consistency
As structure limits organizational performance, we make more structural change, which brings the structure more consistent with the goal. As a result, the organizational performance improves.
B2-loop: Structural change breaks stability
The more structural change, the less structural stability, the more resistance to reduce the structural change.
This is particularly true when the structural change involves the dissolution of existing roles. It poses a threat to the psychological safety. This is why it is so important to ensure job safety but not role safety, as described in the article of "job safety but not role safety".
The structural consistency is the system goal here, while the structural stability is the secondary concern. We make structural change to optimize for the consistency, while address the stability concern in other ways.
Structural change scope vs. period
The scope of structural change affects change period too, i.e. how long the whole change will take. Think about a 20-team organization. If you make structural change for one team at a time, the scope of each change is small; but the change period is long. If you make structural change for all teams at once, the scope is big; but the period is short.
B3-loop: Small change scope to reduce risk
When we perceive the high change risk, our anxiety increases. This leads us to make smaller structural change. Smaller change scope is less complex, thus, its risk becomes lower.
R2-loop: The complexity from long change period
While making smaller structural change, the change period becomes longer. The long change period increases the complexity, thus, its risk becomes higher.
Why does the long change period bring in the additional complexity? A couple of main reasons:
- It requires strong discipline of the organization to get through the long change period, without losing the focus. There will be more crises in the longer period, which triggers our short-term thinking to shift the burden, as described in the article of "from survival need to shifting the burden".
- The parallel organizations are challenging to work with, as different parts of the organization are not consistent with each other, which easily causes confusion. The longer it is kept as parallel organizations, the more pains it has to go through.
Of course, the complexity from the change scope is also valid. It is indeed more risky to change a bigger part of the organization at one time. We need to balance between change scope and change period.
LeSS does not suggest to start from one-team change, but make the structural change at once for 2-"8" teams. However, LeSS Huge suggests to take incremental approach for "8"+ teams. That is the choice of LeSS regarding how big structural change you make at one time.
In the next article, we are going to dive deep in how to make incremental structural changes.
Seeing system dynamics in organizational change: 5) job safety but not role safety
This is the fifth article in the series of seeing system dynamics in organizational change. In the previous article, we concluded that the best time to de-scale was when the organization is still small and has few roles. In this article, we take up the challenge of reducing special roles, notably managers and specialists, when they are already in place.
No role safety
We reduce the special roles to have more responsible teams, which increase the organizational adaptiveness. However, it creates the discomfort among those special roles. All kinds of concerns are raised to resist the change. As those concerns are often valid, the special roles remain and change stalls.
B1-loop: Reduce special roles to increase adaptiveness
To fill in the adaptiveness gap, we apply the de-scaling force, thus, reduce the number of special roles. This increases team self-organization, then improves the adaptiveness until the adaptiveness goal is achieved.
B2-loop: Increase special roles to reduce discomfort
Reducing the number of special roles causes discomfort, thus increases resistance, which keeps up those special roles.
We should ask what our system optimizing goal is. If it is for the adaptiveness but we address the discomfort at the expense of it, we lose the plot, as described in the article of "local optimization and system optimizing goal". The discomfort is the secondary concern, and it should be addressed in other ways.
In LeSS, there is a guide called "Job safety but not role safety". Managers and specialists should not have role safety, and we should not keep those special roles simply for them to feel safe.
More than ten years ago, while I was working in Nokia Networks, the organization experienced a major redesign. As a result, the PMO was dissolved. It was clear that the project manager role would be gone. I was one of the project managers, and ready to leave the organization. However, even though there was no role safety, there was job safety. The organization tried the best in helping the people adapt. Luckily - one of my life-changing moments in retrospect - I changed my role and stayed in the new organization.
Inevitably, some people would choose to exit, while we should focus on the people who choose to stay and take up the change, and help them get through difficulty.
Survival anxiety and learning anxiety
Edgar Schein in his classical book "The corporate culture survival guide" introduced two concepts - survival anxiety and learning anxiety. They are two different types of discomforts.
Survival anxiety is the discomfort that "something bad may happen to you if you don't respond in some way". It creates motivation to change and acts as driving force for the change.
Learning anxiety is the discomfort that "the new behavior that may be required of you may be difficult to learn, and the new beliefs or values that are implied may be difficult to accept". It creates resistance to change and acts as restraining force against the change.
R1-loop: Survival anxiety creates motivation to change
Reducing the number of special roles increases survival anxiety, which provides the motivation to learn, thus, increases the learning. Then, the number of special roles could be reduced further.
B3-loop: Learning anxiety creates resistance to change
However, reducing the number of special roles increases learning anxiety too, which raises the fear, thus, increases the resistance. Then, the resistance keeps up those special roles.
B4-loop: Survival anxiety creates resistance to change
Even though survival anxiety increases the motivation for change, it raises the fear, thus, increases the resistance too. Then, the resistance keeps up those special roles.
The above dynamic is also reflected by two principles about survival anxiety and learning anxiety.
- Principle one: survival anxiety must be greater than learning anxiety
- Principle two: learning anxiety must be reduced rather than increasing survival anxiety
The real leverage is to reduce the learning anxiety by providing psychological safety, of which the two most important aspects are:
- job safety, so that the people have time and space to learn and adapt;
- learning support, so that the people learn and adapt effectively.
Respect for people
In summary, while we have to remove some special roles, we shall do it in a respectful way.
1. Job safety but not role safety. It is more respectful to clearly and firmly communicate the change than to blur the message.
2. Acknowledge that some people will not take up the change but exit. Be respectful for their decision.
3. Provide strong support for the people who decide to stay and take up the change, and help them learn and adapt in all ways.
Seeing system dynamics in organizational change: 4) the best time to de-scale
This is the fourth article in the series of seeing system dynamics in organizational change. In this and next articles, we are going to look at one specific change in the large-scale product development organization: de-scale to scale. This means to simplify the organization to achieve agility, and this is the essence of LeSS too. One aspect is having fewer roles, as more roles lead to less responsible teams.
However, increasing number of roles is a downward spiral when an organization scales up. Among them, the major roles are managers and specialists. We will look at them separately.
More and more managers
The bee watchers in Dr. Seuss's book "Did I Ever Tell You How Lucky You Are?" are the best manifestation for more and more managers. They could indeed keep increasing forever.
This self-reinforcing nature is shown in the below dynamic.
B1-loop: Increase management control for better performance
When seeing a performance gap, we increase the number of managers to have more control, then, the actual performance goes up and the gap is reduced.
R1-loop: Management control decreases motivation thus performance
However, when we increase the management control, the intrinsic motivation from the people doing the real work decreases over time, thus, the actual performance goes down. In response to that, we have more managers and more control.
B1/R1-loops create the "fixes that backfire" system archetype. We are in the downward spiral of having more managers.
When organization scales up, it is even more natural to have more managers. Let's see the below dynamic.
B2-loop: Increase managers to reduce management load
When organization scales up, every manager has more people. The resulting higher management load decreases the actual performance. In response to that, we increase the number of managers, then, we have fewer people for one manager. This reduces the management load, then the actual performance goes up and the gap is reduced.
R2-loop: Managers create silos
When we have more managers, the silo effect gets stronger over time, which increases the management load. Then, the actual performance goes down. In response to that, we have more managers. This becomes self-reinforcing.
R3-loop: Managers hire people
When we have more managers, they tend to hire more people, so that the organization grows over time. Now we have more people for one manager, thus higher management load. Actual performance goes down, which calls for more managers. This becomes self-reinforcing too.
Both B2/R2-loops and B2/R3-loops create the "fixes that backfire" system archetype. We are in the downward spiral of having more people and more managers.
More and more specialists
When organization scales up, we have more specialists too. Let's see the below dynamic.
B3-loop: Split into many specialities to reduce required capability
When seeing a capability gap, we increase the number of specialities, leading to more specialists. This reduces the required capability, then the capability gap too.
B4-loop: Increase learning to improve actual capability
When seeing a capability gap, we increase the learning, thus our actual capability improves over time, leading to the reduced capability gap.
B3/B4-loops create the "eroding goals" system archetype. As there is more delay in B4-loop, B3-loop becomes dominant. We get more specialties and more specialists. See more from Over-specialization and waste of potential.
R4-loop: Specialists create people gap
When the specialists gotta work in their specialities, the varying requirements create people gap in different specialities over time. The people gap triggers the hiring or moving of the people into the organization, thus, growing the organization further. The bigger organization, the more specialities and the more specialists. This becomes self-reinforcing. See more from Why product development group ever grows.
We are in the downward spiral of having more people and more specialists.
The alternative path
De-scaling is to have fewer roles - fewer managers and fewer specialists. How is it possible to not have more managers and more specialists when we scale up the organization? Is there an alternative path?
Instead of having more managers, we:
- design for self-organizing feature teams, so that teams take more responsibility in delivering the end-to-end customer value, and there is less load for managers;
- increase management capability in teaching and coaching.
Instead of having more specialists, we:
- design for generic product developers with multi-specialities, so that people adapt to varying requirements, and there is less people gap for the whole organization;
- increase the effectiveness of cross-learning.
The downward spiral is one path, while de-scaling to scale is the other path. When is the best time to take the path of de-scaling? A client once asked me to help scale up their organization, so as to keep its agility. At the time, they were still small - around 20 people for product development, but they planned to scale up to 50-100 people. They were at the crossroads, and it was the best time for the change.
Yes! The best time to de-scale is when we are still in small scale and have few roles.
If we are already in large scale and have many roles, we shall face the bigger challenge to deal with existing roles, notably managers and specialists. That's the topic for next article.
Seeing system dynamics in organizational change: 3) from survival need to shifting the burden
This is the third article in the series of seeing system dynamics in organizational change. Even though we have agreed on the change vision and is progressing during the norm, we lose the plot when crisis comes.
During the norm
There is always a gap between our change vision and the reality, which is expected.
For example, we envision feature team who would:
- clarify requirements directly with users and stakeholders
- self-organize to coordinate directly with other teams
- develop the feature across components
However, the reality is:
- the quality and efficiency of clarification done by feature team is low
- the quality and efficiency of coordination done by feature team is low
- the quality and efficiency of some component work done by feature team is low
The suggested long-term solutions are:
- build team's capability in clarification via coaching by PO and SM (B2-loop)
- build team's capability in coordination via coaching by SM (B4-loop)
- build team's capability in some component work via coaching by traveller (B6-loop)
Note: traveller is arranged to help feature team increase the knowledge on certain components.
During the norm, we make progress, but it is still not enough to fill in the gap. Then, we hit the crisis.
During the crisis
During the crisis, our survival need increases. We need quick fix, thus we:
- reintroduce an analyst role, in the name of team PO, feature owner, etc. Essentially the old business analyst role comes back. (B1-loop)
- reintroduce a coordinator role, in the name of feature manager, feature coordinator, etc. Essentially the old project manager role comes back. (B3-loop)
- redefine a traveler role, so that the traveller would simply do the component work. Essentially the dynamic resource allocation in traditional project management comes back. (B5-loop)
If only they were temporary solutions!
Unfortunately, over time, we get addicted to:
- external analyst (R1-loop)
- external coordinator (R2-loop)
- external traveller (R3-loop)
We see the same "shifting the burden" archetype in all of those.
Therefore, the change vision is lost:
- team never becomes cross-functional
- team never becomes self-organizing
- team never becomes cross-component
For "shifting the burden", the leverage lies in two aspects.
- During the norm, we shall increase the effectiveness of the long-term solution, i.e. build team's capability via teaching and coaching. As it is long-term solution, we often lose the urgency and focus. We may break the long-term goal into sub-goals, and set time table to achieve those sub-goals.
- During the crisis, we shall first challenge ourselves - is it really a live-or-die situation? Even if the answer is yes, we make it clear that only do the quick fix to buy time. In order to avoid being addicted, we may put "temporary" in the name of the role, and set specific time limit for the role to expire.
Watch out on how the survival need fails our change efforts!
Seeing system dynamics in organizational change: 2) local optimization and system optimizing goal
This is the second article in the series of seeing system dynamics in organizational change. We shall learn where the local optimization comes from, and how important it is to define a clear system optimizing goal and use that to guide the change.
"It is more cost-efficient to test many requirements at once." This is a typical local optimization. Why do we do this?
B1-loop: Test many requirements at once to save cost
Once there is cost pressure, we increase the number of requirements in one test run, so as to reduce testing cost. Then, cost pressure is relieved.
We do this because the fixed cost of one test run is high, e.g. it takes much effort to set up the test environment. So, we do not make local optimization on purpose, but just try to solve a problem.
Why is it a local optimization? Let's zoom out.
In the upper left side, it is the original B1-loop. Now, we pull more variables into the picture. When we increase the number of requirements in one test run, we increase the waiting time. On one hand, this directly increases cycle time. On the other hand, this delays the feedback, and causes more rework. The rework increases development cost (here we apply the traditional distinction between development and testing). The total cost is the sum of testing cost and development cost, thus, it may increase too. Meanwhile, the rework also increases cycle time.
In summary, if we look at the "global" effect from increasing the number of requirements in one test run, while it reduces testing cost, it increases development cost, and possibly total cost as well; and it increases cycle time.
There are actually two different kinds of local optimizations here.
- Reducing testing cost may increase total cost. This reflects that "optimizing the parts does not optimize the whole".
- Reducing cost may increase cycle time. This begs the question - what do we optimize for as a whole? I.e. what is our system optimizing goal?
System optimizing goal
If we reduce cost but increase cycle time, is it a local optimization? We could not really answer it, before we are clear about our system optimizing goal. If our goal is cost efficiency, it may be a global optimization; but if our goal is cycle time, it is clearly a local optimization.
System optimizing goal should be defined in our change vision, otherwise, we do not have solid foundation to guide the change. One of the common change efforts these days is the agile movement, what does it optimize for? It is for agility and adaptiveness, as well as maximizing customer value and reducing cycle time; but not for throughput, resource utilization, compliance, cost efficiency, etc. If the goal is not clearly set, our change effort is doomed, as local optimization would be "natural".
Even though we set cycle time as our system optimizing goal, some people may still have the cost concern. They say: "Yes, cycle time is important, but we also need to consider cost. It is simply too costly to test one requirement at a time, thus, we have to stick with the current practice of testing many requirements at once." Other people nod and the group dismiss. Craig Larman calls this "losing the plot".
In the organizational change, we need to make clear distinction between system optimizing goal and secondary concerns. We shall not solve secondary concerns at the expense of system optimizing goal. Secondary concerns should be addressed in other ways.
In this case, it means that we should break the B1-loop, while introducing an alternative B2-loop to solve the cost concern.
B2-loop: Reduce the fixed cost in one test run
Once there is cost pressure, we increases the effort on automating test setup, which reduces the fixed cost in one test run, thus testing cost. Then, cost pressure is relieved.
In summary, it is important to set clear system optimizing goal for our change, which helps discern all sorts of local optimizations. Then, we address secondary concerns in ways that do no harm to our system optimizing goal.
Seeing system dynamics in organizational change: 1) from change resistance to limits to growth
I have written a series of blogs focusing on seeing system dynamics in organizational design. Now, i'd like to start a new series, focusing on organizational change.
In this first one, let's understand three common problems in organizational changes:
- change stalls after it is initiated, due to change resistance;
- change stalls after it is "done", due to goal seeking behavior;
- change stalls after it grows for a while, due to limits to growth.
Why is change resisted? A basic balancing loop is at work.
B1-loop: Change is resisted to keep status quo
Once we increase change effort, the actual increases, moving away from the goal. This increases the gap, thus, another "change" effort starts, which brings the actual back to the goal (as shown in the small arrow line at the right hand), then gap is reduced.
The goal is the status quo, and the "change" effort is change resistance. What is called change resistance is simply a force to bring the system into the stable state. Notice that there are two change efforts in the diagram. Change effort moves the actual away from the goal, while "Change" effort moves the actual back to the goal. From system perspective, they are both change forces, and neither good nor bad.
Instead of exerting more change effort, which invokes more "change" effort (i.e. change resistance), one leverage is to elevate the goal. As will be discussed in next sections, the change resistance disappears when the goal is kept above the actual continuously. This explains why many change attempts failed due to change resistance. Without the common change goal, people in the organization would naturally try to keep the status quo.
Once the goal we seek is higher than our status quo, the dynamic changes.
B2-loop: Change is done to achieve the goal
The goal increases the gap. Change effort starts to increase the actual, which brings it towards the goal (as shown in the small arrow line at the right hand), then gap is reduced.
This balancing loop actually is no different than the B1-loop, and they both seek goal. However, as the goal in B1-loop is the status quo, thus, we see the resistance to change; while as the goal in B2-loop is the higher state than the status quo, thus, we see the support to change, till the point that the goal is achieved.
After the goal is achieved, the change is done. The goal state becomes the new status quo. How could we continue the change towards even better state? One leverage is again to elevate the goal.
Grow the change
After the original goal is achieved, we elevate the goal again to grow the change.
R1-loop: Elevate the goal to grow the change
Once the actual increases to reach the goal through B2-loop (as shown in the first small arrow line at the right hand); we elevate the goal. Now, the B2-loop is at work again, until the new goal is reached (as shown in the second small arrow line at the right hand), we elevate the goal again. This is the essential continuous improvement.
Ideally, we would grow the change indefinitely. However, the change still stalls after a while, as there are limits to growth.
Limits to growth
In order to change the actual, it requires not only the effort, but also the capability. Capability here refers to all kinds such as organizational, technical, collaboration, and etc.
B3-loop: Capability shortage to limit the change growth
Once the goal is elevated, the required capability increases. While the available capability is the constraint, it leads to the increasing capability shortage, which decreases the actual.
R1-loop and B3-loop create the typical "limits to growth" system archetype. In order to keep growing the change, one leverage is to build the capability earlier, as it will take time. Various constraints will be exposed along the way, but in the context of product development organizational change, some are well known. One of them is the technical weakness unfortunately seen in many development organizations. This is why for example in LeSS, it is recommended to start technical coaching for a few months before doing organizational redesign. This is to remove the constraint before we hit it.
In summary, in order to grow the change forever (i.e. continuous improvement), the main leverages are as following:
- create the common goal to be higher than status quo, in order to avoid the change resistance
- elevate the goal to grow the change, in order to avoid the change being stalled after it is "done"
- remove the constraints earlier, in order to avoid the change being stalled when hitting the limits
Zoom out and see the big picture of Scrum roles
Zooming out and seeing the big picture is a form of systems thinking, and we see how it helps to understand Scrum roles.
Distributed project management
"Distributed project management" is a very powerful exercise regarding Scrum roles. We start to write down all project management tasks in post-it notes, then, group them based on which Scrum role does it. The below is the typical outcome.
It shows that project management is distributed among Scrum roles, without the role of project manager. The key points for each role in relation to project management are as following.
- Product Owner: manage the release, in terms of items, sprints, and teams
- Team: manage the sprint, in terms of items/tasks, days and team members
- ScrumMaster: develop the team so that members would work together to deliver the product
- Others (undefined in Scrum): form the project team, which is done very differently after shifting from project mode to product mode with Scrum
Often, people would draw another couple of conclusions:
- ScrumMaster does not have much work to do
- Product Owner is the project manager
This is a common manifestation of fast thinking. We started from project management tasks in this exercise. If you reasoned well with slow thinking, you would notice that this only touched the project management work.
The more solid conclusion would respectively be:
- ScrumMaster does not have much project management work
- Product Owner does some project management work
And we still need to see the bigger picture, beyond the project management work.
One important aspect of systems thinking is seeing the big picture. The wonderful children book "Zoom" illustrates the approach of zooming out and seeing the ever bigger pictures, with one sample shown in the below.
Similarly, we zoom out and see the bigger picture of Scrum roles.
Now, we go beyond the project management work, and the bigger picture shows the below.
- Product Owner: the main job for PO is product discovery, i.e. find the valuable work, see 80% product discovery and 20% project management
- Team: the main job for team is product delivery, with self-management, i.e. manage its progress and process
- ScrumMaster: focus on coaching for self-organization and continuous improvement, rather than short-term delivery.
Click "Zoom out":)
My view of LeSS
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 the large-scale product development. We could make any choice if we were not clear about the optimizing goal. The choices made by LeSS are optimized for the agility and adaptiveness.
Among others, two choices stand out.
- One Product Owner and one Product Backlog, rather than many Product Owners and many Product Backlogs (team PO as anti-pattern; 1 vs. n product owners; 1 vs. n product backlogs)
- Feature team, rather than component team and feature group (component team vs. feature team; feature team vs. feature group)
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 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 causes behind it? What are consequences from it? Is it consistent to your system optimizing goal?
I am often asked to compare LeSS with SAFe and others. I have no answer, but would like to offer doing an exercise of system modeling on the different choices they make. We evaluate those by applying systems thinking.
When team gets big, we split it into two. How? most 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 them 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.
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 learned 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.