The Odd-e Blog

 
The Authors
 

Over-specialization and waste of potential

Blog - eroding goals 0.jpg

It is natural that people specialize in various things, but when it is too much, it becomes over-specialization. Over-specialization wastes our potential. We shall understand why it happens and how the adoption of LeSS avoids it.

Eroding goals

"Eroding goals" as a system archetype consists of two balancing loops. Think of any problem as the gap between the goal and the actual. There are two types of solutions. One is to improve the actual so that the gap is reduced (i.e. problem is solved), the other is to lower the goal. Over time, it evolves to keep "eroding goals". It becomes boiling frog. This is very simple but powerful dynamic, and let's see a few examples at work.

PO specializing in domain

I have described this topic in the article of "team PO as anti-pattern". Here we don't talk about fake POs, who are not responsible for the product. The real PO may still specialize in product domain. This is often a response to the capability gap. 

Blog - eroding goals 1.jpg

The B1 loop illustrates the solution of lowering the goal. By having more POs, the scope of every PO would be narrower, which requires lower capability.

The B2 loop illustrates the solution of improving the actual. By increasing the learning, the available capability improves. However, it will take time, which makes B1 loop dominant - the goal erodes. This is what we have observed. While growing a company, each PO gets narrower and narrower scope to be responsible for. Also note that we get more and more POs in this dynamic.

Team specializing in function, component or domain

Let's look at team. Team may specialize in function, component or domain. They become functional team, component team and specialized feature team, respectively. Specialized feature team here means that it is feature team and able to deliver feature end-to-end, but it has its own product backlog only containing features in the partial product, i.e. specializing in product domain. 

Blog - eroding goals 2.jpg

This is essentially the same dynamic as PO specialization. The B1 loop lowers the goal by having more teams and each team responsible for the narrower scope, be it function, component or domain. The B2 loop improves the capability, which takes time. This is why we observe that teams get more and more specialized, and meanwhile we get more and more teams.

Individual specializing in function, component or domain

Let's look at team members, i.e. individuals. Individual may specialize in function, component or domain too. They become specialists in the team. 

Blog - eroding goals 3.jpg

This is actually the more generic case for PO specialization, and we see the same dynamic. Individuals get more and more specialized and they become single specialists. It causes that we have to create dynamic team to match the work, and this dynamic team is feature group or project in matrix organization. Likewise, we get more and more people.

In short, this is something I have observed in many organizations. Over time, people specialize more and more, and the company grows bigger and bigger in size, while people's potential is not fully realized!

LeSS promotes learning

Interestingly and perhaps accidentally, LeSS avoids "eroding goals".

Blog - eroding goals 4.jpg

Which one is better, being comfortable but waste of potential, or "painfully" growing and realization of the full potential? This gets philosophical and surely everybody has its own answer.

 

Creating projects is not optimized for product development

Creating projects is still common in product organization, but it is really not optimized for product development. In this article, we give an analysis from one viewpoint.

website-optimization.png

1. The conflict between static skill and dynamic work

If you prioritize the work from customer point of view, you will inevitably find that the effort in each specialization area varies over time. The specialization area could be different functions, e.g. programming and testing. For some requirement, the effort on programming is big while the effort on testing is small; for other requirement, the opposite is true; still for other requirement, their efforts are similar. The specialization area could also be different technologies, e.g. front-end and back-end.

Here comes the conflict between static skill and dynamic work. If people are only working in their specialization area, the capacity will not match with the effort for any requirement. This means that if you work on one requirement at a time, some areas become bottleneck while others do not have sufficient work. The situation in those areas changes over time. Overall, the resource utilization will be low. How do you solve this problem?

2. Creating projects as a solution

One common solution is to create projects. Project groups a set of requirements and creates  batch. Even though for any single requirement, the effort in the specialization area does not match with the capacity, it is likely to match at the project level as the variation among requirements in the batch may average out. Taking it further, creating multiple projects in parallel makes it even more likely to match. In essence, one project and many projects both create the work batch, just to different extents. By doing so, the resource utilization gets improved.

3. The consequences, intended or unintended

