Can you help learning?
This question is about the learning of both kids and adults.
"There is not much you can help"
During the last semester, I attended a parent-teacher meeting. A comment from the teacher struck me in particular - "there is not much you can help" regarding your kid's learning. She meant that they had to work it out on their own. This was different than what I did with my daughter. When my daughter struggled, I tried to help her through explaining the concept to her, analyzing the problem with her, etc. Often, she could "get it" with my help, but still unable to solve similar problems on her own. Instead, the teacher suggested to leave her alone. This triggered me to ponder on the question - can you help learning?
I have been training and coaching on product development and systems thinking for many years. During my training and coaching, when people struggled, I explained more in different ways, gave more examples, and showed my analysis to them. They seemed getting it at that moment, but still struggled next time. For instance, many people said that they could understand my modeling, but could not do it on their own. It seems that the situation is not much different. Perhaps, they just have to work it out on their own, and there is not much you can help.
One thing to notice is the distinction between knowledge and ability. It is relatively easier to convey knowledge, and the question is - can we help learning ability?
On my reflection, I revisited the concept of deliberate practice. By the way, I made a topic presentation "deliberate practice for agile coaching" at Scrum Gathering many years ago.
Deliberate practice is characterized by the following five elements.
1. it is designed specifically to improve performance
- in almost every field, there is a body of knowledge about how its performance is developed and improved, based on which practice activities are designed
- choose activities in the "learning zone", rather than "comfort zone" or "panic zone"
2. it can be repeated a lot
- repeat demanding activities in the learning zone
- repeat at high volume
3. feedback on results is continuously available
- you can't get any better without feedback
Look at these three elements, teachers can actually help a lot. They play an important role to make deliberate practice happen. To illustrate:
- teachers master the body of knowledge, thus able to design practice activities for various aspects of the field. This could be the syllabus for a subject; or the kata for coding or problem solving.
- teachers evaluate where students are in terms of ability level, and ensure that students practice in the learning zone.
- teachers provide feedback. It could be simply correct answers for exercises, but also subjective judgement, or even through analyzing the results together with students.
4. it is highly demanding mentally
- it requires an effort of focus and concentration to improve the unsatisfactory performance of specific aspects.
5. it isn't much fun
- doing the painful and difficult activity over and over may not be fun.
Look at these two elements, they correspond well with the statement "there is not much you can help". To illustrate:
- practicing coding kata regularly is a sign of professional developers, but unfortunately few people hold by it over a long period.
- one of my personal experiences while learning systems modeling is to model for the same topic in many iterations, improving both the model and the thinking. The below picture is the many versions I created while exploring the dynamic with various number of backlogs.
- good students keep working on same problem, and don't give up until they master it.
Learners must keep doing those practice activities that are highly demanding mentally and not much fun, in order to make progress.
Help to sustain
Because of those struggling elements, deliberate practice is hard to sustain. Can we still help in those regards? There are two potential areas.
1. motivation to increase ability
Where does the motivation come from? You may want to create something, while certain abilities are necessary. Or, you may simply have the desire to get better at something, and that mastery itself provides the motivation. The former relates to the discipline of "personal mastery" and the latter relates to the drive. Those are intrinsic motivations, thus eventually still up to learners themselves.
I once wrote an article "create discomfort for continuous improvement". Every discomfort is an opportunity for growth. There is no shortcut, but it can also be considered as good news, as not many people will pursue it.
2. learning mindset
People naturally choose to do enjoyable things, which are often what you can already do well. While deliberate practice means that you insistently seek out what you are not good at, experience the struggle to get better, then enjoy the progress. This requires the right learning mindset, which is essentially mental model for learning - assumptions and beliefs about learning. The right learning mindset is that learning is associated with setbacks, you hold by, and there will be joy after getting over it.
Mental model is developed through experience and reflection. Experience is certainly personal, and you can't transfer your feeling to others. However, you can share your experience, maybe just maybe it prepares others so that they are more likely to hold by when facing setbacks. When they want to give up, you can encourage them and suggest them to take a break. And after they finally get over it, you ask questions to help deepen that experience so as to distill it into their own mental model. Perhaps even if deliberate practice isn't much fun, it can be satisfying after all.?
Well, it seems that we can help learning quite much, both in designing learning content and process, and in developing learning attitude.
More about LeSS manager
It is an oversimplification to understand that LeSS managers mean less (fewer) managers. The more common change in my experience of LeSS adoption is to transform the manager role. Therefore, let's talk more about this "new" role.
Managers improve organizational capability
In the LeSS guide "the LeSS organization", there is the below picture that maps the roles and responsibilities to the focus areas. Managers focus on organizational capability improvement.
One of the clients I worked with actually calls their managers as capability manager, which reflects well their focus area. On the other hand, traditional functional managers may also focus on competence and capability. For example, they may coach and teach the teams in improving their development capability. This is great, however, the organizational capability is more than that. As defined in LeSS rule, "managers' role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and 'experiments over conformance'." Product development system integrate people, process, technology, and more.
Let's elaborate a bit on these means to improve the product development system.
- practicing Go See. "Go see for yourself at the gemba (real place of work) to thoroughly understand the situation" is the 12th principle in the Toyota Way - 14 principles. It is the foundation for effective continuous improvement. There are two kinds of gembas: 1) the gemba of value consumption, where the product is used; and 2) the gemba of value creation, where the product is created. Unfortunately, many managers, especially middle managers, stay away from both gembas. Instead, they live in the powerpoint world with an illusion of reality.
- encouraging Stop & Fix. "Build a culture of stopping and fixing problems to ultimately build quality in" is the 5th principle in the Toyota Way - 14 principles. Quick fix is a norm for many organizations. Without deep analysis, we act based on the symptoms, thus recurring problems. Managers need to be the role model for stopping and fixing, and coach others to do so.
- "experiment over conformance". This is from lean thinking as well. Rather than forcing conformance to central processes, and to bad or outdated product and technology decisions, managers challenge the status quo, and experiment in various areas of product development system to learn and improve.
Should managers improve organizational capability on their own? If managers do all the improvements while others follow, this conflicts with self-managing teams and the desire to unleash the potential of everybody in the organization. Therefore, managers should enable improvements by coaching teams and growing people. On the other hand, how can managers coach teams without themselves deeply doing improvements? Therefore, managers should do the improvements themselves too, preferably in the area of organizational structure, decision and policies.
Managers teach thinking skills
In the LeSS guide "managers as teachers and learners", it is expected that LeSS manages learn to have a good understanding of both the domain and current technical skills, then use that to coach and teach the team. There is another LeSS guide "both domain and technical capability", emphasizing that the right balance between technical skill and domain understanding is needed.
These guides are consistent with what is expected of lean managers - to be hands-on masters of their domain of work. However, lean managers are further expected to understand lean thinking, and to spend time teaching and coaching others. Its focus on thinking skills is evident in Toyota's internal motto "good thinking, good products".
The thinking is embedded in the continuous improvement, and the coaching for better thinking must happen in the real improvement too. Learners learn about the thinking through practicing improvement kata based on PDCA; while coaches coach about the thinking through practicing coaching kata. These two katas go hand in hand, as shown in the below picture from Mike Rother's toyota kata website.
It looks as if managers mainly coach, thus only need to practice coaching kata. This is not true in many organizations, as managers first need to internalize the lean thinking, such as go see and stop & fix, via practicing improvement kata themselves, until they can shift the focus from doing to coaching.
This aspect of manager as teacher may present a great challenge for the transformation of the manager role, as many managers want to be managers, not teachers.
Managers build learning organization
Systems thinking is one of the LeSS principles, and we say that LeSS managers need to be systems thinkers. In my view of "from LeSS to learning organization", LeSS managers go beyond systems thinkers, as systems thinking is the fifth discipline, and there are other four disciplines. LeSS managers are the builders of learning organization, via practicing all five disciplines and coaching other to practice.
The below picture shows the three aspects in learning organization, supported by five disciplines.
- Visioning, via personal mastery and shared vision
- Learning, via mental models and team learning
- Thinking, via systems thinking
Applying these into product development organization, I made a distinction between product learning and process (including team and organization) learning in the "How does LeSS optimize organizational ability to learn?" article. In a LeSS organization, PO and teams focus more on product, while SMs and managers focus more on organization. Therefore, LeSS managers focus on organizational vision and improvement.
- They personally envision the future state of organization and facilitate the emergence of shared organizational vision. See more in the "Shared vision on organization" article.
- They participate in overall retrospectives for organizational learning and improvement, and challenge the existing assumptions and beliefs so as to improve mental models for both own and others.
- They practice systems thinking and coach others to practice. They may start from deepening the analysis in PDCA, then expand it to systems modeling, as introduced in the "Practice Systems Thinking: 2) from Fishbone Diagram to Causal-Loop Diagram" article.
What is the theme for LeSS managers? They improve and coach others to improve; they learn and coach others to learn; they experiment and coach others to experiment. In fact, improving, learning, and experimenting are the same thing. In a nutshell, LeSS managers constantly develop themselves and develop others.
Simplify before moving
"More with LeSS" is one of the LeSS principles and is at the heart of LeSS. It means to have more responsible teams by having less (fewer) roles and less (fewer) installed processes, as more roles and installed processes lead to less responsible teams. In fact, Scrum has the equal focus on self-managing team, while LeSS keeps this focus and points out the key to make it happen in large-scale context.
Simply move it to teams
As we move towards self-managing teams in both Scrum and LeSS, what happens naturally is that much responsibility goes to teams. Who should take up the so-called management work, e.g. planning, coordination and reporting? Surely self-managing teams. We simply move it to teams.
However, let's first look into the management work. It is usually connected to processes - certain ways of working. Some processes are within the team boundary and support team's internal working, other processes are used to interact with the outside. When teams are self-managing, the first type becomes more of team's own working agreements, which are dynamic and updated during retrospectives when needed. While the second type often remains intact as the outside still expects the same ways of interacting with teams, and this is where most of the management work is.
Here are two examples:
- We used to have weekly project status meeting, where team leaders attend and report status on behalf of their teams.
- We used to have project managers coordinate the dependencies and negotiate the priorities across teams.
And "Simply moving it to teams" means:
- Teams write status report and have representatives attend the weekly meeting.
- Teams have representatives to work out the dependencies and priorities across them.
Usually, there are concerns before the change. Does team have the capability to do the work? Team may have a member who did the work before, thus has the capability and may further spread in the team. If not, some team members have to learn those skills. Does team have the capacity to do the work? If the amount of management work remains the same, then the more time on management work, the less time on development work.
Then, if we move forward with the change, this is what I have often seen occurring. Team spends much time on learning and doing non-development work. "I am a developer, and I like doing development work. I don't like spending half of my time in various meetings." We hear comments like these, team morale gets low, and some good developers even choose to leave.
Aren't these just impediments that we shall resolve? Indeed, and most of them are organizational impediments involving others rather than the team itself. ScrumMaster may choose to remove them by herself or coach the team to do so. How? by simplifying the processes and making the management work less needed. However, removing organizational impediments takes time, thus it is a challenge for change management - it does harm to the change momentum when we can not resolve those impediments promptly.
Simplify it via organizational design
LeSS takes a different approach. LeSS first focuses on organizational design, by which the processes are simplified and the management work is less needed.
Getting back to the previous examples, we first ask why those processes exist, then ask how we can simplify them.
- What is weekly report for? It is to check the progress against project plan. How does Scrum achieve this purpose? Scrum shifts the focus from project to product, thus we inspect and adapt on product goal every sprint. Therefore, we get rid of the weekly project meeting, while let PO/APO share the status on sprint basis, and invite stakeholders to sprint review.
- What are the challenges for cross-team coordination, and why? Dependencies, different priorities, etc. and they are caused by having various silos and many backlogs. Therefore, we first reduce the complexity of cross-team coordination, mainly with the structure of feature teams and one shared Product Backlog.
Self-managing teams still need to learn management skills and do management work, especially with the outside. However, it would be less wasteful for teams when we first simplify management work via organizational design.
In summary, when we face the challenge in doing management work, there are three possible solutions illustrated in the below system model.
B1-loop: have managers do management work
B2-loop: have teams do management work
B3-loop: simplify management work
B1-loop illustrates the traditional approach, but more roles lead to less responsible teams. Thus, we want "more with less" - both B2-loop and B3-loop. Moreover, instead of starting with B2-loop, we'd better start with B3-loop. Simplify management work before moving it to teams!
Systems Thinking Dojo
I have been organizing and facilitating the sessions of "practicing systems thinking together" for a while. The purpose is to improve the capability of practicing systems thinking together. Over time, I find it become akin to coding dojo.
"A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun and to engage in Deliberate Practice in order to improve their skills."
The dojo is solely for practice, which distinguishes itself from real performance. However, we often mix practice and performance in our domain of product development. Unfortunately, with the big pressure on from the real work, it is hard for us to focus on improving the skills. Therefore, the same could apply on systems thinking, thus systems thinking dojo.
System Modeling Dojo
In fact, the more precise name would be "system modeling dojo", as we only practice system modeling in a group. There are two aspects in "practicing systems thinking together".
- systems thinking: system modeling with CLD (Causal Loop Diagram)
- practice together: balance advocacy and inquiry while modeling in a group
How is it organized now? The below is the current process.
- Before the session
- Find a topic: I solicit topics from the community - any challenges in the domain of product development that someone would like to explore with systems thinking. Over time, I maintain a list of topics and owners, and simply take the next one for the next session.
- Prepare the topic: I spend 0.5h to prepare with the topic owner, mainly formulating the topic to explore. Then agree on the time, currently having one 1.5h session every other week, evening time, online.
- Open the session: publish the session with the topic and time, open for free registration, limited for 10 people, so that everybody can potentially participate.
- Create a group: a couple of days before the session, I create a WeChat group to share the logistics - links to online meeting and virtual whiteboard, and the participants may have any pre-discussion if they want.
- During the session
- Start with one thought: the topic owner starts by describing the problem and explaining one piece of thought for that problem. Model it with variables, links and loops.
- Invite everybody to participate: inquire for other's thought, and advocate for a different thought. There is one rule: all comments need to be connected to the model. When inquiring, point out the relevant variables, links and loops; when advocating, add or change the relevant variables, links and loops.
- closing: spend 5-10 minutes to freely comment about the experience.
- After the session
- Further discussion in the group, but usually not much:-)
- If some people would like to continue, just suggest a follow-up or same topic and I add it into the list for scheduling, together with other topics.
This seems like deliberate practice, but there are some important differences. There are three elements in deliberate practice - specific, repeatable and feedback. We don't yet dissect system modeling into specific routines that can be practiced and improved alone. We currently practice different topics in each session, even though it is possible to repeat the same topic, the repeatability is not embedded in the design. The feedback in every session is causal and not connected to specific learning goals. We could improve in all these areas.
System Modeling Kata
Here is the definition of Kata in Wikipedia.
"Kata is a Japanese word meaning 'form'. It refers to a detailed choreographed pattern of martial arts movements made to be practiced alone."
When applying this concept into other disciplines than martial arts, kata seems having evolved into two distinctive but related things. One is the piece of routine that supports the development of certain skills; the other is the exercise that is created to practice the piece of routine. Improvement kata mostly refers to the former, while code kata mostly refers to the latter.
So, system modeling kata is:
- the routine that we model with:
- identify a variable with proper name
- clarify the meaning of variables via metrification
- seek inward and outward links for a variable
- model a problem as the gap between current reality and goal
- identify a loop with proper name
- model a solution with balancing loop
- model a limit with balancing loop
- model a vicious cycle (deterioration) with reinforcing loop
- model a virtuous cycle (growth) with reinforcing loop
- recognize systems archetypes
- make interventions based on the leverages in archetypes
- make an inquiry by pointing out the relevant part of the model
- make an advocacy by updating the relevant part of the model
- the content that we model for:
- topics: the below are sample topics from the past sessions.
- move towards trunk-based development
- measure and improve requirement quality
- adopt unit test practice
- continuous integration in large scale
- structure teams for both product development and project implementation work
- scenarios: the below is a sample scenario from my early systems thinking workshop.
- We move towards cross-functional team by first moving part of testing into Scrum team, while the rest still in separate testing team. In the first few sprints, we see that there are still bugs in the Done items delivered by Scrum team, while separate testing team will still catch some bugs introduced by Scrum team. People view it as proof of independent testing team?s effectiveness, thus, want to launch even more of it. We flounder in moving further towards cross-functional team.
- experiments: there are 600 experiments from the first two LeSS books. As "experiments are at the heart of LeSS; reasoning is at the heart of experiments", they are great katas. Via system modeling, we can learn deeply about the reasoning behind those experiments. This in turn improves our capability of modeling together.
Practice In Organizations
Systems thinking is an essential discipline in LeSS and learning organizations. In order to adopt it sustainably, I see three pieces that we can weave them together for the maximum effectiveness.
- practice system modeling in dojo
- We look for existing events to stack dojos on top, e.g. various CoPs, brown-bag lunches, etc.
- practice system modeling in work
- We do system modeling in a portion of experiments, including both product experiments (i.e. features) and process experiments (i.e. improvement actions). For product experiments, we do it during PBR and sprint review; for process experiments, we do it during team and overall retrospective.
- practice light-version system modeling in work
It seems that product development organizations care about productivity the most. This is reflected by the common misunderstanding about adopting agile development for higher productivity while agile development is about flexibility and adaptiveness. In this article, we will take a look at why focusing on productivity is often not a good idea, and surprisingly, focusing on others, such as value, quality, speed and flexibility, eventually leads to higher productivity.
There are a few challenges for productivity focus. Firstly, what is the measure of productivity? For knowledge work, it is not as simple as counting the number of items produced in the factory. We have tried the lines of code, the number of features, and so on, produced per time unit. These are useful to some extent, but focusing on them often leads to local and short-term optimization. In order to deliver more features or lines of code, we select only those familiar features or tasks, and we take shortcuts. We may get higher productivity in the local view and short term, while we suffer in the whole and long term.
What are other focuses in product development organizations? Let's look at value, quality, speed and flexibility, as well as how they relate to productivity.
Value vs. Productivity
This is about outcome vs. output. Outcome is the value, while output is the feature. Usually, we define productivity in terms of output. There is a sense of futility when talking about that we should focus more on outcome. Everybody on the development side agrees easily that this is a major problem, but unfortunately they can't do anything about it.
The silo between product/business and development seems the thickest and deepest, however, this is also where change can have the most leverage. We simply develop too much low-value stuff, partly because it is inherently difficult to identify value, partly because that we are not disciplined enough while exploring and validating value. By the way, agile product development is supposed to increase our discipline via short feedback loop. If we can stop developing half of the low-value stuff, we will have more time to develop those high-value ones with higher quality.
Quality vs. Productivity
It is common that development organizations sacrifice quality in order to meet schedule. The productivity seems improving in the short term, however, productivity deteriorates further in the longer term, exactly because of bad quality. How do we respond by then? We sacrifice quality even more. This is perhaps the most ubiquitous vicious cycle in our industry.
We seem always lacking time to produce quality, but always having time to fix quality. While the defects shipped to users impact quality, the defects found then fixed internally impact productivity. Actually, as there is no easy way to directly measure productivity, I usually suggest to take the number of internal defects as one of the proxies for productivity, because it indicates rework. So, instead of sacrificing quality for productivity, we ensure quality for productivity. In my old days as the quality manager, there was tremendous pressure on meeting schedule in our organization, and my favorite comment was "when we focus on schedule, we don't meet schedule (as our quality suffers, then schedule slips further); while when we focus on quality, we meet schedule too".
Speed vs. Productivity
People often mix up these two concepts - speed and productivity. When they say that they want to go faster, they really mean that they want to produce more. The former is the speed in terms of cycle time, and the latter is the productivity in terms of throughput.
The end-to-end cycle time is critical for product development, not only because it decides when the value is delivered to end customers, but also because it decides when we get feedback for adaptation. How can we reduce cycle time, even with the same throughput? By focusing on the high value work and limiting WIP.
In the book "this is lean", it introduces the above efficiency matrix, which distinguishes flow efficiency and resource efficiency. Behind it is customer focus (speed) vs. resource focus (productivity). Interestingly, the strategy advocated in the book is first focusing on flow efficiency. As improving flow efficiency can reduce a lot of superfluous work and waste, it improves resource efficiency too.
Flexibility vs. Productivity
In my experience, flexibility is not something most organizations focus on, even though It is the means to maximize value in uncertain environment, thus the essence of agile development.
Over-specialization in various dimensions is probably the biggest obstacle for flexibility. It is perceived more productive to keep working in specialized areas, however, it is a local optimization, leading to delivering many features with low value - rarely or never used; or even worse, high amount of WIP - partly done features never delivered to users. How do we break down the over-specialization? Via multi-learning. I have described this topic in the series "Number of backlogs and multi-learning". Although multi-learning is aimed for flexibility, the broad knowledge coming out of it also enables more effective collaboration and integration, which helps productivity as well.
The focus on learning s worth further pondering. Don't we need to learn and improve in order to get more productive? Indeed, if our focus on productivity means the focus on learning, then, it is a good idea. We train and coach developers to write clean code and tests, and help them adopt modern engineering practices. However, this is not what most people usually mean when talking about productivity. Upon a bit reflection, it is common that focusing on productivity means to deliver more by adding more pressure and working longer hours, rather than learning and removing impediments.
In summary, if the productivity focus means to help developers learn and improve, go for it! Otherwise, we'd better focus on:
- value: because only doing high-value work, we have the time needed to do our job properly
- quality: because producing fewer defects, we have less rework
- speed: because flowing better, we have less waste
- flexibility: because expanding knowledge scope, we have more effective collaboration and integration
then, productivity takes care of itself.
Practice Systems Thinking: 2) from Fishbone Diagram to Causal-Loop Diagram
The previous article talked about how to introduce systems thinking in product learning, and this one is about introducing systems thinking in process learning.
In contrast to product learning, practicing systems thinking in retrospectives has been more widely advocated. However, it is rarely sustained in my experience - when introducing system modeling with CLD (Causal-Loop Diagram), it might provoke much enthusiasm in the beginning, but it was seldom picked up regularly, often died out completely after a while. I reflected upon this and supposed that practicing systems thinking was too big a challenge for many organizations, as far as their current reality was concerned. Over time, I realize that RCA (Root Cause Analysis) in the context of PDCA (Plan-Do-Check-Act) could be a stepping stone to systems thinking.
Fishbone Diagram vs. Causal-Loop Diagram
Fishbone Diagram is a common tool for RCA, while CLD is a basic tool in systems thinking.
How does RCA fit into PDCA? In the above A3 report, the left part is the Plan, consisting of the following elements.
- Theme: summarizes the problem or the improvement topic
- Background: why does the problem matter?
- Current condition: describes the current condition for the problem
- Goal: describes the goal condition for the problem
- RCA: analyzes the potential causes
Let's elaborate on the fishbone diagram commonly used in RCA.
- Problem statement is the effect, illustrated as the fish head
- There are categories for potential causes, illustrated as those main branches from the spine.
- Potential causes are written underneath the main and further branches, illustrated as layers of fishbones
How does fishbone diagram relate to CLD? The fishbone diagram is also called Ishikawa cause-and-effect diagram, layers of branches indicating causal relationships. Therefore, it has the same causal foundation as in CLD.
Let's look at the other elements in the Plan. Background describes the effect of the problem, why does the problem matter? What are the consequences of the problem? Current condition and Goal define the problem with more clarify and rigor. The problem can be stated as the gap between current condition and goal. Combining all these elements, it becomes akin to CLD.
What are further benefits through the practice of systems thinking with CLD? This reminds me of a LeSS post-course test question. "System modeling (aka CLD) is a tool used to analyze and find the root cause of a pre-defined problem" - this statement is NOT true. The explanation is "...In Systems Thinking we avoid falling in the trap of simple cause-effect thinking and understand there are always many perspective to a systems and many direct and indirect causes of problems." Indeed, by modeling all causes and effects in RCA as variables, and looking for how they interact with each other, it promotes to think of multiple causes, rather than one root cause; as well as think of leverages, rather than absolute causes.
Convert and Expand
Let's use an example to describe how to transition from RCA to systems thinking.
Here is the brief Plan:
- Theme: adopt UT (Unit Test) practice
- Background: Why UT? better product quality with fewer defects; higher developer productivity due to less rework
- Current condition: few people practicing UT in our development organization
- Goal: all people practicing UT in our development organization
- RCA: see the following fishbone diagram
- The categories are derived from the influencer model. There are two dimensions - motivation/ability and personal/social/structural, thus, we get six categories as main branches.
- In real practice, the causes under "own bad experience" should be asked further, e.g. why not useful. Skip here for brevity.
- "..." under "others' bad experience" is the same as those under "own bad experience".
The process of converting and expanding fishbone diagram (together with other elements in Plan) to CLD is as following.
1. Derive variables from theme, current condition and goal to describe the problem. In this case, I define the variable "#developers practicing UT" for the problem.
2. Model for consequences. We derive the variables and corresponding links from background. There are two main drives for adopting UT practice - product quality and developer productivity. How does practicing UT lead to them? CLD illustrates more granular causal relationships, as shown in the below diagram.
- UT reduces defects from regression, which increases product quality as well as productivity (due to less rework).
- UT's effect on refactoring thus internal code quality is more subtle, while code quality acts as a key leverage for both productivity and product quality.
3. Model for causes. This is an iterative process. I usually take a group of related causes to convert and expand, exploring their relationships with consequences and with each other. For this example, I shall model the causes in three aspects - motivation, time and ability.
3.1 Motivation - do we have the motivation to practice UT?
- R1-loop is to increase motivation via better perceiving the value. There are actually a few similar loops here, through either higher product quality or higher productivity, while they all increase the "perception for the value of UT" thus the "motivation to practice UT".
- R2-loop is to increase motivation via peer pressure; while R3-loop is to increase motivation via organizational recognition.
3.2 Time - do we have the time to practice UT?
- B1-loop constrains the available time to write UT; while B2-loop constrains the available time to maintain UT.
- R4-loop is to reduce time pressure by having fewer defects. We invest time to do UT, but we save time by having fewer defects, can we have net saving on time?
3.3 Ability - do we have the ability to practice UT?
- "Developer skill on UT" is a key variable to understand the dynamic around ability.
- R5-loop shows often a vicious cycle - no time to learn. In fact, there are two similar ones in the diagram, causing no time to write and maintain UT, respectively.
- Thus, "effectiveness of learning UT" becomes an important leverage. Common tool/process, training/coaching are ways to improve the learning effectiveness.
- R6-loop can become a virtuous cycle to increase the learning effectiveness via peer help. In fact, R2-loop and R6-loop provide social motivation and social ability, respectively.
Do you see the advance in thinking with the expanded CLD? That's the motivation behind moving from RCA to systems thinking.
When do we do all these? We practice systems thinking as part of PDCA - we model during Plan, find leverages to Do, then update the model during Check, and design next leverages to Act. As this is on process learning, the natural fit is Sprint retrospective in Scrum as well as both team and overall retrospectives in LeSS.
If practicing systems thinking in process immediately seems too big a challenge for you, RCA could be a stepping stone. Beginning from RCA, perhaps one day we will be practicing systems thinking without notice.
Practice Systems Thinking: 1) from Impact Map to Causal-Loop Diagram
A few years ago, I wrote about "how does LeSS optimize organizational ability to learn?". I saw the potential of practicing systems thinking to enhance both product and process learning, but lacked the concrete steps to make it happen. Now, I gather more thoughts and experience, thus mean to write two follow-up articles - this one is on product learning, and the other will be on process learning.
I always feel hesitant to introduce systems thinking in product domain, because even though it can help in theory, it seems not enough empirical evidence to support its adoption. In contrast, impact mapping is a more recognized technique, and they are both based on logical thinking underneath, so I wonder if we could use it as a stepping stone to systems thinking. While practicing impact mapping, I suggest to do it in a freer manner and focus on establishing the influence path between features and goal - how every feature is expected to cause and has actually caused achieving the goal. In my recent experience, the client one day discovered that it was akin to CLD (Causal-Loop Diagram) - aren't we actually practicing systems thinking? Yes, this approach - from impact map to CLD - could indeed work!
Impact Map vs. Causal-Loop Diagram
Impact map is the outcome from impact mapping. It is a structured mind map, having a goal in the center, with features connected to the goal. CLD is a basic tool in systems thinking. It consists of variables, links and loops to illustrate system dynamics.
They both show causal relations, and both encourage to broaden the space - who else and how else to influence the goal in impact mapping, what other variables influence the dynamic in systems thinking.
However, there are some further benefits through the practice of systems thinking with CLD.
- By loosening the structure in impact map, we are freed to create as many causal links as needed, usually leading to more granularity, thus more clarity and rigor.
- With more variables explicitly being added into the picture, it provides an opportunity to broaden the space further, as we can ask for each variable - what else causes (drives or limits) its change; what else its change leads to.
- With systems thinking, it explicitly asks to extend the time as well - how each variable changes in both the short term and the long term.
- Loops may emerge, and provide further insights for leverage, e.g. exploit reinforcing loops for growth, remove the limits from balancing loops.
Next, I will use an example to describe the process of moving from impact map to CLD, and demonstrate the advance in thinking out of it.
Convert then Expand
This is an example of impact map.
Let's see how each structural element in impact map relates to CLD.
- Goal could be represented as a variable that we would like to optimize, i.e. a variable as system optimizing goal.
- Actor provides perspectives to broaden the space. While modeling with CLD, they are not variables, but can help us think of more variables and see more dynamics.
- Impact is the most critical piece to connect deliverables and goal. We can extract it to create a causal link between each deliverable and goal, with as many intermediate variables as needed.
- Deliverable may or may not be directly represented as a variable in CLD. They can be actions to change variables.
Without much difficulty, we can convert the example impact map into the below CLD.
Here are a few notes:
- "revenue from ads" is a variable directly from the goal.
- I add quite a few intermediate variables, such as "#impressions", "CTR" (Click-Through Rate), "frequency of visits", "length of visits", etc., for more clarity and rigor.
- Among the 5 deliverables, I add corresponding variables for 3 of them (push updates, special offers and better pagination), but the other 2 (forums, chats) are just actions to change the variable "ways to engage". This is to better illustrate the possible relations between deliverable and variable.
Then, we work this initial CLD further by expanding time and space, and discovering interactions and loops, i.e. practicing systems thinking. The below is one expanded version.
Here are a few notes:
- About push updates, there is a limit for the "#push updates", as high number of updates will increase "user annoyance". I add a variable "relevance of updates", then discovered R1-loop that drives the "frequency of visits" through better "understanding of users", thus more relevant updates.
- About special offers, though it drives more visits, thus, more revenue and profit, more budget to fund even more special offers (shown in R3-loop), it increases cost as well, thus puts a limit (shown as B1-loop). I add a variable "relevance of offers", which brings about a similar dynamic (shown in R2-loop) as "relevance of updates".
- Forums and chats provide ways to engage users, so that they can stay longer during their visits. I add a variable "content quality". There are two related reinforcing loops. R4-loop is to drive the "length of visits" with higher-quality content by the company through better understanding about users. R5-loop is to drive the "length of visits" also with higher-quality content but by active users themselves.
Do you see the advance in thinking with the expanded CLD? That's the motivation behind moving from impact mapping to systems thinking.
When do we do all these? Same as impact map, there are as-is and to-be views for CLD too. It is an iterative process to keep exploring, learning and updating. As this is on product learning, it mainly happens during PBR and Sprint Review.
If practicing systems thinking in product sounds too far, impact mapping could be a stepping stone. Beginning from impact mapping, perhaps one day we will be practicing systems thinking without notice.
"Maximize dependencies between teams"
This is an interesting quote by Bas Vodde - "we should maximize dependencies between teams". As it seems contradicting with our conventional thinking, we shall elaborate on it in this article.
Isn't feature team supposed to deliver features independently?
Yes, it is. As illustrated in the above diagram, each feature team develops various items from end to end - team Red for item 3/4/5, team Green for item 1/7/9, and team Blue for item 2/6/8/10. They don't depend upon other teams to deliver those items. In other words, they have separate sprint backlogs.
However, feature teams also seek opportunities to collaborate with one another, as all of them develop the same product and they are not silos. How does it work in practice? Let's look at the below three aspects.
1. Shared backlog
Feature teams share one product backlog. To boost broad learning and increase adaptiveness, we encourage teams to do multi-team PBR (Product Backlog Refinement). Instead of having each team refine specific items, we have multiple teams together refine a group of items, or even all items. In the multi-team PBR, we create the mixed groups consisting of people from different teams, then, make diverge-merge cycles to refine those items. In the sprint planning part 1, feature teams self-organize to agree on which items each team will take, in order to maximize the value delivered in the coming sprint, as well as the learning for sustaining the future value delivery.
2. Shared components
Feature teams share product components. When each feature team develops its selected items independently without collaborating with other teams, chances are they create duplicated work, or the component structure deteriorates. Isn't it supposed to work that way, as we transition from component team to feature team? Not at all. Shared component and component team are two different concepts. LeSS advocates not only feature teams, but also shared components. Feature teams self-organize to create shared components. In the sprint planning part 2, they may discover that they all need to make changes on certain component, thus decide to have a joint design session. They may later form cross-team pairs to implement some changes together. During the sprint, feature teams continuously integrate their work to expose any conflict and collaborate to resolve them earlier.
3. Shared increments
Feature teams share product increments. Sprint review bazaar is a LeSS guide about how to run an effective sprint review. During the sprint review, those stations are usually organized around teams. I find it better to organize them around meaningful increments. Perhaps a set of items form a customer journey, or all contribute to a desired impact. If they are developed by multiple teams, great! Then, relevant teams need to collaborate together, which fosters the whole product view and promotes cross-team learning.
Whole product focus
Putting all these together - although feature teams have their separate sprint backlogs, they share product backlog, product components and product increments. For the good of whole product, the teams need to span their boundaries. This is in line with the case that individuals need to span their boundaries when they form a team. Even though individuals may have different skill levels in various areas, they cross learn and help each other to focus on the whole team. LeSS expands the whole team (one team) focus to the whole product (multiple teams) focus.
In essence, "maximize dependencies between teams" is to encourage collaboration and learning across team boundaries for the whole product focus!
"Component Product Manager"
During the past half year, I have seen the similar situation at least three times in various organizations. This probably means that it is worth an elaboration.
"Component Product Manager"
We know of component team, but what on earth is "component PM (Product Manager)"? Doesn't it sound absurd? I did not really hear the exact term being used, while it came out from the people whom we together ponder over the situation - "we have not only component team, but also component PM"!
We were discussing about how to transition from separate backlogs to one shared backlog. As shown in the below diagram, they currently have respective PMs and development teams responsible for certain areas (A/B/C) within the product. In order to move towards one backlog, besides the teams, the PMs also need to change.
This term contains two parts - Component and Product Manager, and let's understand them separately.
- The component responsible by PM is to some extent customer oriented, as a customer or business area inside the whole product.
- It may depend on other areas to together create value, but it is occasionally valuable on its own, as illustrated in the shared backlog on the right side of the above diagram.
- Product Manager
- Its alternative name is Product Owner, but they are actually more like BAs (Business Analysts). In some organizations, they are also called so.
- They specialize in certain area. As they are coupled with teams, the corresponding teams specialize in the same area.
In short, "Component PMs" are the BAs specialized in dependent areas.
When we have all teams share one backlog, the generic teams (1/2/3) who work on whatever features with highest value simply can't continue to couple with the specialized BAs. Therefore, these BAs need to decouple with the teams and somehow connect to the one backlog, as shown in the below diagram.
It is common that the same technical stack is used across those areas, thus, the teams usually feel comfortable in expanding their scope to develop features from end to end. So, this time, the limit is more on the specialized BAs. They see it a big challenge to learn and analyze broadly across the whole product, for whatever features with highest value in the one backlog. You may argue that developers can learn broadly, why can't BAs do the same? It is of little avail if you encounter a view that developers only need to code for specification, while it is much more difficult for BAs to learn broadly, thus they have to specialize in some area. So, the better strategy is to focus on the system optimizing goal, which is to discover and deliver the most value as the whole organization.
What further complicates the change is that specialized BAs are often located in the product department, rather than the development department. As BA is a part of feature team, the necessary organizational redesign (aka organizational flip) for feature teams is bound to span both product and development departments.
According to the LeSS framework, it is actually one-step change to create both one product backlog and feature teams.
- (one product backlog) All teams follow one priority, not constraint by current skills. When work and skill do not match, it triggers learning.
- (feature teams) Each team includes dedicated BA, and BA will cross-learn in the same way as other members do. All team members have the same reporting line.
It is possible to have more gradual steps, i.e. gradually break down BA's specialization on areas and change the organizational structure as well.
- (one product backlog) BAs are still specialized in areas, then, they are de-coupled from teams. However, BAs follow the same priority from one backlog, and are not allowed to analyze features in lower priority just in order to keep busy. (hint: observe what they will do then)
- (one product backlog) BAs break down the specialization on areas, as shown in the below diagram. They learn broadly to be able to work according to one priority.
- (feature teams) BAs join feature teams, and any BA belongs to one team stably.
- (feature teams) BAs and developers align performance measures across product and development departments, so as to break down functional silo and really have common goal.
- (feature teams) Reporting structure is changed so that all feature team members have the same reporting line, as shown in the below diagram. This further promotes cross-learning within the teams.
Eventually, we evolve into the LeSS structure - multiple feature teams share one product backlog.
Domain Teams and Product Definition
A bunch of teams are responsible for various domains, be it systems or services. Each domain team has its own backlog. For example, in an e-commerce company, there are domain teams responsible for website, OMS (Order Management System), WMS (Warehouse Management System), payment system, etc. They develop features from those domains, such as adding a payment method, managing shared order, tracking shipping status, etc.
What change do we bring onto these teams in LeSS adoption? There are two essential elements in LeSS organizational design - feature team and one product backlog. How does this domain team structure differ from LeSS structure?
One Product Backlog or Feature Team?
At first glance, these domain teams seem like feature teams, as they are customer oriented to some extent. Then, the change would be towards one product backlog. Instead of each team focusing on one domain (team A/B/C for domain A/B/C respectively), all teams will work on whatever features at the top of the backlog.
Let's look at a product backlog as below - all items belong to only one domain. A/B/C in the backlog indicates the domain each item belongs to.
In this case, the domain teams are indeed feature teams, while the main change would be to share one product backlog for maximizing the value delivery globally, i.e. among all domains. In order to share one product backlog, the teams need to transition from single-domain to multi-domain.
Furthermore, let's look into customer value. Does value come from one domain or across multiple domains? How much percentage from one domain, and across domain? Let's look at another product backlog as below - many items are cross-domain.
In this case, the (single-)domain teams are essentially component teams. If we keep them intact, teams can't deliver many items from end to end. Therefore, the first change would be to create cross-domain feature teams 1/2/3. Team 1/2/3 can be fully cross-domain, each team covering A+B+C; or partially cross-domain, e.g. covering A+B/B+C/A+B+C by team 1/2/3 respectively.
Often, we don't introduce another dimension of specialization for these feature teams any more. Instead, we let them share one product backlog. However, if necessary, we can still take smaller step in first creating cross-domain feature team specializing in some customer dimension.
In either case of the above backlogs, we will create multi-domain teams, but for different reasons. When values come from single domains, those (single-)domain teams are feature teams, multi-domain teams are created to globally maximize value delivery (further refer to Number of backlogs and multi-learning: 4) specialized feature team). When values come across domains, those (single-)domain teams are component teams, multi-domain teams are created to first speed up end-to-end delivery (further refer to Number of backlogs and multi-learning: 2) functional team and component team).
The deeper meaning of feature team connects to the product definition. "The definition of feature is dependent on the definition of product. The product bounds the feature, and the feature is end-to-end within the product." (further refer to Is team in Scrum feature team?) So, when single domains are defined as products, those (single-)domain teams are feature teams. When multiple domains all together are defined as a product, those (single-)domain teams are not feature teams anymore; the feature teams in the new context need to be cross-domain teams.
This change relates more to the LeSS guide "feature team adoption map" as below.
In fact, Y-axis shows the gradual expansion of product definition. The scope of feature team gets broader - from single-domain to multi-domain - when the product definition gets broader. In fact, by creating one product backlog to include multiple domains, we implicitly expand the product definition.
In the LeSS guide "define your product", one of the questions that expands product definition is "our product is part of? what problem does the product solve for end-customers?". Let's apply this question in the example of e-commerce. Initially, we may treat OMS as a product, and OMS team is a feature team. Then, as OMS product is part of the e-commerce solution, we expand our product definition to e-commerce. OMS becomes a component in the expanded product, thus OMS team becomes a component team. To make it a feature team, we expand its scope to e-commerce.
In the same guide, there are also questions that restrain the product definition as practical. One of them is "what is the product vision? who are the customers? what is the product's customer domain?". Applying this question here, it is also possible that the company decides to focus on developing an OMS or payment system rather than the whole e-commerce solution, then, OMS or payment system becomes the product. Accordingly, OMS or payment teams become feature teams.
In conclusion, the change on the domain team structure is closely connected to product definition. A feature team often becomes a component team when product definition expands, while product definition may be implicitly expanded when creating one product backlog. In fact, the fundamental change is the expansion of product definition!