Beyond adopting LeSS

Will you adopt LeSS? Not wanted, or not possible; end of story. This is a loss of opportunity for both. For LeSS, it loses much of its potential to make an impact in the domain of large-scale product development; while for organizations, it loses the opportunity to get inspired by LeSS and learn many great and practical ideas from LeSS to help their improvement. Adopting LeSS is not the only way to benefit from LeSS.

How can organizations benefit from LeSS?

I see at least two ways, and refer to them as framework focus and experiment focus.

1. framework focus

Framework focus is to adopt LeSS frameworks (LeSS and LeSS Huge), including the rules that define them, and the guides that support the adoption.

For a smaller large-scale organization, we create a LeSS structure all at once, having multiple feature teams sharing one product backlog. To focus on the whole product, we create common sprints at product level, and inspect & adapt as a whole to maximize customer value.

For a bigger large-scale organization, we take evolutionary and incremental approach, and may start from a RA, having multiple feature teams sharing one area backlog. Gradually with one RA at a time, we transform the whole organization to be LeSS structured.

LeSS frameworks are designed to optimize for organizational adaptiveness. If we adopt it in full, the likelihood to increase adaptiveness will be high. With a well designed structure, it provides a strong foundation for teams to continuously improve. That is certainly one way to benefit from LeSS.

2. experiment focus

Experiment focus is to use LeSS experiments for improvement. In fact, LeSS started as experiments, while frameworks were introduced later as a response to the people who would like to know where to start. The history of how LeSS evolved was well explained in "the story of LeSS" by Bas.

Organizations try to improve regardless of LeSS. They are likely already on their way to improve, but they still look for inspirations about where to evolve, then further refining their vision; or look for improvement ideas in various areas of product development, learning from others and the industry. LeSS experiments just provide those kinds of inspirations and improvement ideas.

This initial set of LeSS experiments is well documented in the first two LeSS books, and more experiments are constantly emerging. When we learn about experiments, we don't just copy the solution - the experiment itself, but focus more on the reasoning behind - why this experiment, what factors and dynamics are involved, etc. The people in organizations decide what to do with that learning, and they own their improvement.

Experiments can be small or big. Those experiments concerning organizational design are usually big ones, which can be risky, but also have the potential to create profound impact. Nevertheless, organizations choose the right pace on their own. Their next experiments can be creating one feature team aligning all members' performance measures without the change in reporting line, merging two teams' backlogs, having the team leader step away from assigning tasks, and many more. They are not the same as LeSS rules, and even not directly from but inspired by LeSS experiments, however, they are equally if not more powerful with their own thinking, reflection and learning.

These organizations may never officially adopt LeSS frameworks, but they clearly can benefit from LeSS.

Get balanced

On reflection, I feel that we get somewhat imbalanced with these two focuses over the years. We seem focusing more on the opportunities of adopting LeSS, and less on the opportunities of using LeSS experiments for improvement. However, the latter perhaps accounts for more among all cases where LeSS can be beneficial. All the LeSS case studies seem focusing on the adoption, and there is not one case study based on using LeSS experiments to improve a large-scale product development organization, without adopting LeSS. In contrast to talking much about starting a LeSS adoption, we seem talking less about designing the next experiment for improvement. LeSS adoption is becoming a goal in itself.

Therefore, I'd like to rebalance the framework focus and the experiment focus. Specifically, I will take initiative to group relevant LeSS experiments into improvement areas (product, team, engineering practices, and organization), then organize a series of educational sessions to increase the awareness that our improvement can benefit from LeSS. Anyway, what really matters is to improve product development. So, let's go beyond adopting LeSS!

Develop causal and dynamic thinking

CLD (Causal Loop Diagram) consists of causal links and loops. Without solid links, there will be no solid loops. While we practice system modeling using CLD, the first gap is usually at stating a causal chain of links clearly. Therefore, we often spend the majority of time in practicing causal thinking on links, and little time in practicing dynamic thinking on loops. How can we develop both thinking skills in a balanced way?

Causal thinking

Causal thinking is the basic reasoning. When we can't explain our reasoning well, it is often because we don't have clear thinking.

When facilitating a group modeling session, the first challenge is to get the people to advocate their reasoning clearly. While one is explaining verbally, it is hard to extract the variables and links. We have to ask to repeat in slow motion so that the causality in the thinking can be exposed and clarified. Facilitating in this case is more about coaching to think clearly. It can be effective, but takes much time, and meanwhile other participants often wander off.

In fact, writing is an effective way to improve thinking. When putting your thoughts on paper, you turn something elusive into something that is more tangible, so that you can evaluate it by yourself and refine it iteratively. As you improve the writing, you improve the thinking.

In High Output Management, Andy Grove writes: "So why are written reports necessary at all? ... As they are formulated and written, the author is forced to be more precise than he might be verbally. Hence their value stems from the discipline and the thinking the writer is forced to impose upon himself as he identifies and deals with trouble spots in his presentation."

While I work with a client intensively, I am used to writing coaching journals every week, capturing the progress and main issues this week, and planning the focused areas next week. I write it mainly for myself, as it forces me to think more clearly about what I do and why I do it. That improves my thinking.