However, while creating project and then projects, you increase the WIP and get longer cycle time. The flexibility drops due to the high WIP. Because the work in different specialization areas gets out of sync at requirement level, it creates various wastes such as waiting, interruption and relearning.

Do you see those consequences? Sometimes not, as you solely look at improving the resource utilization. Sometimes yes, then is it acceptable? That depends on your system goal.

4. What system goal do you optimize for?

If your system goal is higher resource utilization, then, you get what you want. However, if your system goal is something else such as higher speed and flexibility, then, creating projects is conflicting with your goal. For product development, speed and flexibility are critical factors, and they are often system goals to optimize for. That is why I state, creating projects is not optimized for product development.

In order to optimize for product development, the focus should be on the unit of requirement, i.e. doing smaller number of requirements in shorter time, ideally one requirement at a time. Instead of creating projects, you adopt product backlog and limit the WIP by either doing sprints in Scrum or setting WIP limit in Kanban.

How about you may still want to consider the resource utilization? You should look for alternative solutions by fostering dynamic skill to meet dynamic work. The cross-learning is essential to increase your resource utilization in the long term, without damaging your system goal.

The end

By the way, I did system modeling with CLD for this analysis, but decide not to include it. I envision a format of systems thinking analysis - first you see the analysis with text; then if you click "Expand", you see the analysis with CLD. Just imagine:-)

 

80% product discovery and 20% project management

Project manager does not exist in Scrum context. Project management in Scrum is distributed mainly between PO and team, for release and sprint respectively. This clarifies one of the most common understandings about SM as project manager, but raises another misunderstanding, which regards PO as project manager. To clarify this, I start to describe PO's job as 80% on product discovery and 20% on project management.

80 and 20.jpg

20% on project management

If you have done the exercise of discovering how project management tasks are done in Scrum, it is clear that there are two levels of projects, the sprint as small project is managed by team; and the release as big project is managed by PO. While making tradeoffs among scope, time and cost, for sprint, team works with tasks, days and members; for release, PO works with PBIs, sprints and teams.

So, does PO do project management? Certainly yes, but that's only 20% of his job.

80% on product discovery

The 80% should be focusing on product discovery - find the most valuable work. PO shifts the focus from the output (how many features) to the outcome (how much impact).

How does PO do product discovery?

PO collaborates with users, customers and stakeholders, as well as the team on product discovery. He owns the product vision, and defines release goals based on impact. He uses techniques such as persona, impact mapping and story mapping to understand the customer problems deeply, explore the product solutions broadly, and plan the releases with clear focus.

The product development is inherently uncertain, thus, inspection and adaptation on sprint basis is necessary. PO leads sprint review and uses various types of information to make informed decision about what to do next.

Why do you see the opposite?

Unfortunately, I see that many POs have the disproportionate focus on project management and product discovery. Some might have focused 99% on project management. They missed the opportunity to make a real difference. It is sad, but why does it happen?

One common reason is that PO is from R&D, rather than from business and product. This essentially maintains the traditional contract mode - R&D is responsible for delivery, but not for ROI. The prevalent component team structure makes it more difficult to change. If team is responsible for component, their PO can hardly focus on product discovery.

 

Less copying, more learning

I started to work with a new organization and its teams recently. During the first sprint retrospective, developers and testers in teams discussed about how to collaborate more effectively. The same discussion has happened in other organizations of the same company, isn't it too slow to go through it over and over again? Why not simply copying solutions from elsewhere?

Copying != learning

Copying could mean simply adopting best practices from the industry. As they are best practices, we only need to focus on executing them well in our environment.

Pilot then spread is a slightly different form of copying. We realize that our context is different. Thus, we first pilot in small scope and create solutions fitting into our context, then, we spread those solutions throughout the whole organization. For example, we pilot in one team, then, spread to other teams; we pilot in one organization, then, spread to other organizations within the same company.

The process of effective problem solving and improvement goes something like this:

  1. Experience the problem
  2. Create options to experiment
  3. Inspect and adapt

What are problems with copying regarding this process?

  1. While copying, motivation is not in place. In particular, the intrinsic motivation is often missing, even though strong execution may bring extrinsic motivation.
  2. We can copy to create options. However, the associated thinking on essential elements may not be developed. This leads to practicing without deep understanding and clear focus.
  3. After copying, it is done. We do not continue to make necessary adaptation for our context.

