October 2017 Archives

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.

About this Archive

This page is an archive of entries from October 2017 listed from newest to oldest.

June 2017 is the previous archive.

November 2017 is the next archive.

Find recent content on the main index or look in the archives to find all content.