From fixed roles to evolving agreements
In many if not all Agile ways of working, team self organizes to take shared responsibility. This often means to transition from role-based working model to agreement-based working model. This transition doesn't happen automatically, and it needs to be nurtured.
Roles are gone
When a team takes shared responsibility, the fixed roles within the team are gone and everybody becomes a team member. As we want everybody to care about the common goal, we purposefully keep the boundary among team members vague, so as to discourage the silo mentality. However, we often mistaken vague boundary for vague agreements. In fact, we need more - not less - clear agreements when we work in shared responsibility. Shared responsibility combined with vague agreements is a recipe for low performance of a team.
In traditional role-based working model, part of the agreements come from fixed roles with special responsibilities. When we get rid of those specialized roles, and replace them with generic roles such as team member, it both empowers and excuses everybody - now anybody can do anything and anything can be done by anybody. Thus, if we are not careful - doing things without agreeing with each other, it soon becomes chaotic. Once roles are gone, something else is needed.
From roles to agreements
Agreements play an important role when team takes shared responsibility. In theory, as anybody may do anything, everything requires an agreement; this will be too much overhead. In reality, we rely much on tacit agreement. If the team is stable, they build tacit agreements over time. With tacit agreements in place, there is less overhead to keep the team functioning. How do we build tacit agreements? If we leave them completely ad-hoc, they may emerge eventually, but with lots of pain during the storming. It is not uncommon to see that teams ruin the relationships among members and never get out of the storming. So, we instead introduce working agreements to aid the process.
Working agreements are explicit, usually with 5-7 items. They are evolving - with new items added into the list, and old items taken off the list - they become part of tacit agreements. Indeed, when a team changes, the tacit agreements need to be re-built, often meaning that some items may be re-added to the explicit working agreements.
In addition to tacit agreements and working agreements, sometimes there is need for more transient agreements, for example, around specific tasks. While taking shared responsibility, we should be mindful for more clarity - always be clear about who will get what done by when.
Back to roles
Working agreements are defined by team itself, what if team defines roles as their working agreements? It seems not breaking team's self-organization, as long as it is decided by themselves and they can adapt when necessary. Can having roles inside a team co-exist with taking shared responsibility as a team?
Let's look at it from two dimensions - whether roles are fixed or changing, and whether people taking those roles are fixed or changing?
- fixed roles/fixed people leads to the silo - everybody becomes only caring about their own role and responsibility over time, then the shared responsibility is in jeopardy.
- fixed roles/changing people may still have shared responsibility, though the fixed roles implies its static working model, and possibly the lack of continuous improvement.
- changing roles/fixed people looks like just renaming roles:-)
- changing roles/changing people clearly indicates shared responsibility, and the changing roles implies its dynamic working model, and possibly continuous improvement.
Therefore, as long as not the same people stick with those roles, roles and shared responsibility may well co-exist.
Although it is possible that team transforms by itself, it is more common that ScrumMasters, coaches, or Team Leaders (see Leading Self-Directed Work Teams) coach teams to transition from fixed roles to evolving agreements. When the roles are gone, watch out for the agreements!
With or without shared-component team
In many organizations, there is dedicated team responsible for shared components. Meanwhile, there are multiple business/product teams, and they all request work from the shared-component team. The below diagram shows a typical case.
The most pain associated with shared-component team is the waiting, leading to longer end-to-end cycle time. We can improve the situation through better prioritization of the work in shared components and/or further adoption of feature teams.
Prioritize work (with shared-component team)
The work in shared components usually does not have standalone customer value; it needs to be integrated together with the feature work in the businesses/products using these shared components. Therefore, while prioritizing the work in shared components, we naturally consider the priority of relevant features in the businesses/products.
In practice, the request from more important businesses/products usually gets the priority, thus they suffer less from having to wait. For them, even though there is cross-team dependency, the related work can still be done more or less synchronously. However, those less important businesses/products suffer more, and they sometimes feel no hope in getting the priority at all. Is it reasonable?
Suppose that there is one overall backlog including all businesses/products, at some time possibly there is no high-priority work at all from some businesses/products, thus it is reasonable that they do not get any priority in shared components accordingly. However, the reality is that each business/product has its own backlog and people. Even though some businesses/products are less important, they still proceed on their own. In this case, not getting any priority from shared components impedes them from getting their features done, thus creates WIP and waste. Then, is there any better way to prioritize the work in shared components?
When businesses/products have different importances but meanwhile have their own backlogs, how are the different importances reflected across businesses/products? It is actually in the pie chart showing the number of people in each business/product. We should take this information into account while prioritizing the work in shared components. We can fix the work amount for each business/product based on the distribution in pie chart, but this way we ignore the nature of shared components - they are used by multiple businesses/products. How else?
"Buy a feature" is an innovation game by Luke Hohmann, and it fits nicely here. We allocate virtual budgets for multiple businesses/products based on the distribution in pie chart; and we estimate the cost for candidate requests. Then, we decide what requests to take into the next sprint. There is an example in the "Incremental LeSS Adoption at SolarWinds" case study - see the section "Try ... Buy a feature game when you have many stakeholders." If we play the game, businesses/products would have representatives to collaboratively decide. Even not, we can still use this model in the prioritization for shared components. This model intends to align the priorities at the global scale, i.e. between businesses/products and shared components, and thus reduce the waiting caused by different priorities.
Adopt feature teams (without shared-component team)
While it helps reduce waiting time through better prioritization for shared components, the deep cause of waiting is the mismatch between skills and needs. As long as we assume that skills are static - people are fixed in specialized areas, while needs are dynamic - work amount in various specialized areas fluctuates, waiting is inevitable. The fundamental solution is to adopt more feature teams, whose members multi-learn various skills to match the ever-changing needs.
It is important to note that with feature teams, there are still shared components. New shared components emerge and existing ones evolve. Feature teams collaborate to make it happen. By the way, this is what Bas Vodde promotes about maximizing dependencies between teams; I wrote about this aspect also in a related article. Then, how can we move away from shared-component team and towards feature teams?
The first step is to simply distribute the people in shared components to various business/product teams. The number can again be based on the distribution in pie chart. Suppose that we already have partial (not including the work in shared components) feature teams in various businesses/products, we essentially expand the scope of those teams. Those shared-component people continue the collaboration regardless of the change in their team identity - they used to collaborate inside shared-component team, and they now collaborate across feature teams.
Then, as the real integration within feature teams proceeds, the boundary between business/product members and shared-component members gets blurred. Furthermore, the people working on shared components are not limited in those old shared-component people any more.
Eventually, we don't need to consider the pie chart at the level of shared components any more. Only feature teams adapt as part of their normal life - they may move to different businesses/products when priority changes.
In LeSS organizations, the majority of teams are feature teams, and feature teams share components without having dedicated shared-component team. However, as the majority does not mean all and feature team adoption is a gradual process, shared-component team may exist even in LeSS organizations.
With shared-component team, we can still improve its prioritization and gradually reduce its size. The pie chart provides a useful view about global priority; it can help both prioritization and feature team adoption.
Story is about change
It seems self-evident that story is only about change - when it gets done, it becomes part of the baseline. However, in practice, I often observe that people don't make the distinction between change and baseline, which causes pains.
Mixing change and baseline
Let's look at the below example.
create a person with same name
- response with success or failure
- failure includes reason
- attributes include name and title
- name begins with letter and has less than 20 characters
- if the name already exists, create a variant (lv yi -> lv yi.1)
- title is either developer or coach
This is a story from an application of people management. It is about creating a person with same name. While it looks good, there is confusion about what the change is. Is it the whole functionality of creating a person, or is it only the part dealing with same name?
As story is about change, let us only describe the change. The updated story could be as below.
deal with same name
- if the name already exists, create a variant (lv yi -> lv yi.1)
Isn't it easier to understand this story than the first one? It only focuses on the change, while leaving out the existing part.
But, isn't the first one more self-contained, thus more convenient in the way developers can learn about related parts - both existing and new - all at once? Indeed, changes are scattered, and they are not friendly for learning the big picture. This calls for baseline.
Baseline accumulates all changes till now. Once we implement a change, the change becomes part of the baseline.
It is surprisingly common that we don't maintain a baseline, only changes along the way. Missing baseline is the deep issue, and it causes various pains.
How do we learn about the application? We should learn from the baseline, but we haven't maintained it except the application itself or user manual.
How do we make a full regression? We should test against the baseline, but all the details especially expected results are described in the changes. In order to do it properly, we have to re-establish the baseline from the changes, but in practice we seldom do it, because doing it all at once is painstaking. Instead, we do a little bit, for example, creating a set of smoke tests, which is essentially a minimum baseline. Of course, the better way is to establish the baseline from the beginning, and maintain it all along. This can be something as below.
create a person
- response with success or failure
- failure includes reason
- attributes include name and title
- name begins with letter and has less than 20 characters
- if the name already exists, create a variant (lv yi -> lv yi.1)
- title is either developer or coach
Notice that this is not a story, but a baseline functionality of creating a person. Several stories may have changed this functionality, but this is what it is now.
Although this can be a baseline document we maintain all along (the stories can be thrown away after it is developed), the better form is automated tests, which becomes living documentation. You may learn more from "Specification By Example".
I believe that understanding this distinction can help make our product development more sustainable.
Alternative to Reorganization
Reorganize to adapt
Uncertainty causes the need to adapt, but the current organization structure is a drag for adaptation. It seems inevitable to reorganize to adapt. Let's elaborate.
The current organization was set up based on certain (pun intended) assumptions. We looked at what needs to be done, then, organized our people into various teams of business areas and technical areas, be it function or component based. The size of each team accorded to the understanding about work at that moment, and we made it as right as we could.
Then, change always comes. This leads to certain areas having more work of high value than initially assumed, while other areas having less work of high value than initial assumed. How do we adapt?
More often than not, we don't, at least not promptly. This seems surprising - why don't we adapt? On one hand, as we have invested in creating the current structure, we unconsciously follow the plan over responding to change. On the other hand, the intricate structure of teams in various dimensions makes it hard to see the big picture. Although the situation has gradually deviated from the assumptions, only until much later do we see the consequence - deliver less value and become less competitive over time.
Or we adapt partially. We grow people in those areas having more work of high value, but we change nothing in those areas having less work of high value. It is desired that we move people from low-value area to high-value area. However, the structure makes it hard to do so. Thus, we simply tackle only half of the problem, while ignore the other half. This makes development organization grow bigger and bigger, as illustrated in my old article. Furthermore, this only works in good times.
Can we adapt fully, based on new assumptions? Yes, but only through reorganization, as the current organization was set up based on old assumptions. However, the next change will come again, thus we need to reorganize often in order to catch up changes. This can be costly.
Alternative to reorganization
Is there any alternative to reorganization? Yes, we can design organization with the aim of optimizing for adaptiveness. This is exactly what LeSS is about. Let's see a couple of design ideas from LeSS.
One idea is to decouple line organization from requirement area. The coupling makes it difficult to adapt, because the adaptation means at least some reorganization. However, when we decouple them, the adaptation only means reallocating certain teams into different areas, without changing the reporting line.
Another idea is to promote multi-learning thus develop more of multi-specialists rather than single-specialists. This is done through multi-team PBR (Product Backlog Refinement), CoP (Community of Practices), mob/pair programming, etc.
We must deliberately design our organization to optimize for global adaptiveness, rather than local efficiency. Systems thinking plays an important role in this organizational design. This is why I often introduce LeSS as using systems thinking to design a large-scale product development organization aiming for adaptiveness.
What about "if it hurts, do it more often" - does it apply onto reorganization? The idea of doing painful things more often appears a lot in agile thinking. Continuous integration is probably the most well known application of this idea - integration is painful, thus integrate continuously. Martine Fowler explained three forces behind this effect. Would the reduced amount help? Yes, partial reorganization concerns fewer people, thus less painful for the whole organization, though not much for the people involved. Would more learning associated with more frequent feedback help? Would more practices help? Yes, both learning and practices would improve our skills of doing this thing. So, if we do reorganization more often, we possibly do it better, thus it becomes less painful. In other words, we keep asking - how can we reduce the cost of reorganization? The answers will lead us to experiment with different organizational designs.
From Top 3 to Pie Chart
Ultimately, we want to have one product backlog for the whole organization in order to optimize value globally. However, the current reality is often lack of global priority, with many local backlogs. What could be practical next steps in order to gradually establish global priority?
I have been suggesting to start from defining top 3 or a priority guideline. However, I find it only effective in some cases. In this article, I'd like to explore the reasons and provide the alternative - pie chart.
When suggesting to first define top 3, I have the below further changes in mind:
- from top 3 to top 10, 20... then the product backlog emerges
- have more people focus on those top items, thus, deliver more value as whole organization.
However, what actually happens is often different. Once top 3 becomes visible, it does increase the awareness about global priority. All related people do take these as highest priority. But there is little impact on others, whose work is not related to top 3. Why?
The organization is structured with various specialty areas, be it functions, components or customer domains. There are essentially many local backlogs, and the real work only follows the local priority. Even though everybody knows what top 3 items are, it doesn't change anything.
What is wrong with this? Aren't top 3 items already proceeding as highest priority? We need to step back and see the big picture. Looking at the whole development capacity in the below picture, we find that perhaps only 20% of people work on top 3, while the remaining 80% of people work on other things. What is the priority of other things? They are not in top 3, thus lower priority, but as they are being worked on, practically they have the same priority as top 3.
So, the defined global priority does not become the actual one by itself, and we need to respond to them - focus on getting them done as whole organization.
In my experience, the defined top 3 items are usually big. They are close to the traditional project size, i.e. 3 top items may be 3 top projects. Can we get the 1st item done before working on the 2nd and the 3rd, assuming that those items are already minimally valuable? If we are in smaller large-scale case (e.g. 30 people), it is feasible. This way, we evolve from top 3 to one backlog and one priority for the whole organization.
Nevertheless, there are limits to one backlog coming from both PO and team. Please see the full analysis in the series of "Limits to one Product Backlog". When we are in larger large-scale case (e.g. 150 people), we may end up with a few areas each having a few teams sharing one area backlog. Top 3 is not effective in guiding the priority across those areas, then comes pie chart.
Pie chart shows how the overall development capacity is distributed, in terms of people or teams. Pie chart reflects the priority in a coarse granularity, and it is similar to an investment portfolio. The below picture is an example for an 150-people organization, distributed among 5 areas. Furthermore, same as product backlog, pie chart is also prone to change, but less frequently than backlog items.
So, instead of asking what top 3 are, we ask how you want to distribute your whole development capacity.
If you already structure your development organization into feature teams, then, the pie chart shows how many teams in each area. With the appropriate size of areas, this is essentially a snapshot of RAs (Requirement Areas). While the overall PO manages the life cycle of RAs, he could in practice be managing the pie chart.
If your current structure is not yet feature team based, the initial distribution is based on number of people. Then, we look for the opportunity to create the first RA - establish multiple feature teams and have them share one area backlog.
As the transformation of the whole organization into feature team based is a gradual process, it is very likely that in the middle of that change, we also need to change the pie chart. When that happens, we both move existing teams and establish new feature teams to reflect the priority change in the updated pie chart, until eventually pie chart becomes RA view.
Size matters. In smaller large-scale case (i.e. LeSS), we may start with top 3 - what are the most valuable work. In larger large-scale case (i.e. LeSS Huge), we may start with pie chart - how do we distribute our development capacity?
Limits to one Product Backlog - 6
I have written the series of "limits to one product backlog" for a while, and the recent observation and thought triggers me to write another one, which is an addition to the 4th article. We shall elaborate on the capability of prioritization as a limit.
The above diagram was described in the previous article. It showed that the challenge of prioritization comes from the number of items, but didn't deep dive into what specific challenges are associated with the increasing number of items in one backlog. And we dig deeper in this article.
Quick fix for the incapability
As you know, the splitting of teams for different work - thus more backlogs - is common in large-scale product development. There are various reasons, mostly related to various specializations from both team and PO. However, I notice another one more and more often, which is related to the incapability of prioritization. Let me illustrate with a few examples.
- A team used to work for both new development and maintenance. It turned out that maintenance work was always urgent, causing short-term effect; thus, new development was left behind, causing long-term effect. The solution? Let's split into two teams, one for maintenance, and the other for new development. This is a quick fix for our incapability to prioritize between short-term and long-term.
- A group of teams used to work in one priority for multiple groups of business stakeholders. It turned out that every now and then there was escalation from certain group that their requests were not fulfilled. The solution? Let's split into teams, each team for one group of stakeholders. This is a quick fix for our incapability to prioritize across various stakeholder groups, i.e. between local and global.
- A group of teams used to work in one priority for multiple product areas. It turned out that there was an endless fight for priority among areas, indicating a lack of shared vision and global priority. The solution? Let's split into teams, each team for one product area. This is a quick fix for our incapability to prioritize across various areas, i.e. between local and global.
In fact, these quick fixes accommodate for our lack of whole product focus while prioritizing, and our lack of systems thinking to optimize in the long term and at the global scale. So, to make this limit more specific, I update the previous diagram as below.
The limit is our capability on global prioritization in both time and space. The solution is to reduce item diversity in one backlog - be it all maintenance items, or all items from one business group or in one product area.
Why is this limit so pervasive?
When I start to notice this incapability, I find it rather pervasive. Often, we can't proceed towards one product backlog or one area backlog with broad scope, because it is difficult to find a suitable PO or APO. Many people are used to prioritizing inside domains and projects, thus, don't develop the capability to prioritize globally. This incapability doesn't happen by accident, and there is a deep why.
Facing the challenge from much diverse items, PO's anxiety goes up. We can either do the quick fix by increasing more local backlogs (B1-loop), or learn to eventually increase PO's capability on global prioritization (B2-loop). Because it takes longer for B2-loop to take effect, there is another (invisible) reinforcing loop - a vicious cycle - embedded in the two balancing loops.
- the higher PO's anxiety
- the more local backlogs
- the less item diversity in one backlog
- the lower PO's anxiety
- the less learning on global prioritization
- the lower capability on global prioritization
- the higher PO's anxiety
In short, it is not only "we are limited by our capability on global prioritization, thus having more backlogs", but also "we have many backlogs, thus, causing our incapability on global prioritization".
Let's conclude by looking at the leverage. As you may have noticed, the above dynamic reflects the archetype of "eroding goals". The leverage is to focus on maintaining or elevating the "goal" - PO's capability on global prioritization. And how? through learning and practicing the prioritization in a more global backlog with peers. Instead of creating multiple local backlogs to accommodate for the incapability, we introduce one global backlog to drive the learning thus increase the capability.
Therefore, do not delay the introduction of one backlog, start with one backlog and have a group of people take shared responsibility to prioritize globally. As they learn, the capability of prioritization doesn't limit any more.
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