In short, copying does not develop the motivation and the understanding. Furthermore, when people is part of the context (thus, you never get the same context), simply copying does not work. To be clear, I am not suggesting that we should reinvent the wheel, but copying without learning does not work.

Speed up learning

Often, I hear comments from clients saying that "I feel slow in our transformation". We need to understand the real constraint here. In my view, it is the learning that decides how fast we can make in our transformation.

Copying essentially puts the focus on execution, rather than learning. On the contrary, in order to go fast, we need to speed up learning.

Learning involves developing the motivation, creating options, and inspecting & adapting.

  1. Motivation

Strong execution in many cases only brings extrinsic motivation, while intrinsic motivation comes from seeing and experiencing the problem themselves. To speed up the learning, we speed up the exposure of the problem. "Scrum is like your mother-in-law, it points out ALL your faults." Shorter iteration and faster feedback help further.

My coaching focuses on helping people see and experience the problem. Through visualization and powerful questions, people think and relate. That creates the motivation to act.

  1. Best practices as inspiration

Speed up learning by facilitating to create experiments. Take best practices as inspiration.  Understand deeply on why and what essential elements are.

My coaching focuses on increasing awareness on essentials behind various best practices. For example, scaling involves making choices with lots of variables. Systems thinking helps people see the dynamics and possible leverages.

  1. Retrospective

Give the learning priority. While coaching a company with strong efficiency and delivery focus, I have seen a common mistake in adopting Sprint among organizations within that company. They do not end Sprint on time, when there is unfinished work. The default priority for them is to finish the work and deliver, while retrospective and associated learning are delayed and even skipped.

My coaching focuses on making retrospective happen. After facilitating many retrospectives and following what happens later, I come to think that the spirit of learning and improving is far more important than retrospective techniques.

Coaching plays an important role in speeding up the learning. With my past experience in Agile organizational transformation, coaching capacity is often a constraint. In this regard, more and better coaches are helpful to the progress. However, I also think that more or better coaches can not speed up the progress indefinitely, as learning inevitably takes time.

In LeSS, there is a rule regarding LeSS Huge adoption. "LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach." The relevant guide in new LeSS book is called "One Requirement Area at a Time", which distinguishes from the "pilot & spread" approach. Why? One reason is that it is hard to provide enough education and coaching on that scale.

The end

My friend and former colleague Janne Kohvakka experienced LeSS Huge adoption twice, and afterwards wrote an article "Will Your Second LeSS Adoption be Easier?".

Perhaps I just want to set the right expectation...

 

Team PO as anti-pattern

In large-scale product development, multiple teams work on one product. Team PO is prevalent for various reasons, but they are anti-patterns. In this article, I try to describe those and provide the leverages.

In Scrum, PO plays an important role in breaking the traditional contract game and improving the collaboration between R&D and business/product. Thus, I first try to learn whether those team POs are from R&D or from business/product, as they represent different reasons and dynamics.

1. Team PO from R&D

Component team

Blog - team PO 1.jpg

B1-loop: Have PO from R&D to accommodate for component team

While adopting Scrum, there is a need for PO. However, component team structure makes it impossible to have real PO from business/product. B1-loop illustrates one common response to this problem - find PO from R&D instead, which fulfills the need, but is a symptomatic solution.

B2-loop: Adopt feature team to enable PO from business/product

B2-loop illustrates another solution, which is to adopt feature team, so that we can find real PO from business/product to work with team. This requires organizational structural change, thus not an easy path, but it is a fundamental solution.

Having PO from R&D removes the immediate tension of not having PO. The R-loop shifts the burden to B1-loop, thus, the status quo of component team is maintained.

Business/Product disengagement

In case of feature team, there are still team POs from R&D but with different reason.

Blog - team PO 2.jpg

This dynamic is basically the same as in one-team Scrum, where business/product does not want to engage in sprint-by-sprint collaboration with R&D and they are still in the mode of contract game. In large-scale product development, it just creates more resistance as the need for having one PO per team requires more business/product people to change.