In Writing to Learn, William Zinsser writes on many occasions that clear writing is clear thinking, and the process of writing has often clarified much half-formed ideas. That resonates well with my own experience. I have been writing blogs for many years. When I have some insight, I decide to write about it. I always find that there is unclarity in my initial thought, and I make it clear through writing. This is why I think that the writing is mainly for myself, and it is a plus if some other people can benefit from reading it.

So, when we have an issue or a theme at hand, we first write about it individually. That would provide a much stronger base for the further modeling.

Dynamic thinking

While causal thinking is the foundation, dynamic thinking gets into the core of systems thinking. Dynamic thinking enables us to see interconnections. To develop our dynamic thinking, we extend time and expand space.

When we see an event, we extend time to learn patterns of behavior, and from there we model the structures underlying the event. Extending time is a critical step. If we analyze an event and jump directly into the possible causes, we are likely only seeing linear causations, without seeing interconnected structures. There is a systems thinking tool to help us extend time, which is called BoT (Behavior over Time). We start from the event and identify key variables, then, we look back to draw out patterns of behavior. We may also look forward and project future behavior, acknowledging that it contains assumptions to be tested.

When we see an event, we expand space to include more perspectives. Who is directly involved in the event? Who influences the event or is influenced by the event? We are used to only looking at the event from our own perspective, be it an individual, a team or a department, but we can see the structures in a new light by looking at it from others' perspective. I am not aware of any systems thinking tool that specifically supports this expansion; something similar to the context diagram can be useful.

I do a simple exercise in my CLP (Certified LeSS Practitioner) course to demonstrate that everybody has the potential to think in the longer and more global term. I use an event commonly seen at work - a SM (Scrum Master) chases an individual or a team, on which his team depends, to get a quick response. The SM tries to help the team by removing the impediment, and it seems all good. I ask the participants to slow down, then:

  • extend time, with guided questions such as: has the chasing happened more or less often over time; what are the effects in both the short term and the long term; are there any related things happening and how have they changed over time.
  • expand space, with guided questions such as: what happens to the team, the dependent parties, the other teams who also depend on the same parties, the rest of the organization, etc.

By thinking through those questions, even without modeling, we are able to see some longer-term but often unintended effects (e.g. negative impacts to other teams), vicious cycles, and more interconnections. Indeed, we can practice dynamic thinking not dependent on modeling.

In group modeling sessions, we can design a structure to alternate the focus on causal thinking and dynamic thinking. We zoom in to strengthen variables and links, and we zoom out to expose loops. That forms a cycle, and one session comprises many such cycles.

develop causal & dynamic thinking.jpg

Conclusion

System modeling with CLD is an effective approach to develop systems thinking capability. However, as it involves both causal thinking and dynamic thinking, we can get imbalanced during the practice. It is possible to develop them without modeling. We can write our reasoning to improve our causal thinking; we can extend time and expand space to improve our dynamic thinking. While we practice both with modeling, we alternate them deliberately.

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?

from fixed roles to evolving agreements.jpg

  • 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.

with or without shared-component team - 1.jpg

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.

Thumbnail image for with or without shared-component team - 2.jpg

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?

with or without shared-component team - 3.jpg

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.

Conclusion

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.

Missing 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.

Top 3

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.

from top3 to pie chart - 1.jpg

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

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.

from top3 to pie chart - 2.jpg

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.

Conclusion

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. 

Limits to one PBL 6 - 1.jpg

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. 

Limits to one PBL 6 - 2.jpg

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.

Limits to one PBL 6 - 3.jpg

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".

Conclusion

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?

Deliberate practice

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.

deliberate practice for modeling.jpeg

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.

More about LeSS manager - 1.jpg

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.

More about LeSS manager - 2.jpg

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.

More about LeSS manager - 3.jpg

  1. Visioning, via personal mastery and shared vision
  2. Learning, via mental models and team learning
  3. 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.

  1. 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.
  2. 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.
  3. 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.

Conclusion

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.

Recent Comments

  • lee: ya good thinking read more
  • Lv Yi: The key difference between them is the purpose. MVP may read more
  • Chen Gang: Clear introduction. BTW, do you mean the key difference between read more
  • Jacky Shen: A complicated organization may result to "contract game" & "content read more
  • Lifen: Very glad to see your new post. Just a few read more
  • He Bing: IMHO, the knowledge composition is typically related to role, but read more
  • Lifen: I did experienced the period of wearing this two hats. read more
  • https://www.google.com/accounts/o8/id?id=AItOawmNYfpsk6pL7pHr1A6_rEDt5CYSG_nX6Fg: PO on feature reminds me of companies new to Scrum read more
  • He Mian: What is the new responsibility of the line managers. - read more
  • Vineet Shukla: Hi Yi, We share same views on long lived team read more

Recent Assets

  • develop causal & dynamic thinking.jpg
  • from fixed roles to evolving agreements.jpg
  • with or without shared-component team - 3.jpg
  • with or without shared-component team - 2.jpg
  • with or without shared-component team - 1.jpg
  • from top3 to pie chart - 2.jpg
  • from top3 to pie chart - 1.jpg
  • Limits to one PBL 6 - 3.jpg
  • Limits to one PBL 6 - 2.jpg
  • Limits to one PBL 6 - 1.jpg