Percentage of people in special roles
In large-scale product development organization, %(people in special roles) is a good indicator for the degree of self-organization in teams.
Special roles in this measure are outside teams. There is no special role inside teams, as everybody takes the role of team member. Sometimes, the team may define "special roles" inside it, e.g. interface towards other teams. I consider this as their working agreement, because the team has the full authority to decide and change as they wish. The impact of having those internal "special roles" on their self-organization is a separate topic we may explore in the future. In this article, we focus on special roles outside teams.
Please be noted that %(people in special roles) is essentially the same as %(people in teams), as %(people in teams) + %(people in special roles) = 100%.
Its value in LeSS organizations
LeSS organizational design leads to low value in this measure. This is in line with the LeSS principle "More with LeSS" - the less (fewer) roles, the more responsible teams. Let's look at LeSS organization and LeSS Huge organization respectively.
1. LeSS organization
- there is no undone department, which is the preferred case
- there are 5 teams, 7 people in each, that is 35 people in teams
- there are 1 PO, 3 SMs and 1 manager, that is 5 people in special roles
Then, %(people in special roles) = 5/(35+5) = 12.5%.
2. LeSS Huge organization
- there is no undone department, and no support as it is done by normal feature team
- there are 20 teams, 7 people in each, that is 140 people in teams
- there are 5 POs (PO team consisting of 1 overall PO and 4 APOs), 10 SMs (competence & coaching), 5 managers, that is 20 people in special roles
Then, %(people in special roles) = 20/(140+20) = 12.5%.
There is usually still undone department and support in LeSS Huge organization, and we consider them as people in special roles too, then its value is often higher in LeSS Huge organization.
Its impact on self-organization
Why "More with LeSS" - fewer roles leading to more responsible teams?
There are mutual effects between special roles and self-organization. Having more people in special roles outside teams leads to lower degree of self-organization in teams, which in return leads to more people in special roles. This is shown in the below diagram as a reinforcing loop. It could be either a virtuous cycle of leading to ever higher degree of self-organization in teams and ever fewer people in special roles, or a vicious cycle of leading to ever lower degree of self-organization in teams and ever more people in special roles.
If we elaborate on the links in both directions, we get the below diagram. Having fewer people in special roles opens up more space for teams to self-organize, leading to higher degree of self-organization in teams. This in turn decreases the need for special roles, leading to fewer people in special roles.
Of course, there are other factors too. We add a couple of more variables in the below diagram.
- Job safety: when job safety is low, even if the need for special roles is little, people would still fight hard to keep their special roles so as to keep the job.
- Coaching effectiveness: when coaching effectiveness is low, even if much space has been created for teams, they would still be unable to reach high degree of self-organization.
By now, we have explained why %(people in special roles) would be a good indicator for the degree of self-organization in teams.
Its reality and goal
In reality, many large-scale organizations have a much higher value in this measure. Besides those in LeSS organizations, they may have more of the below special roles.
- business analyst, including those in the name of team PO
- project manager, including those in the name of SM
- technical leader or architect
- team leader, in addition to SM and manager
What these special roles are doing largely belongs to the scope of self-organizing teams. The most helpful way to proceed is for them to join feature teams, as team members. In fact, this is what is going to happen in LeSS adoptions - simplify the organization to scale up.
Are we going to further reduce special roles after adopting LeSS? In LeSS organizations, self-organizing teams are the basic building block, while special roles are mainly in two kinds.
- PO for product vision and direction. If we consider shared vision, it is possible that vision is co-created by teams and product community. See more in Shared vision on product.
- SM and manager for team and organizational capability improvement, as coaches and facilitators. Even with team maturing, it is very likely that they still benefit from having some coaches and facilitators around every now and then, if not all the time.
Therefore, the goal is to have low - perhaps not zero - %(people in special roles) outside teams, and have high degree of self-organization in teams.
Experiments are at the heart of LeSS
Frameworks as starting point
If you look at the LeSS complete picture, you see that the frameworks - defined by the rules - and the principles are at the heart of LeSS. However, this is not completely true.
In fact, the LeSS frameworks emerged out of the experiments, in response to the need of novice group in large-scale product development domain. In the first two LeSS books, hundreds of concrete experiments are shared. Those experiments are insightful but do not fit for novice group. We may start from the frameworks, then still move towards experiments. Therefore, experiments are really at the heart of LeSS.
Then, what is the essence of experiments? How do they differ from best practices and patterns?
Best practices and patterns
At a glance, experiments look similar to best practices. The below is the description for best practice in Wikipedia.
"A best practice is a method or technique that has been generally accepted as superior to any alternatives, because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things."
With best practices, we focus on adopting and spreading them as they are already proven. Best practices both cater to and nurture copying mindset.
However, using experiments in LeSS is to emphasize that "there are no such things as best practices in product development. there are only practices that are adequate within a certain context". This is meant to encourage a culture of leaning, questioning, engagement and continuous improvement.
Are rules best practices, if experiments are not? Rules and frameworks were created to help novice group get started and form the foundation to support empirical process control for the whole product and organization. Would it encourage following and copying mindset, as these are stated as rules? Probably. To mitigate it, in the CLP (Certified LeSS Practitioner) course, we explore the rules via systems modeling to understand various factors and dynamics behind them.
How about patterns - are experiments patterns? A pattern is a general, reusable solution to a commonly occurring problem within a given context. In a way, patterns are formalized best practices, and they differ in patterns emphasizing the context. With patterns we focus on solving problems within a given context. This helps shift the focus away from the copying. While focusing on problem solving in a context, we are more likely trying to understand how the solution is supposed to solve the problem, and how the context matters. In this sense, experiments and patterns are close, as they both present logic and depend on context. However, they differ in putting which one first - the solution or the reasoning?
Focus on reasoning in experiments
In my view, reasoning is at the heart of experiments. When we learn about experiments, we don't focus on copying the solution, we don't even focus on learning the solution itself, we focus on learning the reasoning about the solution - how this solution is created, what factors and dynamics are involved, etc., so as to reason about our own problem and context then create our own solution.
This view made me think that the current format of experiments - try/avoid - does not promote enough the focus on reasoning. Let me use two different formats for one experiment to illustrate the difference.
- Try - one product backlog shared by multiple teams.
- Understand - the impact of number of product backlogs on adaptiveness
With the first format, the focus is immediately on the practice or the solution (share one product backlog) itself; while with the second format, the focus is on the problem/goal (adaptiveness) and the potential leverage (number of product backlogs), thus, the reasoning.
I have to admit that it is unappealing to focus on "understanding" for many people. Unfortunately many people often just want to copy something, thus, any attempt to reason about factors and dynamics with them is seen too slow. However, this is exactly what we need in the complex domain such as large-scale product development.
The experiments are evolving, and never-ending because of continuous improvement. The first two LeSS books documented only those experiments collected till that time. Although we can wait for a revision of those two books, considering the nature of experiments, we would benefit from having a more dynamic collection of experiments made by and for the community of LeSS practitioners.
In summary, here is the shift of focus from best practices to pattens further to experiments:
- with best practices we focus more on copying the solution than understanding the logic
- with patterns we focus on learning the solution as well as understanding the logic - its problem and context
- with experiments we focus on learning the logic - factors and dynamics, then creating solution on our own
Shared vision on organization
Shared vision is one of the five disciplines practiced in learning organization. This is the second article on how this discipline relates to product development organization, and it is about organizational vision. You may want to read the first one about product vision as well.
Let's look at organizational vision again in one-team Scrum context and multi-team LeSS context respectively.
In this context, organizational vision is actually team vision.
Scrum is based on empirical process control, while empirical process is guided by goals. There are three instances of empirical processes in Scrum.
- Daily Scrum is the empirical process applied towards sprint goal
- Sprint review is the empirical process applied towards product goal
- Sprint retrospective is the empirical process applied towards process goal
While sprint goal and product goal are straightforward, what is process goal? The embedded "process goal" in Scrum is to get potentially shippable at the end of every sprint. This lies at the heart of Scrum. Initially team may not be able to achieve this, and they use sprint retrospective to reflect and improve towards it.
Another common source of process goals comes from some assessment frameworks, either created by other people or on our own. The assessment framework is usually associated with questionnaires or checklists. The above diagram is a checklist I created many years ago for my own usage to assess team and organization. Its scope is bigger than one team, but the idea is the same. This kind of framework or checklist implies that team aims to achieve the ideal state indicated by getting full score in all dimensions and questions. If all questions are written as statement and the scores are marked based on the extent that team or organization has realized, the overall statement is essentially a team vision. Team vision describes more than processes, while getting potentially shippable at the end of every sprint is one of those processes.
Similar to product vision, here we set time-bounded team goals based on team vision, and work towards them mainly through sprint retrospective.
Who owns team vision? Though it is clearly defined in Scrum that PO owns product vision, it is less clear about who owns team vision. ScrumMaster certainly plays an important role as change agent, because team vision is closely connected to change vision. On the other hand, as team is self-managing, how much should they own team vision themselves?
This relates again to the above diagram from the book "The Fifth Discipline Fieldbook", which shows the degree of shared-ness. Similar to PO sharing product vision, SM could tell/sell/test/consult/co-create team vision with the team. These various ways of engaging team will also achieve different degrees of shared-ness. Let's elaborate on this.
Suppose that we would like to create a team vision that describes what an ideal team would look like. It could happen in the following ways.
- [Telling] SM creates a full version and simply tells the team that this is what great Scrum team would look like. SM may borrow it from others, create it based on her own experience and aspiration, or mix multiple sources.
- [Selling] SM creates a full version and explains why to the team in trying to convince them that this is a great team vision.
- [Testing] SM creates a full version, explains why, and asks feedback from the team about what excites them and what does not. Then, she refines the vision.
- [Consulting] SM creates a draft version, and asks the team to contribute. However, SM still reserves the role of judge, and she chooses to accept or ignore what the team says.
- [Co-creating] SM does not create any version at all, and asks the team to co-create. SM may prepare some inputs for the team to reference, if they want. In this case, team fully owns the decision making, and SM only acts as the facilitator.?
The co-creation is often done through a series of team visioning workshops, which leads to shared team vision. Please note that it is not a one-time effort, but an ongoing process. Every quarter or half-a-year, perhaps during normal sprint retrospectives, team shall revisit and evolve its shared vision.
In this context, organizational vision spans across multiple teams.
In LeSS, there is an additional event called overall retrospective, which is the empirical process applied towards organizational goal. Organizational goals support to achieve organizational vision.
What is organizational vision? There is a LeSS guide called "Organizational Perfection Vision". Even though "a perfection vision is different from a vision. The goal of a vision is to achieve it, whereas the goal of a perfection vision is to channel improvements", the general idea of organizational vision still holds true. The vision describes a future state of organization, e.g. "able to deliver or change direction at any time without additional cost", "special coordination roles are avoided and teams are responsible for coordination", etc.
In the book "The Fifth Discipline", it defines learning organizations as "organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning to see the whole together". In fact, this describes a future state of organization, thus, learning organization itself is an organizational vision too.
In the book "Reinventing Organizations", it describes the advance of organizational models, and the emergence of teal organizations. Teal organization operates as a living organism or living system, with three major breakthroughs: self-management, wholeness, and evolutionary purpose. Teal organization is another organizational vision that we may aspire to.
In the above diagram from the LeSS guide "The LeSS Organization", we learn that PO provides product vision. Then, who provides organizational vision? Managers and SMs focus on organizational capability improvement, while organizational and team vision guides the improvement. Therefore, manager plays a similar role in organizational vision as SM in team vision. Managers together with SMs may provide organizational vision, by telling all the way to co-creating. Co-creation would lead to the highest degree of shared-ness. Nevertheless, the quality of organizational vision is also dependent on the quality of individual's personal vision. This is why shared vision better starts with personal vision, which is the focus of another discipline "personal mastery".
How do we co-create organizational vision? It could be similar to team visioning process, but with larger group. In those sessions, divergent and convergent steps are planned to facilitate large group. Alternatively, team visioning - what do we want to create as a team - may happen first, then, we organize the sharing sessions for teams to listen to one another, and let the shared vision emerge over time. You may find more from "shared vision" section in the book "The Fifth Discipline Fieldbook".
In product development organization, shared vision is applied to both product and organization. We have explored them in the previous article and this one respectively, and hope that it will help you practice the discipline of "shared vision" in product development organization.
Shared vision on product
Shared vision is one of the five disciplines practiced in learning organization. I shall write two articles on how this discipline relates to product development organization. This one is on product vision, and the next one will be on organizational vision.
Let's look at how shared vision relates to product in both one-team Scrum context and multi-team LeSS context, especially considering that both Scrum and LeSS have the role of PO, who sets product vision and priority.
In this context, there is one team and one product.
Regarding product, there are why, what and how. PO and team are responsible for them altogether, with the below division.
It is clear that the how responsibility is completely owned by team, and the why responsibility is mostly owned by PO. However, the what responsibility is shared by PO and team. The specific division is decided by themselves and context dependent. Usually when team matures, team takes over more of them. It includes two parts. One is requirement clarification. The teams that need to be fed by PO with all requirement details at best work for product delivery. The other is solution creation. The great teams take the problem from PO and create solution for it, and they truly work for product creation.
Shared vision relates to the why. Why this product defines product vision, and why this feature defines feature value. Prioritization is based on both the vision of the whole product and the value of the specific feature. How can PO make the product vision a shared vision? How can PO make the prioritization a shared decision?
The above diagram comes from the book "The Fifth Discipline Fieldbook" and shows the degree of shared-ness. PO can simply tell the product vision and the priority, but as team has almost no active involvement, there is the lowest degree of shared-ness. On the other hand, if the product vision is co-created and the priority is co-defined, there is the highest degree of shared-ness.?
How can we make co-creation work? Through collaboration and participatory decision making. A coach or facilitator like ScrumMaster would be of great help. Many product envisioning techniques such as design thinking are built upon the divergent and convergent pattern, while the book "Facilitator's Guide to Participatory Decision-Making" is one of the classics to facilitate this process.
When PO and team co-create the vision and co-define the priority, there is really no separate role, it is just one team. In the book "Leading Teams", this is the self-governing team setting overall direction on its own, which is simply a natural progression from self-managing team. Do we have this kind of team in reality? Yes, great startup teams often work this way.
In this context, there are multiple teams, but one product.
?In LeSS, product creation is already defined as teams' responsibility. As one PO works with many teams, it is practically impossible to leave teams in the delivery mode. Teams not only work on requirement clarification but also product creation. What remains for PO is still vision and prioritization. See the below diagram from the LeSS guide "The LeSS Organization" for details.
While PO "provides" vision and direction, similar to the one-team context, he could create various degrees of shared-ness by doing it differently - from telling all the way to co-creating. The additional challenge with co-creating is the size of the group. One team is within 10 people, while multiple teams may be dozens, hundreds and thousands of people. Is it feasible to co-create with everybody? Large-group facilitation techniques are helpful. Nevertheless, it does take more time and effort. Is it desirable to co-create with everybody? The active involvement from co-creating would help set free the collective aspiration. However, in order to create a better product vision, it also requires that those people involved have the necessary capabilities such as understanding of users and markets, critical thinking, and etc.
An alternative to co-create with everybody is through product community, where team representatives would participate. In a way, PO team in LeSS Huge could be viewed as the beginning of product community. We may gradually expand PO team and turn it into a product community.
In this case, we don't really have any PO either - neither overall PO nor APOs. Teams and communities co-create product vision, with the support from coaches and facilitators. Do we have this kind of organization in reality? Yes, check out those teal organizations described in the book "Reinventing Organizations".
In the next article, we shall look at how shared vision relates to organization.
There is a rule in the LeSS Huge framework - "LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach".
In the 3rd LeSS book, there are three related guides for LeSS Huge adoption.
- "evolutionary incremental adoption"
- "one requirement area at a time"
- "parallel organizations"
The "evolutionary incremental adoption" guide is an overarching one, which describes two approaches.
- gradual incremental adoption over the whole product group
- focused deeper adoption at a part of the product group
The "parallel organizations" guide provides a major technique to support the 2nd approach, while the "one requirement area at a time" guide is an instance of "parallel organizations".
What is a parallel organization?
"This means you keep your existing organization as it is and gradually build the new organization next to it, starting with a few feature teams or one requirement area."
"A parallel organization is not a pilot, and one consequence is that the line of organizational reporting must be separate from the traditional organization."
This guide was developed from the below experiment.
Try...Transition from component to feature teams gradually (in the 2nd LeSS book)
"Note!--Team Red is not a temporary project group formed only for the purpose of feature-M. We are not suggesting the traditional practice of resource management with resource pools for short-term work groups. Rather, Team Red is a new stable team that will stay together for years; feature-M is but the first of many features they will eventually do."
Therefore, parallel organizations here mean two different structures in reporting line.
There are a couple of risks or weaknesses associated with the approach of parallel organizations.
1. without common vision
Parallel organization is a change strategy, rather than a pilot to test whether this is the direction we would like to go. Thus, parallel organizations happen after you have established a common vision - eventually the whole organization will move into the new mode.
"Communicate very clearly that eventually everyone will be in the new organization. That's an important message so that people in the old organization do not focus on rivalry."
However, shared vision is not a one-time process, but a continuous process. The extent of the commitment to the new vision would vary among the people in the current organization. This is also why using volunteering is a powerful adoption principle. We provide a chance for people who are more ready to volunteer into the new organization now, while for people who are less ready to temporarily stay in the old organization. However, it is not an option to forever stay in the old organization. The really available option is getting some extra time to learn and digest the new mode so as to get more ready (or eventually decide to leave the organization). This fits the nature of various paces that different people have, thus, shows the respect for people.
2. additional complexity
Parallel organizations do introduce additional complexity. The complexity of making two modes co-exist may be more than the complexity of making the new mode work.
At the code level, the individual code ownership simply prevents the adoption of feature teams, while the adoption of feature teams simply breaks the individual code ownership. Continuous integration is not continuous integration any more when only part of the organization is practicing it. "Don't let the parallel organization branch the codebase as that will lead to merge-hell. They are separate organizations but work on the same product and the same codebase."
As there are two different organizations, each involves its own organizational design. In light of Star mode, they may have different strategies, structures, processes, rewards and people practices. These add complexity on the management too.
LeSS or LeSS Huge seem binary, while in fact it is a continuum. We may split LeSS Huge into small LeSS Huge and big LeSS Huge to explore the alternatives. Let's get back to the root of LeSS - experiments, as we shall experiment to explore.
1. Small LeSS Huge
Small LeSS Huge is perhaps between 50 and 200 people.
Try...Feature teams - transition (in the 1st LeSS book)
Reorganize into broad cross-component feature teams
This is an "all-at-once" approach. In the LeSS framework, it becomes a rule. While in the LeSS Huge framework, it is recommended to take an evolutionary incremental approach. However, it doesn't mean that you could not experiment it in the context of LeSS Huge, especially when it is a small LeSS Huge case. It avoids parallel organizations, thus, reduces the associated complexity. Meanwhile, it increases the risk of either superficial adoption (the law of raspberry jam - the wider it is spread, the thinner it gets) or overwhelming problems from everywhere.
Try...Feature teams from single-specialized to multi-specialized
Try...Feature teams from being led by Team Leader (TL) to self-organization without TL
I worked with an organization of ~150 people to adopt LeSS. When presenting them with parallel organizations, they disliked it. They concerned that it would be confusing to maintain two different reporting structures. They used to be structured in functional and component teams. They wanted to form cross-functional feature teams, and change the reporting structure all at once.
However, considering that the challenges could be overwhelming, we thought about limiting the change scope elsewhere. We still had product backlog per feature team, still had Team Leaders (no ScrumMasters) in some teams, and etc. Over time, we reduce the number of product backlogs and nurture the self-organization. Along the way, we don't have parallel organizations in the sense that there are two different reporting structures. Nevertheless, this is still an evolutionary incremental approach.
2. Big LeSS Huge
Big LeSS Huge is perhaps above 200 people.
Try...Feature teams - transition (in the 1st LeSS book)
Gradually expand teams' responsibility
This experiment could mean to merge small-component teams into big-component teams. Suppose that we have four component teams - A, B, C and D, instead of creating full feature teams by mixing all components, we take smaller step to first create bigger-component teams - A/B and C/D, each having two teams sharing one bigger-component backlog.
This experiment could also mean to expand the Definition of Done (DoD) over time. The expansion of DoD and product definition often goes hand in hand. This experiment was actually developed into the guide of feature team adoption map.
Try...Reduce #component backlogs and #functional backlogs over time
The essence of adopting cross-functional feature team could be boiled down to the reduction of #functional backlogs and #component backlogs. Please refer to "number of backlogs and multi-learning" for more details.
While we merge small-component teams into big-component teams, we reduce the number of component backlogs. Besides that, we merge fine-grained functional teams into course-grained functional teams. For example, UX, UI and BA teams could be merged into a product design team; various specialized testing teams could be merged into a generic testing team. While doing this, we reduce the number of functional backlogs.
Try...Feature areas having teams with various extents of functional, component and customer domain specialization
To avoid parallel organizations, try to establish feature areas all at once at the highest organizational level. Feature areas consist of multiple teams, and can complete customer features from end to end. However, team structures within the areas vary. In some areas, those are still functional and component teams. In other areas, those are feature teams, but single-specialized, thus having their own product backlogs. In still other areas, those are multi-specialized feature teams sharing one product backlog. In that case, those areas are already requirement areas, though static. The adaptiveness would increase further by making those requirement areas dynamic.
We continue to experiment towards perfection.
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.