B1-loop: Have PO from R&D to accommodate for business/product disengagement

B1-loop illustrates the solution of having team PO from R&D. This releases the tension for business/product to engage into sprint-by-sprint collaboration with R&D, but it is a workaround.

B2-loop: Coach business/product to engage

The fundamental solution is coaching them to engage. Once they get used to collaborating with R&D team on sprint basis, e.g. at sprint review, the required change to take PO role becomes smaller thus more likely to happen.

Having PO from R&D makes an excuse for business/product not to engage in sprint-by-sprint collaboration with R&D. The R-loop shifts the burden to B1-loop, and the status quo of contract game is maintained.

2. Team PO from Business/Product

When POs are from business/product, there are two common reasons why every team still has its own PO.

Overload on requirement clarification

When team counts on PO to clarify requirements for them, PO becomes bottleneck and is constrained to feed mostly 1-2 teams.

Blog - team PO 3.jpg

B1-loop: Have team POs handle the workload on requirement clarification

B1-loop illustrates the common solution of having one PO for each team. As the number of stories for one team is limited, PO's workload gets eased.

When team PO focuses on requirement clarification, she essentially takes BA role. In Scrum, BA is part of team, and works as team member. She may still develop speciality on business analysis, but in the meantime she shares the team's common goal and learns other specialities, while other team members learn the speciality of business analysis too. By having a separate team PO role, it creates the extra handoff.

B2-loop: Have team clarify requirement directly with users and stakeholders

The fundamental solution is to let team clarify requirements, especially the details, directly with users and stakeholders. It eases PO's workload and enables one PO to work with multiple teams by focusing on prioritization. This reduces the handoff too.

Having team PO actually makes it harder to get team involved in requirement clarification, as team POs can well manage their workload thus have less perceived need to involve team. The R-loop shifts the burden to B1-loop and stabilizes team PO role.

Specialization on product domain

There are many domains inside a big product. It is a challenge for one PO to develop deep insights in all domains for effective product discovery.

Blog - team PO 4.jpg

B1-loop: Have team POs specialize on product domain

B1-loop illustrates a common solution of having team POs specialize on different domains. This is essentially a response to capability gap. By defining narrower domains, it reduces the required capability.

Specialized team PO often goes with specialized team. In this case, there is not any more shared product backlog with one priority. Much of the product discovery is restricted in each domain and only leads to incremental innovation, while the breakthrough on the whole product is less likely.

B2-loop: Learn to be capable for the whole product

The alternative solution is to develop the capability through learning. We aim to have one PO capable of leading product discovery for the whole product, with the help from teams and domain experts.

In case of LeSS Huge, APO specializes on certain requirement area inside the whole product , but APO is not team PO, as requirement area usually has 4-"8" teams.

These two balancing loops form the archetype of "Eroding goals". As the size of product development grows, it creates more POs with narrow domain focus and fewer POs with whole product focus.

Summary

Team PO in large-scale product development is an anti-pattern to watch for. In case of team POs from R&D, we shall try to break it by adopting feature team and coaching business/product to engage in sprints. In case of team POs from business/product, we shall try to break it by having one PO with the whole product focus while getting help from teams and domain experts on requirement clarification and product discovery.

 

Why product development group ever grows

I have seen ever-growing development group over and over again, whether it is a component team, a specialized feature team, or a Requirement Area (RA). There is an intriguing dynamic behind.

Ever-growing people

Work vs. People.jpg

This is my first time writing a dynamic with Stock & Flow Diagram (SFD) rather than Causal Loop Diagram (CLD). The reason is that for this dynamic, the distinction between stock and flow is important, and it makes the dynamic more clear and easier to understand.

In CLD, all are identified as variables. In SFD, there are three types of variables - stock represented by the rectangle, flow represented by the oval, and auxiliary variable represented by the diamond. Flow is further defined as inflow and outflow. Inflow increases the stock, while outflow decreases the stock. Thus, while you count the number of links to identify the polarity (Reinforcing or Balancing) of a loop, you treat inflow to stock as +, and outflow from stock as -.

