Systems Thinking Primer
I have written a series of articles that apply systems thinking to explore various organizational design options and change strategies. The goal of this primer is to prepare you for understanding and practicing systems thinking. Besides describing basic concepts, we shall use examples in product development organization to help see the significance of systems thinking in the context of large-scale product development organization. Meanwhile I shall share insights through my own practicing.
1. Systems Thinking
Why do we choose to apply systems thinking to explore and guide organizational design and change? Peter Senge in his book "The Fifth Discipline: The Art & Practice of The Learning Organization" makes the distinction between detail complexity and dynamic complexity. Detail complexity is characterized as having many variables, while dynamic complexity is characterized as the subtlety between cause and effect. Cause and effect may not happen in the same time and space, which brings high dynamic complexity. Systems thinking can help us better understand such problems thus enable more effective intervention. The design and change of large-scale product development organizations not only have detail complexity, but also dynamic complexity. Thus, systems thinking is a good fit there.
Many definitions of systems thinking can be found by various authors. The concepts and tools I use in my articles are borrowed from system dynamics, founded by professor Jay Forrester from MIT. There are four main tools: Causal Loop Digram (CLD), Behavior over Time Diagram (BoT), Stock & Flow Diagram (SFD) and Computer Simulation. Many insights from systems thinking are counter-intuitive. Therefore, quantitative analysis based on computer simulation enables us to generate new insights and further change our mental models. However, considering that 1) approaches to make quantitative analysis through mathematical modeling for the topic of organizational design and change are not mature, and 2) qualitative analysis and critical thinking based on CLD are already helpful in enabling us to change our mental models (i.e. shift the thinking of cause and effect from linear to loop-based), I shall use CLD as the main tool for system modeling and analysis in this primer.
2. Causal Loop Diagram
You can find introductions to CLD in any general systems thinking book, e.g. "Seeing the Forest for the Trees: A Manager's Guide to Applying Systems Thinking" or "Systems Thinking Basics: From Concepts to Causal Loops". Its basic elements include: variable, link and loop. Let's introduce them one by one.
Variable is a factor in the system structure we are trying to model. Its value changes over time. In product development organization, common variables include: number of people, amount of requirements, cycle time for delivery, velocity, flexibility, quality, value, morale, satisfaction, etc.
When defining variables, it is worth mentioning the following:
- Variable is noun. For example, "speed up" is not a variable, and the related variable could be "speed", which may increase or decrease.
- Variable could be tangible or intangible. For example, the variable "number of people" is tangible, while the variable "morale" is intangible.
- Variable could be decomposed into more granular ones. For example, the variable "amount of requirements" could be further defined into "number of requirements" and "size of requirements".
Link is the causal link between variables. The link from variable A to variable B means, assuming all other factors being equal, a change in A will lead to a change in B. According to the relative change direction, link can have two types of polarity. It could be positive, noted as "+"; or it could be negative, noted as "-". There may also be a delay in associated change, noted as "||".
Let me illustrate with two examples.
1. The link between "amount of requirements" and "number of people"
Does bigger "amount of requirements" cause higher or lower "number of people"? or no relation at all (i.e. no link between them)?
One explanation is, the bigger the "amount of requirements", the higher the "number of people", because we would need to hire more people to work on requirements. Thus a positive link forms between the "amount of requirements" and the "number of people".
However, with this logic we find that "number of people" as a variable is not very accurate. It could mean "number of required people" or "number of available people". We can make a distinction between them in the below diagram to show the underlying causation more clearly. Note that "hiring" itself is not a variable, but "hiring intensity" could be more appropriate, as it may increase or decrease.
Bigger "amount of requirements" leads to higher "number of required people" which leads to increase in "hiring intensity" and increase in "number of available people".
Are there any delays in the above three links? The delay itself is a relative concept. There is a continuum between no delay and infinite delay. In qualitative analysis, we make a judgement on how much this delay influences the dynamic and then we decide whether to include it. For example, considering that there is usually a significant delay from increasing "hiring intensity" to having higher "number of available people", we decide to explicitly present the delay in the link.
Bigger "amount of requirements" leads to higher "number of required people" which leads to increase in "hiring intensity" and, after some time, increase in "number of available people".
Besides positive/negative noted as "+"/"-", another common notation for the change direction in a link is same/opposite noted as "s"/"o". I decided to use positive/negative notation for the following reason.
Increasing "hiring intensity" leads to higher "number of available people"; the change is in the same direction. However, does decreasing "hiring intensity" mean lower "number of available people"? As long as we are hiring, the number of available people will in fact never decrease. The two variables don't seem to move in the same direction. Thus, the definition of same/opposite direction can be very confusing. CLD does not distinguish between stocks and flows, while SFD does. What is the exact meaning of positive/negative link polarity? The more accurate statement would be lower "hiring intensity" causes the "number of available people" to become lower than it would be otherwise. Therefore, regardless of the change direction, it is always positive.
2. The link between "amount of overtime" and "output"
Is there any causal link between "amount of overtime" and "output"? Is it positive or negative?
One explanation is, bigger "amount of overtime" leads to bigger "work effort" which leads to more "output". The overall link polarity is positive.
Another explanation is, bigger "amount of overtime" leads to lower "morale" which leads to lower "efficiency" and less "output". There is a negative link between the "amount of overtime" and the "morale", which makes the overall link polarity negative too. In order to judge the overall link polarity, we only need to count the number of negative links in between. If the number is even, the overall polarity is positive; if the number is odd, the overall polarity is negative.
So, there are two links between the "amount of overtime" and the "output", one is positive and another is negative. Whether the total effect is positive or negative has to be decided through quantitative analysis.
Moreover, there is also a delay between the "amount of overtime" and the "morale". It takes a while for overtime to decrease the morale. Bigger "amount of overtime" after some time leads to lower "morale", then lower "efficiency" and less "output". Delay does not change the link polarity, but we shall see its significance later.
Several links can form a loop. If there is a link from A to B, and there are other links via a series of other variables from B to A, a loop forms. There are two types of loops: one is a reinforcing loop, noted as R; and the other is a balancing loop, noted as B.
1. Reinforcing loop (R)
This is a common dynamic around a product. An increase in "value" leads to bigger "sales" which leads to higher "profit" and increased "investment" and an even higher "value". This forms a reinforcing loop.
It is worth noting that I read the above as a virtuous cycle. However, it can also be read in another direction. A decrease in "value" leads to smaller "sales" which leads to lower "profit" and even lower "value". This is also a reinforcing loop, but it is a vicious cycle. So, a reinforcing loop can be both virtuous and vicious.
When we create a loop, naming it is an important thinking step. A loop is only a part of a bigger dynamic. By naming the loop, we are able to explore the overall dynamic at a higher level. Take the example of the reinforcing loop above. We can name it as "value drives product growth".
2. Balancing loop (B)
Continuing from our previous example on "amount of requirements" and "number of available people", we discover that our definition of "amount of requirements" is not accurate either. It could be further defined as three related but different variables: "amount of done requirements", "amount of to-do requirements", and "amount of input requirements". The "amount of to-do requirements" is the difference between the "amount of input requirements" and the "amount of done requirements".
The bigger the "amount of to-do requirements", the higher the "number of required people", the "hiring intensity" also goes up as well as the "number of available people" which leads to bigger "amount of done requirements" and smaller "amount of to-do requirements". This forms a balancing loop. We can name it as "hiring people to get requirements done".
We get familiar with vicious and virtuous cycles through our life experience. It is not so hard to understand reinforcing loops. In contrast, it is harder to understand balancing loops. A characteristic of a balancing loop is goal-seeking. We can define a problem as a gap between a goal and current reality. The gap drives changes in behavior which causes changes in current reality and the gap to be reduced.
The classical example for explaining a balancing loop is the adjustment of water temperature. You have a "target temperature" and an "actual temperature". When there is a gap between them, it drives you to increase the "level of adjustment" leading to an increase in the "actual temperature" and reduction of the "temperature gap". You gradually slow down the adjustment eventually reaching the "target temperature". This becomes the balance state. This is similar to the balancing loop of "hiring people to get requirements done". The "amount of to-do requirements" is the equivalent of the "temperature gap" and hiring corresponds to adjusting water temperature.
Let us look at another example of the balancing loop.
On the left diagram, the bigger the "pressure", the higher the "number of shortcuts" taken, the faster "speed", the smaller "pressure". Shortcuts mean all kinds of approaches to help speed up delivery in the short term through sacrificing quality, e.g. do less testing, copy and paste, ignore error handling, etc. We can name it as "taking shortcuts to speed up". Where is the "temperature gap" here? Pressure! "pressure" is actually caused by the gap between some "target speed" and the "actual speed". Taking shortcuts is equivalent to adjusting water temperature. On the right diagram we illustrate it in the same way as in the example of adjusting water temperature. They are essentially the same diagram.
To detect whether a loop is balancing or reinforcing, beside going through each variable and link, there is a simpler way - count the number of negative links. If it is even, the loop is reinforcing. If it is odd, the loop is balancing. The step of naming the loop serves as a verification. When you find that the name for a reinforcing loop is solving a problem/reaching a goal, or the name of a balancing loop is growing/declining, you should examine the loop again.
3. System Archetype
Multiple loops interact to form certain patterns. In systems thinking, those patterns are called system archetypes. There are roughly a dozen common archetypes, and some of them appear often in my articles. In the following, we shall make a brief introduction by using examples from product development.
Fixes that backfire
"Fixes that backfire" system archetype consists of one balancing loop and one reinforcing loop. The above example is built upon the previous "taking shortcuts to speed up" balancing loop. The higher the "number of shortcuts" taken, after some time, the higher the "number of defects", leading to higher "amount of rework" and slower "speed" which leads to even bigger "pressure". To address the growing pressure we take even more shortcuts. Thus, a reinforcing loop forms. It can be named as "being slowed down by defects". The unintended consequence is the key feature in this archetype. The unintended consequence in this example is the growing number of defects caused by taking shortcuts. Delay plays an important role in this dynamic. It is the delay that makes the unintended consequence surprising.
Shifting the burden
"Shifting the burden" system archetype consists of two balancing loops and one reinforcing loop. If the top-left balancing loop of "taking shortcuts to speed up" is a fix that backfires, is there any alternative balancing loop to help reach the goal? The balancing loop on the bottom-left provides an alternative. When we feel more pressure to speed up, we increase the "intensity of improvement" to improve the speed. Then, the pressure is relieved. There are many possible improvement actions, for example, training and learning to improve skills, strengthening collaboration, removing impediments, etc. It usually takes longer for these actions to become effective than taking shortcuts. However, when shortcuts seem to be working in the short term, it lowers the "motivation of improvement" leading to a decrease of the "intensity of improvement" and slower "speed". We already know that slower "speed" leads to bigger "pressure" and taking more shortcuts. This forms a reinforcing loop, which can be named as "getting addicted to taking shortcuts". The key feature in the "shifting the burden" archetype is the tension between short-term symptomatic solution and long-term fundamental solution. Because of the reinforcing loop, we get addicted to the short-term symptomatic solution.
"Eroding goals" system archetype consists of two balancing loops. We can define any problem as a gap between a goal and the current reality. The gap could be reduced by changing the reality or by changing the goal. This may sound like cheating , but it is not so uncommon, especially when it takes a long time to actually change the reality. The problem in the above diagram is the progress gap between "target progress" and "actual progress". In order to reduce the "progress gap", there are two solutions, i.e. two balancing loops. The upper loop is the solution for lowering the goal; the bigger the "progress gap", the lower the "target progress", the smaller the "progress gap". In fact, this is simply schedule slippage. The lower loop is the solution for changing the current reality; the bigger the "progress gap", the higher the "intensity of 'speed up' actions", the faster the "actual progress", the smaller the "progress gap". The "speed up" action here does not necessarily mean overtime. Although overtime may help to speed things up to some extent, too much of it will make the progress worse. There are many other "speed up" actions, such as improving efficiency, reducing scope, etc., but these actions usually take longer to become effective. It is this delay that makes us shift gradually to the upper loop. Delay becomes a habit. In a way, "Eroding goal" is a special case of "Shifting the burden". In the "Shifting the burden" archetype, the two balancing loops are both changing the current reality; while in the "Eroding goal" archetype, one of them is changing the goal.
Limits to growth
"Limits to growth" system archetype consists of one reinforcing loop and one balancing loop. The above example is built upon the previous "value drives product growth" reinforcing loop. Potential customers mean people who are targeted by our product, but have not yet become actual customers. Therefore, "potential customers" is the difference between "target customers" and "actual customers". Higher "sales" lead to more "actual customers" which lowers the number of "potential customers" leading to smaller "sales". In other words, sales is limited by the number of target customers. This is usually described as market saturation.
Please note that both "Fixes that backfire" and "Limits to growth" archetypes consist of one reinforcing loop and one balancing loop, but their dynamics are completely different. In the "Fixes that backfire" archetype, the balancing loop is the solution, but it brings an unintended consequence, while the reinforcing loop works as a vicious cycle. In the "Limits to growth" archetype, the reinforcing loop works as a virtuous cycle, while the balancing loop limits it. Therefore, we would like to break the balancing loop so that the reinforcing loop would continue to bring benefits.
4. Modeling Approach
In my Systems Thinking writing, I have included various system models. We shall learn two main approaches of system modeling, applied to organizational design and organizational change, respectively. Organizational design is in fact redesign, as the current design exists regardless of whether it was designed consciously or not. We shall use four questions to drive the modeling analysis for the current design and potential alternatives to reveal deeper understanding and insights about different choices for changes. In organizational change, it is critical to strengthen effectively the driving forces and weaken the restraining forces. We shall do the modeling analysis for driving and restraining factors on the basis of "Limits to growth" system archetype to gain insights.
We use the following four questions to model various factors behind different choices:
- What is the intention of the current choice?
- What is the consequence of the current choice?
- Are there any alternatives that would achieve the same intention?
- Why is it hard to implement those alternatives?
Use the example of "development taking shortcuts" below:
- What is the intention of taking shortcuts? What purpose does it try to achieve? What problem does it try to solve? We can model achieving goal or solving problem as a balancing loop. In this case, it is the B1-loop of "taking shortcuts to speed up".
- What is the consequence of taking shortcuts? It is important to expand the time horizon to see if there are any unintended consequences. Taking shortcuts actually creates negative impact on the goal of speeding up in a longer term, which forms the R1-loop of "being slowed down by defects". The B1 and R1 loops together form the "Fixes that backfire" system archetype. It may also influence other goals, for example quality. Supposing that taking shortcuts does make you faster, but decrease your quality, then it becomes a question on which system goal - speed or quality - is more important to you.
- Are there any alternatives to "speed up"? If "speed up" is the intention behind taking shortcuts, can we take other approach to realize this intention? The B2-loop of "improving efficiency to speed up" is such another approach.
- Why is it hard to implement the B2-loop? Why do we keep taking shortcuts? The R2-loop of "getting addicted to taking shortcuts" provides an explanation.
Through these four questions, we have done a sufficiently comprehensive analysis for the dynamics behind taking shortcuts, paving way for further decision making.
We use two other questions to model organizational change.
- What driving forces can we leverage for a certain change?
- What restraining forces do we need to weaken for a certain change?
This is similar to the common force-field analysis. The difference is that we shall leverage potential reinforcing loops and identify the limits associated with balancing loops, while force-field analysis often stops at linear causation.
Take the example of adopting some practice:
- What would drive the adoption of a practice? Let the team who has adopted it share their experience, communicate with other teams, so as to increase the enthusiasm of other teams. Thus, more teams may start to adopt. There is a reinforcing R1-loop here, which can be named as "sharing to inspire enthusiasm".
- What could restrain the adoption? Team needs coaching while adopting a new practice, but coaching resource may be limited. Thus, we are unable to provide effective coaching for many teams at the same time. There is a balancing B1-loop here, which can be named as "being limited by coaching resource".
The R1 and B1 loops form the "Limits to growth" system archetype. Here, we have only identified one reinforcing loop and one balancing loop. In reality there would be more reinforcing loops to drive the change, as well as more balancing loops to restrain the change.
I hope that this primer could help you to learn and practice systems thinking. Systems thinking is a specialized subject. There are many books available for reference and study. In this primer, I try to use examples in product development to describe some basic concepts that we can apply in many similar situations.
A system, by definition, involves multiple factors interacting with each other. One challenge in applying systems thinking is where to start. It doesn't need to be complicated. Start with the problem, identify some factors (variables) and relationships (links) between them. Look for loops. Loops are key. Multiple loops form various system archetypes. Here I shared two approaches that could be applied for organizational design and organizational change respectively.
P.S. Many thanks to my colleagues - Ivan and Steven - for their great improvement suggestions!
LeSS before Scrum - adopting Scrum in large-scale organization
This is a session I planned to give in LeSS meetup in Apri, Agile 2020 in July, LeSS 2020 in Sept., but could not make any of them due to the COVID-19. Next attempt will be LeSS meetup in Sept. Thought that the ideas might be useful, thus, put the outline in this blog.
LeSS before Scrum - adopting Scrum in large-scale organization
Instead of starting from one-team Scrum then spreading, we explore a different organization-first approach to adopt Scrum in large-scale product development.
First, you will hear an experience of "LeSS without Scrum", i.e. doing LeSS organizational design - feature team and one product backlog - but not yet introducing ScrumMaster, rather keeping Team Leader. It was done due to the organizational constraint, but surprisingly, self-organization emerged out of it, and the team leaders transformed. This experience then inspires more experiments on progressing the role of Team Leader while team matures. What is on earth the role of Team Leader, especially in the context of self-directed work team? How does it differ from ScrumMaster?
Then, we shall present an emergent approach of adopting Scrum in large-scale organization, which is developed based on those experience and further experiments. Start from the whole product; next create feature teams; then increase the degree of self-organization for those feature teams, as well as have more feature teams share the same product backlog. Eventually, Scrum emerges on one product with multiple teams, and further towards a learning organization.
- Understand why organization-first approach rather than team-first approach in adopting Scrum in large-scale organization
- Ideas to experiment on adopting Scrum in large-scale organization: feature team with Team Leader; one product backlog shared by multiple feature teams; progressing the role of Team Leader to the role of ScrumMaster
- An evolution path on adopting Scrum in large-scale organization: whole product -> feature team -> one product backlog | self-organizing team -> learning organization
The talk consists five parts.
- Introduction (10 min.)
The essence of Scrum is 1) empirical process control and 2) self-organizing team; while the essence of LeSS is 1) scaling Scrum on one product with multiple teams, and 2) achieving more with LeSS via organizational (re)design. Organizational design is a first-order factor in large-scale organization, and LeSS organizational design enables Scrum.
- LeSS without Scrum (15 min.)
During 2015-2016, I had an experience of adopting LeSS without Scrum - adopting LeSS organizational design without mandating self-organizing team and introducing the role of ScrumMaster, rather keeping the role of Team Leader. I presented the experience report in Agile Conference 2017, and see the details from here. I will recap the main part in this talk.
- Self-directed work team (15 min.)
The above experience made me dig deep into the role of team leader in the context of self-directed work team. See the book "Leading self-directed work teams".
This has shifted my focus in large-scale Scrum adoption, from immediately introducing SM role to developing TL role into working with self-organizing feature team, eventually turning it into a complete coaching role - ScrumMaster.
- LeSS before Scrum (25 min.)
Based on those experiments, we develop an approach of adopting Scrum in large-scale organization.
- "start from the whole product", get the transparency at the product level by creating one product backlog (for transparency, not for adaptiveness yet) and doing (at least) daily product builds
- "next create feature team", create feature teams, and increase the number over time. Feature team is not feature group. Feature team shortens the e2e cycle time, and is enabled by multi-learning on functions and components.
- "then one product backlog", have more feature teams share the same product backlog, ultimately one product backlog for the whole product. One product backlog improves the adaptiveness, and is enabled by multi-learning on customer domains.
- "then increase the degree of self-organization", turn feature team into self-organizing feature team. While team matures, team leader role progresses from trainer & teacher to coach & facilitator, eventually ScrumMaster role
- Conclusion (10 min.)
What is the final step? Towards learning organization. Feature teams and the whole organization practice the five disciplines (personal mastery, shared vision, mental models, team learning and systems thinking), continuously learning and improving.
Manager as Scrum Master
Note: This article was originally published as an experience report in Agile 2011.
Manager as Scrum Master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a management transformation from command and control to leading and coaching. This experience report will explain how one large-scale organization adopted Agile over three years, with the focus on the evolution of Scrum Master and manager role and the way they work together. It describes how the change regarding self-management was introduced and adapted, then how we have tried to sustain the change by creating consistency between the values and principles behind Agile into the organization and the management capability to practice them.
I worked in a product development organization in Nokia Siemens Networks, formerly Nokia Networks, from 2002 to 2010. The organization consists of two sites, one in Hangzhou, China, and the other in Espoo, Finland.
In late 2005, we started Scrum pilots in various projects and teams to get focus and flexibility in our projects. We were running parallel projects and the resulting multi-tasking caused people to lose focus. Because teams were organized around components, not customer deliverables, we had a diluted sense of customer focus. The combination of single functional team and component team structure made adapting to change in a flexible way difficult. Because of all these factors, both upper management and the teams were motivated to try different approaches to development, and the agile nature and simplicity of Scrum made it a natural choice to try. I led one of the first Scrum projects in the organization.
In 2007, after initial success in our pilots, our entire product organization (over 500 people) decided to move to an Agile/Scrum model. I was selected to lead one department with ~100 people in the new Scrum-based organization and join the organizational leadership team. The story is about how we have been inspecting and adapting on Scrum Masters, Line managers and how they work and grow together ever since then.
Many organizations failed to change product management, which is typically a separate organization from R&D. However, in our case, Product management is part of our product organization, with the same boss. We introduced a Product Owner role and created a PO-centered mode of operation. Since traditional project management is distributed among Scrum roles - PO, team and Scrum Master, we eliminated most project managers to avoid the dysfunctions due to overlapping roles. People managers didn't feel threatened with this change, since people management is still essential (if not more so) in an agile organization. Thus, it was relatively easy to get their support. The challenge was getting people managers to understand the deep change needed to transform their role from command and control to leader and coach.
The original department consisted of single-functional component teams, and we reformed them into cross-functional feature teams. There were a few line managers in the department but Scrum Master was a new role. Product Owner was selected for our department. My first task as department manager was to set up teams to enable Scrum development (i.e. cross-functional feature team committing and delivering potentially shippable product increments on sprint basis), and get Scrum Masters to lead and facilitate the team and Scrum implementation. Self-managing is one essential theme in Scrum. I intended to incorporate this principle into the change - could we reform the teams and select Scrum Masters via self-management?
We started by sketching the constraints we faced and decided that we needed an appropriate sized team that was cross-functional and able to deliver customer features. We educated our people in self-organization, and provided opportunities for them to know each other. Our Product Owner also shared the current Product Backlog, which indicated the needed competence from teams. During the planning, one concern was raised, what if it failed to self-organize into teams, how long would we wait for teams to emerge? We decided to timebox the team-forming process and explained this to the potential teams. If teams did not emerge within the timebox, then management would decide the team composition for them.
We invited all the potential team members into a team forming session. Around 80 people were in one big hall room. Flipchart stands were distributed within the room, each of which indicated one team presence. We listed main criteria on the flipchart. After some turbulence, some people started to gather around stands, and others joined to discuss about the criteria. People moved around. Some people who shared good early working experience started to form teams as initial members, and they even added their own criteria to recruit other members, some related to the technical, while others related to the social. The most interesting experience happened in the end. Some "leftover" people finally merged into the last team. I was worried about their future, however, it surprisingly turned out to be one of the best teams later. After one hectic hour, 10 teams formed.
I was thinking of going one step further to ask each team to select their Scrum Master, but did not implement this idea for the following reasons. Line managers were not familiar with Scrum. In order for the change to succeed, they certainly needed to understand Scrum deeply and know how to effectively work in that mode. Practicing as Scrum Master could be good approach to develop that understanding and get them immediately involved in the new mode. Secondly, our people did not yet have the sufficient understanding about what good Scrum Master should be like, and there were few real Scrum Masters in the organization. I was concerned about the quality of self-selected Scrum Masters, thus, decided to recruit Scrum Masters by myself and create a pool of candidate Scrum Masters including all line managers. After the teams formed, the Scrum Masters presented themselves to the teams. The teams and the Scrum Masters mutually agreed for which team the Scrum Master would serve.
One risk to have traditional line managers as Scrum Masters was the tendency of working via authority, rather than influence, by line managers and the perceived authority by team, which may impede the team from self-managing. We instituted a rule that line managers could not be the Scrum Master for the team directly under their line.
Since all line managers including myself were Scrum Masters at the same time, line managers and Scrum Masters, together with Product Owner, worked very closely at both team level and organizational level. The size of this group, less than 10 people, made the efficient work possible. We had grown our capability of leading and facilitating teams through practicing as Scrum Masters and learning from external coaches. Moreover, we had developed deep understanding about organizational impediments to be solved and organizational supports to be established.
Struggling and adaptation
We soon found that line managers struggled with balancing the roles of organizationally-centric role of line manager and the team-centric role of Scrum Master.
During the planning of the transition to Scrum, a hot topic was the role of a line manager in Scrum. The Product Owner decides what, the team decides how, and the Scrum Master supports and enables. In the beginning, some people in the organization were unclear about how the process was supposed to work, and skeptical about the change. Crisis and urgent escalations from customers demanded immediate attention with little room for mistakes; organizational impediments surfaced and demanded management solutions. Making the transition to self-management requires even more management efforts, and more leadership. The dual function of the line manger affected the progress at team level towards well-working self-managing team with continuous improvement, as well as at organization level towards enabling and aligning organizational structure and support.
We moved towards having dedicated Scrum Masters, and let line managers lead organizational change and coach Scrum Masters. Their early experience as Scrum Masters enabled line managers to take on a new role in the Scrum organization that was more outward looking. Line managers became more involved with removing organizational impediments and creating the vision and strategy in organizational evolution. Line managers also transitioned from command and control to coaching Scrum Masters. Some new Scrum Masters were recruited within the organization; others emerged from within teams; others were identified and developed by line managers.
In our organization, line managers had the responsibility of supporting personal development. Once people understood better about Scrum Master role, some of them showed interests of developing into it. In the meantime, line managers were looking for candidates to take over their Scrum Master role. It was a good match. Nevertheless, with the social culture of valuing getting into management position more than continuing to develop into technical experts, we actually encouraged people to stay focused on technical skill development. We made it clear that being Scrum Master is good for learning and growing leadership, but it is neither a position nor related to promotion. In fact, it would affect becoming a technical expert. Line managers paired with the remaining people, who would genuinely like to serve the team and help them become great, as well got the support from other team members. By recommending books and sharing thoughts after reading, coaching and mentoring in the context of the team to which they belonged, letting them facilitate Scrum meetings and giving feedback for improvement, line managers helped them get ready to start. The taking over happened when all parties including team felt comfortable in doing so.
When we had the mixed role of line manager and Scrum Master, we started with a peer group of both line managers and scrum masters. With the evolution towards having more dedicated Scrum Masters, a single group grew above the appropriate size for effective team work. Therefore, we decided to separate them into two groups. One consisted of line managers, whose focus was to specify the ends and create the environment for team to achieve; the other consisted of Scrum Masters (and line managers as optional members) whose focus was the competence development of Scrum Masters.
We made line managers optional in Scrum Master development groups. In addition to keeping the group size small, we thought that the line managers' presence might prevent Scrum Masters from taking the ownership for their own development. We made it clear that it was their platform and line managers would participate based on a pull mode.
We implemented Scrum buddies, pairing a line manager and a Scrum Master, to support coaching and mentoring within the organization. For new Scrum Masters, we also paired them with experienced Scrum Masters, considering that they would learn more from hands-on Scrum Masters, and experienced Scrum Masters would increase coaching and mentoring capability through practicing.
A downside of having two separate groups was the lack of opportunity for Scrum Master to get involved at the organizational level. A good Scrum Master in our organization not only looks at the team, Product owner, and their interactions, but also at the organization. For a Scrum Master's growth, we wanted them to understand the organization. In addition to the line manager's coaching that could be extended beyond the team context, we created workgroups based on organizational tasks, which would not only solve the problem but also grow Scrum Masters. Another downside came from line managers being separated from the teams compared to Scrum Masters, thus, weakening their understanding of the problems teams were facing.
Although we had positioned line manager as organizational centric role and Scrum Master as team centric role, we noticed that the line was sometimes blurred for some Scrum Masters/Line Managers. It made sense to develop the consistency among them for sustainability.
Our organization as well as our department grew. We increased the number of new line managers as well. Besides following the conventional management ratio (one line manager for 2-3 scrum teams), the selection of new line managers provided the opportunity to create sustainability in the change. Those Scrum Masters who had already demonstrated leadership in both team and organization contexts became a good source of candidates.
When they were selected as line managers, they continued to serve one of teams under their direct line as Scrum Master. This supplemented the line management team with good insights from teams. This seems as though we were back where we started, i.e. line managers were Scrum Masters. There were important differences, though. In the beginning of the Scrum transformation, the focus was to implement the change throughout the organization, including creating the vision, communication to get buy-in, removing impediments, etc. At this time, the focus was to sustain the change and ensure that it became part of the organization. The best way to do this is through the people, in particular those who have influence. With great Scrum Masters being promoted to line managers, it created more consistency between values and principles behind Scrum-based organization and management capability to practice them. As teams became more experienced in self-managing, the original challenge of balancing the line manager and Scrum Master roles became less of an issue.
With the growing number, the team of Scrum Masters with the learning focus has evolved into Community of Practice, i.e. Community of Scrum Master. It became less efficient to complete task with big number of people, thus we shifted focus further on growing ourselves into good Scrum Masters via exchanging ideas, sharing experiences, opening perspectives and providing insights. With the new purpose after adaptation, we extended Community of Scrum Master from our department to the whole organization. We set up the mailing group and regular gathering to support the community. We made a few arrangements to cultivate it. A few Scrum Masters and line managers acted as the role model for how to properly behave in the community; we handed out good books and encouraged the sharing after reading and group study; we introduced the internal community to the Scrum China community, thus connecting us to the outside; and so on. Over time, people developed the learning habit and got into self-growing stage. That's where sustainability comes from. Personal continuous improvement from Scrum Masters and line mangers led to the continuous improvement in teams and organization. Moreover, when they started to contribute in wide scope, it created positive reinforcing loop.
The initial drivers for more flexibility and better focus were addressed by creating customer-oriented product backlog and teams accordingly, so that we as organization deliver potentially shippable product increments in every sprint. We experimented how to lead self-managing teams in this context, and discovered the followings.
Successful change needs both vision and down-to-earth. Even though the ultimate state is less management efforts through self-managing, we should not underestimate the management efforts while introducing change; even though we desire for emergent Scrum Master in the long run, we'd better not start with self-selecting Scrum Master; and so on.
Sustainability comes from the consistency between organizational management with servant leadership and the self-managing teams. Although the conventional wisdom assumes a conflict between the focus of the manager on command and control and the Scrum Master on leading and coaching, and may suggest to separate these roles, this is questionable when thinking about creating sustainability. Without changing the organizational management, self-managing teams are more accidental. When managers change, the original conflict disappears.
Finally, sustainability comes from a change in people. Without most of the people making continuous improvement on their own, continuous improvement at team and organizational levels is unlikely.
We love individual responsibility more than we would admit
Once a team responsible for "A" (be it a function, component or customer domain) grows too big, we split it into two teams, responsible for the subsets of "A" (the left side). Why is it so natural to do this, rather than the alternative - we split it into two teams, responsible for "A" together (the right side)?
There are a few responses.
- we don't know why we do this, with the variants of "we have been doing this", "others are doing this", "is there any alternative", and etc.
- we want specialization by letting each team focus on one subset.
- we want clear responsibility by letting each team work on one subset.
I don't know what to do with the 1st response, and I have explored the 2nd response in the series of "Number of backlogs and multi-learning". This article is for the 3rd response.
The iceberg model is a systems thinking tool. It helps progress our thinking from the obvious event to the patterns of behavior, to its supporting structures, and its underlying mental models. The below diagram is from Michael Goodman's original article that introduced the iceberg model. In other places, mental models may also be illustrated as a separate deeper layer.
For the topic of specialization, we explored mainly the structure, but mental models, such as "people can or can't learn", were also implied there.
Now look at the topic of responsibility, is the mental model here that "clear responsibility is necessary"? It is hard to dispute about this. Who wants its opposite - unclear responsibility? However, when two teams are responsible for "A" together, is the responsibility unclear? Not really, it is not unclear, but shared. What is the opposite of shared responsibility? it is individual responsibility. The response is actually that "we want individual responsibility" in disguise. The mental model is really that "individual responsibility is necessary".
Why do we want individual responsibility? Because we assume that shared responsibility means no responsibility. When something goes wrong, shared responsibility makes is difficult to find someone accountable, so as to blame or even fire him. By contrast, individual responsibility makes it more "clear".
However, the sole focus on its responsible part leads to strong local identity, and eventually silo mentality. Many people say that they hate silo, but the love for "clear" responsibility in fact helped create it in the first place. Maybe we don't really hate silo, do we?
From Individual responsibility to Shared responsibility
I purposefully make individual unclear - be it individual person or individual team. The underlying thinking is the same. We need to improve our mental model from "individual responsibility is necessary" to "shared responsibility could work, and even better."
This happens in Scrum adoption. One-team Scrum breaks down individual responsibility on the individual members, and defines shared responsibility on the team instead. The team takes shared responsibility towards its common goal. While individual responsibility makes it easier to hold someone accountable, it doesn't make the group a real team working towards a common goal. Individual responsibility creates silos in the group, and leads to local optimization.
This happens in LeSS adoption too. LeSS - aka multi-team Scrum - breaks down individual responsibility on the individual teams, and defines shared responsibility on the product instead. Multiple teams take shared responsibility towards their common goal. It has the same logic as one-team Scrum. This should not be surprising, as LeSS is Scrum.
The shift in this mental model happens at two levels - one-team (Scrum) and multi-team (LeSS), but they are essentially the same shift.
Espoused theory vs. Theory-in-use
Espoused theory is reflected by what we say; while theory-in-use is reflected by what we do. We realize the gap through the discipline of mental models.
When we let the whole team take shared responsibility in adopting Scrum, that is our espoused theory. When we still define clear responsibility for individual members and hold them accountable for their own parts accordingly, we have a different theory-in-use.
When we have already let individual team take shared responsibility, but fail to take it into the next level, i.e. multiple teams take shared responsibility on one product through shared product backlog and shared product increment, there is still a gap between espoused theory and theory-in-use.
The gap is not necessarily bad. When we realize the gap, we ask ourselves - do we really value the espoused theory? If yes, then the gap represents the tension between reality and our vision, so as to help create the path of least resistance. If no, then the gap is not real. As there is no commitment to the espoused theory, we will only manipulate the gap but fail to achieve our vision.
Reasoning before measuring
I often got this question - what do you measure while adopting Agile?
The conversation usually went like this:
[me] What is about adopting Agile?
[him] ... doing Scrum.
[me] What effect do you expect after adopting Agile?
[him] higher efficiency.
[me] How would you define higher efficiency?
[him] ... finishing more tasks.
[me] Why would adopting Agile lead to higher efficiency?
[him] Agile means higher efficiency, doesn't it?!
The thinking is fuzzy, to say the least. I suggest to focus on reasoning before measuring.
Let's take Specification by Example (SbE) as one example of agile practices. What do you measure while adopting SbE?
Practice and Purpose
Firstly, we learn about SbE by asking 1) what is SbE; and 2) why SbE.
A good source of learning is of course the book "Specification by Example".
1) What is SbE?
"Specification by Example is a set of process patterns that facilitate change in software products to ensure the right product is delivered effectively."
Suppose that among those process patterns, the below two are our main focus of initial adoption. We dive deep on them.
- Specifying collaboratively
"Instead of relying on a single person to get the specifications right in isolation, successful delivery teams collaborate with the business users to specify the solution."
- Illustrating using examples
"The team works with the business users to identify key examples that describe the expected functionality. During this process, developers and testers often suggest additional examples that illustrate edge cases or address areas of the system that are particularly problematic."
2) Why SbE?
There are various benefits from the whole set of SbE process patterns. Let's focus on the benefits from "Specifying collaboratively" and "Illustrating using examples". In other words, let's understand the purposes of these two specific practices.
"Specification by Example helps to improve the quality of software products, significantly reduces rework, and enables teams to better align analysis, development, and testing activities."
There are three areas of benefits.
"Specification by Example improves collaboration between delivery team members, facilitates better engagement with business users, and provides clear objective targets for delivery - leading to big improvement in product quality."
"Specification by Example helps teams establish a collaborative specification process that lowers problems in the middle of an iteration. Most teams have significantly reduced or completely eliminated rework that occurred as a result of misunderstood requirements or neglected customer expectations."
"Specification by Example enables tams to clearly define a target that's universally understood and objectively measured. As a result, many teams find that their analysis, development, and testing activities became better aligned."
The above reasoning could be summarized as below.
Only then do we go to the measuring part.
"Practice has purpose, and we measure both the practice and the purpose." I learned this in one private workshop by David Hussman for Odd-e in 2013 - one of the most memorable experiences with "the dude".
We may come up with the following measures.
- For the practice
- %stories done with SbE (measuring the extent of doing SbE)
- %stories with cross-functional conversations (measuring the extent of specifying collaboratively)
- %stories specified with examples (measuring the extent of illustrating using examples)
- For the purpose
- #defects due to misunderstood/neglected requirements after done (measuring product quality)
- #defects due to misunderstood/neglected requirements during the sprint (measuring rework)
- %stories reaching completion at the end of the sprint (measuring work alignment)
In the "The Book of Why", it introduces causal diagram to move from the correlation to the causation. Causal diagram is similar to causal loop diagram in systems thinking, as they both are based on the causation.
After understanding the practice and the purpose, we reason further for finer-grained causation by expanding with the intermediates. Why doing SbE leading to higher product quality, less rework and better work alignment?
The below causal diagram illustrates one reasoning.
Then, we measure the intermediates, so as to learn the whole chain of causation via validation or invalidation. Note that some variables are harder to measure than others. For example, "amount of rework" is harder to measure than "internal defects". We don't have to measure all the variables. With a few intermediate ones, we build our confidence in this causation.
We may end up with measuring:
- %stories of doing SbE (i.e. specifying collaboratively and illustrating using examples)
- #internal defects during the sprint
- #external defects after done
- %story completion at the end of the sprint
We reason about the cause and effect, before getting to the measure. On the other hand, measuring also improves our reasoning in two senses - 1) thinking about how to measure increases the rigor in the reasoning; 2) the measuring result validates or invalidates the reasoning.
Notice that measuring here is for learning and improving. See my previous blog "Two Guidelines for Metrics" for further reference.
How does LeSS optimize organizational ability to learn?
In my previous series of article "#backlogs and multi-learning", I wrote that "the agility is to deliver highest customer value in uncertain environment. With uncertainty, the ability to deliver is not sufficient, we need the ability to inspect and adapt, in order to deliver highest customer value". Inspect, adapt and deliver is the essential cycle.
To achieve higher agility, we need to optimize for inspectability, adaptability and deliverability. LeSS optimizes adaptability via one product backlog; LeSS optimizes deliverability in terms of end-to-end cycle time via feature team; then, how does LeSS optimize inspectability, i.e. organizational ability to learn?
I have been pondering on this question for a while. In the "fifth discipline" book, there are three disciplines closely related to learning - team learning, mental model and systems thinking. I try to look for insights from them.
Scrum/LeSS has built-in events for product learning and process learning in the sprint cycle. Therefore, let's look at product learning and process learning separately.
The most related event to product learning is sprint review. In Scrum, during sprint review, team, PO and stakeholders including users and customers together inspect the current product increment and explore the ideas for improving the product further. In LeSS, with the whole-product focus, there is one sprint review for all teams. Review bazaar is the recommended practice for the joint sprint review.
The sprint review institutionalizes the discipline of team learning - for product learning. Furthermore, in order to deepen the learning, we also need the other two disciplines - mental model and systems thinking.
Lean startup popularizes the concept of validated learning. First make hypothesis, then design experiment to test core assumptions, then learn from the validation or invalidation. This reflects the discipline of mental model. We make our mental models explicit while making hypothesis, so as to examine and improve them both before and after running the experiments.
Impact mapping shows the logic connection between product goal and features. It explicitly asks to expand the view - who else and how else would impact the goal? This reflects the discipline of systems thinking - in the space dimension. Unfortunately, impact mapping does not highlight the time dimension, i.e. short-term vs. long-term impact.
Business seeks for growth and product needs growth engine. This is the reinforcing loop. The growth is inevitably limited by certain factors. This is the "limits to growth" system archetype. I could see the merits in applying systems thinking in the product domain, but I have rarely seen its comprehensive application - through the explicit use of systems thinking tools such as behavior-over-time, causal-loop diagram, stock&flow diagram, computer simulation - in the field. It is worth experimenting to leverage its potential.
The most related event to process learning is sprint retrospective. In Scrum, during sprint retrospective, team and PO reflect on way of working and strive for improvement. In LeSS, besides team retrospective (i.e. team does the sprint retrospective on their own), team representatives, PO, SMs and managers will have an additional overall retrospective, which has the focus on improving systems.
The sprint retrospective - both team retrospective and overall retrospective - institutionalizes the discipline of team learning - for process learning. Same as in product learning, in order to deepen the learning, we also need the other two disciplines - mental model and systems thinking.
There is a LeSS guide called "improving the system". It explicitly recommends doing systems modeling to understand the system and have a conversation to reach shared understanding. As overall retrospective has the systemic focus, applying systems thinking there is a natural fit.
In fact, every improvement action is an experiment. We first model to make our logic behind the experiment explicit for critical thinking. While modeling, the whole team practices "balancing advocacy and inquiry", and exposes different mental models. We examine those underlying assumptions via "the ladder of inference", and improve them via reflection. Then, we return to our model and learn more after running the experiment. This is the combination of systems thinking, mental model and team learning.
I find that there are many similarities in product and process learning, when they are elevated into higher abstract level.
Every feature is an experiment; every improvement action is an experiment. Therefore, we make hypothesis (i.e. make the logic explicit) for critical thinking; we balance advocacy and inquiry with the whole team; we examine mental models and reflect with actual result to improve them.
In short, we aim for double-loop learning, rather than single-loop learning, for both product and process, via practicing systems thinking, mental model and team learning.
LeSS before Scrum?
The discussion in this article assumes that we apply Scrum in large-scale (i.e. multi-team) product development, which is probably 90% of cases.
Scrum implies the change in organization design. The star model by Jay Galbraith defines five aspects of organization design.
Let's put Scrum in the context of organization design.
- In "strategy", Scrum is designed to achieve speed and flexibility.
- In "structure", cross-functional team able to deliver customer value from end to end is the basic organization unit.
- In "processes", value is delivered in sprints, which defines the planning, review and retrospective cycle.
- In "rewards", team is jointly accountable for the result.
- In "people", team members learn to become multi-specialists.
While the change may be trivial in one-team organization, it is significant in large-scale organization.
When there is lack of proper organization design, Scrum adoption falters. Richard Hackman in his classical book "Leading Teams" showed how team design and coaching jointly affected team performance.
When team is poorly designed, the coaching only has limited effect. On the other hand, when team is well designed, its performance would not be too bad, even with ineffective coaching. This provides room to gradually improve coaching effectiveness.
LeSS provides the guide on the necessary organization design to enable Scrum in large-scale organization. LeSS is the Scrum enabler. Therefore, first adopt LeSS to design the organization, then coaching for those well-designed teams. This is the organization-first approach.
Even LeSS without Scrum provides benefit, actually more than Scrum without LeSS, in large-scale organization. See more insights from LeSS without Scrum experience report.
Therefore, here is an experiment for Scrum/LeSS adoption: LeSS before Scrum (rather than first Scrum, then LeSS).
CSM is probably the most popular Scrum course, and many people learn about Scrum from it. The CSM focuses on one-team context, and treats scaling as more advanced topic. This leads to various educational paths.
Before Scrum Alliance introduced A-CSM, I had my own version of Advanced SM course. It consisted of two days, day one on organization design and day two on coaching. The course design was targeted for large-scale context, and built on Richard Hackman's work - team design and coaching jointly affect team performance. In large-scale context, organization design becomes the first-order factor, thus it is essential for SM to learn about it. Later, Scrum Alliance introduced A-CSM and scaling is part of its content.
The more scaling-focused educational option would be attending CLB or CLP after CSM. CLB is 1-day overview on LeSS, while CLP is 3-day deep-dive on LeSS. For people working in large-scale organization to learn about Scrum, it is also recommended to attend the 2-day CSM plus 1-day CLB. Regardless, the underlying thinking behind those options is all the same, first learn about Scrum then scaling.
However, there is a potentially fundamental flaw. For people working in large-scale organization, only learning about Scrum in one-team context is simply not sufficient. They get confused and fail miserably after going back to apply Scrum in their organization, because the existing organization design is not supportive for Scrum. Therefore, we need better approach on Scrum education in large-scale context.
A while ago, Michael James started to offer 3-day CSM/CLB mixed together. The mixed CSM/CLB does not separate CSM and CLB. Scrum is not something you learn first, while LeSS not as more advanced topic. In order to do one-team Scrum well in large-scale context, the organization design in LeSS is a necessary enabler, thus, must be taught and learned as an essential part. In fact, after teaching CSM for 10+ years, I have stopped doing it, and put my focus on doing CLP. However, I would seriously consider trying the mixed CSM/CLB course.
How about CLP before CSM? LeSS is Scrum, thus it seems illogical to learn in this sequence. However, if we could teach LeSS without Scrum, i.e. extract the part of organization design from LeSS, it isn't that illogical, is it?
Therefore, here is an experiment for Scrum/LeSS education: LeSS before Scrum (rather than first Scrum, then LeSS).
The path of least resistance towards one backlog
How could we create a path of least resistance towards one backlog?
A collection of multiple backlogs is NOT one backlog
Assuming that multiple teams are working on the same product, the below is a typical conversation between me and my fellow, who may be a friend in the community, a client in the organization or a student in the class.
[me] do you have one product backlog?
[fellow] yes, we do.
[me] how do you create this one backlog?
[fellow] we collect every team's backlog to make one backlog.
This is NOT one product backlog, but a collection of multiple product backlogs. They are not the same thing, as one product backlog means to prioritize as a whole, while a collection means to prioritize separately.
Accommodate constraint in actual backlog
[fellow] but, if we prioritize as a whole, we will find that some teams may need to work on domains that they are not familiar with. Though we desire for one backlog, we currently still have constraint.
[me] so then?
[fellow] we have to take our constraint into account when creating the actual backlog.
That way, the collection becomes the actual one backlog. In this solution, we accommodate the constraint in creating actual backlog, and further regard it as desired. It is illustrated by B1-loop in the below diagram.
Meanwhile, as the tension caused by the gap between desired backlog and actual backlog goes away, the fundamental solution of removing the constraint, illustrated by B2-loop, does not move forward. Thus, the constraint will stay forever. This creates the dynamic of "eroding goals".
Maintain desired backlog to keep tension
[fellow] what to do instead?
[me] maintain the desired backlog, so as to keep the tension
Let's maintain two backlogs - desired backlog and actual backlog, so that the tension is kept. This avoids "eroding goals" and creates the path of least resistance towards one backlog.
One backlog for one team
The same dynamic may exist in one-team context too, though rarer than in multi-team context.
Sometimes, we may accommodate the constraint from team members in creating actual backlog, and mistake it as desired backlog.
In that case, maintaining the unconstrained desired backlog keeps the tension, thus creates the path of least resistance towards the real one backlog for one team.
The path of least resistance
Here are some further thoughts on the path of least resistance.
1. Personal vision
In fact, the path of least resistance is the name of a book about personal mastery, which is one of the five disciplines for organizational learning.
What do you want to create? That is your personal vision. The gap between the personal vision and the current reality provides creative tension, thus creates the path of least resistance.
2. Organizational vision
Not surprisingly, another discipline for organizational learning is shared vision. What does organization want to create? The resulting creative tension creates the path of least resistance too.
This is also similar to what I wrote in the article of "from change resistance to limits to growth" - create the common goal to be higher than status quo, in order to avoid the change resistance.
Number of backlogs and multi-learning: 4) specialized feature team
In this article, we shall look at the structure of specialized feature team, and explore the dynamics around their backlogs, then analyze its impact on the agility and find the lever to optimize for the agility.
Feature team is responsible for delivering customer value from end to end, thus, there is only one backlog associated with value delivery, i.e. the whole team shares the work and one priority. However, for the organization, there are multiple feature teams, each having its own backlog. They are responsible for different customer domains, thus, specialized feature teams. Those work in different backlogs are independent of one another.
More backlogs for efficiency
Let's still ask the question of why having multiple backlogs for feature teams. The answer again lies at the efficiency thinking.
B1-loop: specialization for efficiency
This is the same loop as the one you have seen in the structure of functional team and component team. There is an explicit or implicit efficiency goal. This causes efficiency gap, leading to more backlogs, more specialization, higher efficiency, which reduces the gap.
However, here is a different type of specialization. Instead of specializing on function for functional team and on component for component team, feature team specializes on customer domain. This creates the different impact.
The "unintended" impact on adaptability
As feature team can deliver customer value independently, thus, having more backlogs won't have direct impact on e2e cycle time. The unintended impact is on adaptability.
In the upper part of the diagram, there are 3 causal links from #backlogs to adaptability.
- More backlogs, lower transparency, less motivation to respond to change, lower adaptability.
- More backlogs, stronger local identity, less motivation to respond to change, lower adaptability.
- More backlogs, more specialization, narrower knowledge breadth, lower adaptability.
All of them indicates that having more backlogs leads to lower adaptability.
In order for higher adaptability, we need to:
- increase transparency so that we see the need to adapt
- reduce silos associated with local identity so that we are willing to adapt
- increase knowledge breadth so that we have the skill to adapt
Multi-learning for fewer backlogs
Let's see how to drive toward fewer backlogs in the context of feature teams.
R1-loop: fewer backlogs drives broad learning
More backlogs, more specialization, narrower knowledge breadth. Then, the narrow knowledge breadth becomes the cause for more backlogs, and it creates a reinforcing R1-loop. It is easier to work in the direction of more backlogs, how could we turn this around?
Take the same reinforcing loop and make it like this - fewer backlogs, less specialization, broader knowledge breadth, even fewer backlogs... The challenge is that less specialization does not lead to broader knowledge by itself. We need multi-learning to increase the knowledge breadth.
Fewer backlogs drives multi-learning; multi-learning enables fewer backlogs. They are mutually reinforcing. Therefore, the number of backlogs itself is an important lever - have one backlog for multiple feature teams.
The above analysis is exactly the same as the one for functional team and component team. What are the differences here? The knowledge breadth here is about customer domain, rather than function or component. The backlog here is product backlog, rather than functional or component backlog. The multi-learning here is cross-domain learning, rather than cross-functional or cross-component learning.
What are the techniques to do cross-domain learning? LeSS provides a guide about multi-team PBR. This is the key practice for any feature team to learn broadly about as many items as desirable from the same product backlog. In fact, when you start the adoption, it is recommended to do all-team PBR by default, in order to maximize the learning. During multi-team PBR, instead of having different feature teams refine different items, we create mixed groups with people from different feature teams, and have them refine different items. They diverge and merge to get the maximum cross-domain learning among those feature teams sharing one product backlog.
In summary, the associated backlogs in feature teams are still for efficiency, but it creates unintended impact on adaptability, rather than e2e cycle time. Cross-domain learning enables fewer product backlogs, while fewer product backlogs in turn drives cross-domain learning.
Let's conclude this series by putting various types of backlogs, specialization and multi-learning together.
The drive behind having various backlogs is higher efficiency through specialization. They specialize on different things - function, component and customer domain. They create different problems. Functional backlog and component backlog create dependency among them for delivering customer value, thus, they have the most impact on e2e cycle time. While product backlog is independent of one another, it has the most impact on adaptability.
The key lever all lies at multi-learning, though different types of multi-learning. Cross-functional learning enables fewer functional backlogs; cross-component learning enables fewer component backlogs; and cross-domain learning enables fewer product backlogs.
This ends the series - number of backlogs and multi-learning.
Number of backlogs and multi-learning: 3) feature group
In this article, we shall look at a variant of the functional team and component team structure - feature group. We shall revisit the dynamics with functional team and component team, and see how much similarity and difference feature group has with them, in terms of its impact on the agility and the lever.
Feature group is also called feature project. It is formed to deliver customer value, consisting of people from various functional and component teams. Each member has its own work and priority, thus its own backlog. Same as the functional team and component team structure, for the value delivery, it requires the work in multiple backlogs, and they are dependent on one another. The difference between them is on whether those backlogs are responsible by functional team and component team, or by functional members and component members in the group.
Let's start from the same diagram for the functional team and component team structure, and understand how it applies in the context of feature group.
Members in the feature group take individual responsibility for either function or component, thus, have multiple backlogs. Why?
B1-loop: specialization for efficiency
The functional or component specialization is good for efficiency. It is now on members, rather than teams, but the same efficiency thinking applies.
This weakens the group's common goal, and likely leads to the following dynamic.
R2-loop: Local identity hurts collaboration
Members still keep strong local identity for their functions or components. This hurts collaboration, which leads to 1) increase integration effort, thus lower efficiency; 2) increase integration time, thus longer e2e cycle time.
The feature group could lessen the silo thinking, as the group may develop a common identity in addition to local identity, something like this - "you belong to this 'team' (feature group), nevertheless, you still do the work in your speciality only."
In the structure of functional team and component team, the related parts may be done at different sprints, thus, the e2e cycle time could be several sprints long. However, the feature group should have the common goal of delivering customer value within the same sprint. In that case, the level of synchronization improves, then, waiting is confined to a sprint. The longest e2e cycle time would be a sprint. This also lessens the below problem.
R3-loop: Rework hurts efficiency
The rework caused by asynchrony still exists, but with the improved level of synchronization, the resulting rework gets decreased.
R1-loop: Over-specialization hurts collaboration
Over-specialization does not get fixed when members have their own backlogs (B1-loop). The resulting narrow knowledge breadth continues to hurt collaboration, and creates unintended impact on efficiency.
Besides, with dynamic requirements, the needed effort in various functions and components will change, which creates two more dynamics, shown as the additional R5 and R6 loops in the below updated diagram.
As members have their own backlogs (B1-loop), the change on effort leads to:
1) Partial allocation
Some members will work in multiple feature groups, then multi-tasking ensues.
R5-loop: Multi-tasking hurts efficiency
More backlogs leads to more multi-tasking, then lower efficiency. The multi-tasking creates another unintended impact on efficiency.
2) Temporary group
Group members will change accordingly, thus the group becomes temporary.
R6-loop: Group instability hurts collaboration
More backlogs leads to less stable group. The feature group consists of people who are able to work on various backlogs. The more backlogs, the more change the group composition endures. It takes time for the group to jell and become effective. Temporary group hurts collaboration, and is hard to sustain the improvement. The group instability creates another unintended impact on efficiency.
In summary, the main dynamics and problems with functional team and component team remain with feature group. However, feature group may have a common goal of delivering customer value within the same sprint, and develop a common identity as a group. Therefore, it is usually better than no group at all, in terms of our goal for agility.
To improve further on agility, having fewer backlogs in the feature group is a key lever. In fact, this is the main difference between feature group and feature team. The real feature team has only one backlog, and members take shared responsibility.
R4-loop: fewer backlogs drives broad learning
Feature team may also start with multiple implicit backlogs due to the skill constraints, but by having one explicit backlog, it drives multi-learning and reduces the number of implicit backlogs over time. On the contrary, feature group accepts the status quo and keeps multiple backlogs forever.
Having one backlog removes the need for partial allocation and temporary group. With the dynamic requirements, the needed effort in various functions and components will still change, and there will be mismatch between the work and the skill. When that happens, we take advantage of it and trigger cross-functional and cross-component learning.
The same list of techniques for cross-functional and cross-component learning still applies.
- specification by example
- collective code ownership
- pair/mob programming
- communities of practices (both functions and components)
- component mentor
- current-architecture workshop
- multi-team design workshop
Multi-learning further enables fewer backlogs, until eventually achieving one backlog. By then, feature group becomes feature team.