B1-loop: hiring for people gap

  • the more customer work coming
  • the longer work backlog
  • the more people gap
  • the more hiring or moving in people
  • the more people for work
  • the higher velocity
  • the more work done
  • the shorter work backlog

In short, B1-loop illustrates that we hire people to complete growing work.

The customer work fluctuates. This happens naturally in one part of the product, either components or customer domains, if we prioritize the work for the whole product.

When the customer work decreases (i.e. there is work gap), there are two solutions illustrated by B2-loop and B3-loop.

B2-loop: moving people out for work gap

  • the less customer work coming
  • the shorter work backlog
  • the more work gap
  • the more firing or moving out people
  • the fewer people for work
  • the lower velocity
  • the less work done
  • the longer work backlog

Assuming that firing is not desired, B2-loop illustrates that we move people out from this part of the product, in response to work gap.

However, in reality, what is more often seen is the B3-loop.

B3-loop: create internal work for work gap

  • the less customer work coming
  • the shorter work backlog
  • the more work gap
  • the more internal work created
  • the longer work backlog

When there is people gap, we go for B1-loop; when there is work gap, we go for B3-loop. The intriguing thing happens, as there is no outflow for the stock of "people for work", it ever grows.

Fixed group vs. Variable work

What makes B2-loop difficult to happen in reality? Once the group is fixed on certain part of the product, the emphasis on the responsibility for that part builds silo mentality, which puts maintaining the group above the actual work situation.

Think about a couple of cases where we fix a group on certain part of the product.

  1. Component team

We fix teams on components. As the original customer work is based on features, the work going to certain components fluctuates. The above dynamic indicates that component team will ever grow. To break this, we shall adopt feature team.

  1. Specialized feature team

We fix teams on specialized area. As we set the priority for the whole product, the work going to certain areas fluctuates. The above dynamic indicates that specialized feature team will ever grow.

Isn't specialized feature team the same as RA? Yes and no.

If feature team is specialized further within RA, and they have their own team backlog, rather than one shared backlog for RA, this is not the same as feature teams in RA. The above dynamic could happen in the short term, and make the RA unnecessarily big. To break this, we shall adopt generic feature team (not constrained by the specialization and always follow one priority) within RA.

If feature team is specialized on RA, assuming that RA's work is stable during relatively long period, the dynamic happens more slowly. However, if we never change RA, the RA will ever grow too. To break this, we shall adopt dynamic RA.

In LeSS, RA is defined as dynamic area. We move teams across areas based on the long-term trend. However, in practice, the choice of whether coupling RA with line organization or site makes a big difference. Once they are coupled, the silo mentality gets stronger. It is almost doomed that RA will ever grow in the long term.

In summary, when we create fixed group for variable work, the underlying dynamic will make the group ever grow.

Endnote

What about ownership? This is the reason to create fixed group in the first place. Ownership and silo are two sides of the same coin. We shall develop the ownership for the whole product, rather than part of it.

What about outsourcing to make B2-loop happen? This is indeed the traditional response to this problem. However, it creates much more problems than it solves.

 

Change starts before it starts

People ask me how long it takes to adopt LeSS? I say, half a day. I refer to the most visible change in the LeSS adoption - team self-designing workshop, where the restructuring to feature teams happens.

In fact, change starts before it starts.

A couple of years ago, my client asked me to consult on their large-scale Agile adoption based on LeSS. I accepted and later found that there was not yet any product unit ready to start the adoption immediately. Thus, we started with organizing a few 2-day LeSS workshops in their various sites. We invited key people from product units who were interested in improving their system, and offered LeSS as one alternative. Not surprisingly, nobody decided to move forward right after the workshop. If they did, I must have set the unrealistic expectation about what this meant. After those workshops, we continued the discussion with some of them, who were not  scared away still. Fortunately, a couple of product units eventually went onboard. The experience afterwards was documented in my experience report - LeSS without Scrum.

Ever since that, I evolved my strategy about what to do before reaching the point of flipping the organization.

LeSS workshop

Having LeSS workshop to build the understanding is still essential. I do not try to sell, but help make informed choices. For many people and organizations, they only see one option. For example, start with one team responsible for one component; when the team grows and splits into two teams, almost always, each team would be responsible for a sub-component. The success key in workshop is to help people see it as one option, but there are also other options.

We apply systems thinking to understand current situation. By seeing the dynamics resulted from our previous choices, we develop insights about how we contribute to our own problems. This is critical in building the motivation for change.

Different options are optimizing for different system goals. We need to define the organizational perfection goals, as they guide our choices in organization design. LeSS is a set of organization design choices, and optimizes for the goal of delivering valuable product in every sprint. If you have a different goal such as maximizing resource utilization, you would make different choices.

Once we build informed consent, we are ready to go.

One product backlog

We develop better understanding about what our product is, and create one product backlog for it. We do not change the way of managing work yet, but only add this view in parallel. This creates transparency, and often exposes problems in the current system. One typical problem is the difficulty in delivering a feature due to the asynchronous dependency across multiple component teams. By seeing those problems clearly, the motivation for change increases.

Meanwhile, this is also the foundation for the future work and team re-design. It helps accelerate the pace of change once your decide to go. We shall use it as guideline for team self-designing workshop. We shall use it as input to sprint planning. Even if you still decide not to take the further step, one product backlog is still useful to let you see the value delivery capability of your organization.

Continuous integration

Continuous Integration (CI) is essential for feature teams to succeed. It takes much effort to build this capability, thus, start earlier. We adopt CI to tackle one of the known biggest obstacles in adopting LeSS. On the other hand, the motivation of adopting CI may be low as you do not yet have feature teams in place. This becomes chicken and egg problem. As minimum, we shall do the daily build, and create one example for both unit test and acceptance test. This involves the skill buildup and tool selection. It helps accelerate the pace of change once your decide to go. Meanwhile, those engineering improvements are useful regardless of your organization design.

Before "change" (i.e. the most visible structural change), you focus on these areas. During "change", you focus on organization design for both work and team. After "change", you focus on sprint practices, effective learning, coaching for self-organization and continuous improvement.

 

Is your current mental model useful?

Mental models are underlying assumptions. Many different behaviors and decisions could be traced back to different mental models. However, when we start to argue whose mental model is right or wrong, it usually leads nowhere.

Make it explicit

In order to be able to talk about different mental models, the first step is always to make them explicit.

As a coach, one powerful question that I often ask ScrumMasters and managers is "what slows us down in our product development?". Unfortunately, every now and then, I hear some responses along this line - people are inherently demotivated, people slack off, etc. Then, I ask further, "what makes you think so?". It would trigger more reflection, and eventually the realization of different underlying assumptions - theory X vs. theory Y. Theory X assumes that "people have little to no ambition, shies away from work or responsibilities, and is individual-goal oriented." Theory Y assumes that "people are internally motivated, enjoy their labor in the company, and work to better themselves without a direct 'reward' in return."

I have been practicing and teaching systems thinking to understand the organizational dynamics. "Systems thinking is mental models made explicit." We can only question and modify our mental models after they are explicit. When we narrow down the disagreement on one causal link or loop, we make progress. In fact, "fundamental attribution error" in social psychology describes our tendency to blame the person rather than the system. Thus, when practicing systems thinking, we already exert a different mental model - believing that system structure shapes the behavior.

Is it useful?

For people holding theory X or theory Y, they both think that their mental models are valid. They are proven by their own experience. An insight from the book "Systems thinking for social change" is that it is more productive to ask if current beliefs are useful or not? Do they help achieve the purpose or enable to move forward?

Coincidently, when hearing about the response indicative of theory X such as people are inherently demotivated, I often ask that "what can you do?". This is essentially the same as "is it useful to think so?". Based on theory X, there are a few options and possible consequences.

  1. Increase command & control, you see the speed-up, at least for a while. Over time, it slacks off and you have to tighten up again. Even worse, when you overlook things, you become single point of failure.
  2. Work with manager and HR to increase the salary and bonus to motivate people. It may help to some extent. It may also create more problems such as perception on fairness, unrealistic expectation, etc.
  3. Work with manager and HR to get rid of some members who do not "deserve" autonomy. It may help to some extent. It is also likely that new members do not "deserve" autonomy either.

If the above does not help you move forward, it would be more useful to challenge your own assumption and see different possibilities. What if the problem does not lie in people, but in system. Then, you may learn systems thinking and its tools, and start to develop alternative views.

System goal

Usefulness is related to system goal.

If you only seek for short-term result and your domain is relatively simple, command & control with the assumption that people need to be supervised and controlled may be useful. If your goal is to maximize resource utilization, single specialization with the assumption that it is too costly for people to learn new skills may be useful. However, when your goal changes, your mental model presents itself as an obstacle.

I visited an organization recently. With the growth, they are on the spiral of developing narrower and narrower specialization. When examining the goal of the growth, I found that they would like to deliver more. Why do they develop the narrow specialization? The underlying assumption is that specialization helps delivery efficiency, thus, the further specialization would lead to more efficiency. Does it serve the goal in reality? No, they actually find it harder and harder to deliver, due to bottleneck areas. With the current mental model, the way to solve it is to add people in those areas. Unfortunately, the bottleneck areas keep changing. It is simply not feasible for them to keep going. So, it is the time to reevaluate current mental model and seek alternative views.

 

Team-first or Organization-first

When adopting Scrum, we usually take the team-first approach by looking at which teams to pilot Scrum. However, the problem with this approach is that quite often the existing teams are not properly designed for Scrum. So, the alternative approach is organization-first by looking at which part of the organization to pilot Scrum or LeSS when multiple teams are involved for the same product.

Scrum adoption without organization design

Many Scrum adoptions start with giving trainings and finding a project team to pilot. This approach often overlooks the need for proper organization design, which includes:

  • all work comes from product backlog
  • one product owner deciding overall priority for all the work
  • cross-functional team with common goal and shared responsibility
  • SM as coach not having delivery responsibility

Instead, they do poor organization design, which looks vaguely similar but deeply different.

  • only feature work is in product backlog
  • PO only responsible for feature, manager still responsible for maintenance and other work
  • cross-functional team members only work in their own speciality, do not cross-learn, partially work on this project, etc.
  • SM (renamed from project manager or team leader) still responsible for delivery

We often receive limited benefits, if any, from this approach. Even coaching does not seem matter too much. This is best illustrated by Richard Hackman's work. In his classical book <<Leading Teams>>, the below picture showing the relations among team performance, team design and coaching is insightful. In short, well-designed structure and effective coaching together create best effects, but organization design is first-order factor.

Team design vs Coaching.jpg

Scrum holds very different leadership approach, but training does not seem help too much either. The HBR article "Why leadership training fails" illustrates this clearly. "If the system does not change, it will set people up to fail."

LeSS adoption with organization design

LeSS has strong focus on organization design, as it is the first-order factor to influence for change. LeSS is further defined in two frameworks - LeSS (2-"8" teams, roughly 10-50 people) and LeSS Huge ("8"+ teams, roughly 50-1000+ people).

Look at LeSS rule:

"For the product group, establish the complete LeSS structure 'at the start'; this is vital for a LeSS adoption."

Continuous improvement is more effective once proper organization structure is in place. However, organization structure itself is not sufficient, coaching is necessary. The challenge after proper organization design is still big, when you consider backlog management, development practices cross-team coordination, etc. This is the reason why LeSS Huge takes a different approach.

Look at LeSS Huge rule:

"LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach."

LeSS takes all-at-once approach, while LeSS Huge takes incremental approach. Requirement Area is the technique that enables incremental approach in LeSS Huge. The key is to find a relatively independent area, within which you can do LeSS adoption - complete organization redesign.

My consulting approach

During the past few years, unless there is only one team of less than 10 people for the whole product, I try to find a group of 20-40 people, do proper organization design in creating well-designed teams, and coach Sprint practices from there.

For external consultant, the approach of doing proper organization design first makes sure that further coaching on Sprint practices will be focused and more likely effective. If we falter in proper organization design, we also know that the change is unlikely going very far. Then, the decision on whether to engage is better informed.

However, for internal champion, this means that you need to apply the art of the possible before reaching to the point where the experiment can be done on the proper level of organization. Unless your organization is very simple, this usually means certain product area and involving a few functional/component teams for which you need to redesign.