This sounds like an easy choice in Agile development, however, single-functional team such as testing team is still prevalent in many organizations. There are forces favoring in it. By understanding the factors and dynamics behind different choices, we make more informed decisions.

Efficiency & Quality vs. Cycle time

Why do we want to have single-functional team? The answer is often with efficiency and quality, as shown in B1-loop and B2-loop.

Why do we want to have cross-functional team? The answer is often with cycle time, which further relates to speed and flexibility, as shown in B3-loop.

Blog - cross-functional team 1.jpg

B1-loop: Functional specialization for efficiency

When there is efficiency gap, we reduce team's functional scope and develop more functional skill, thus, increase the efficiency so that the efficiency gap is filled.

B2-loop: Functional specialization for quality

When there is quality gap, we reduce team's functional scope and develop more functional skill, thus, increase the quality so that the quality gap is filled.

B3-loop: Cross-functionality for speed

When there is time pressure, we expand team's functional scope and decrease the number of teams to coordinate, thus, shorten the cycle time, so that the time pressure is released.

Only seeing this, team's functional scope becomes a tradeoff between efficiency & quality and speed.


The efficiency and quality comes from the functional skill, how do we develop our functional skill? Traditional thinking is that we achieve functional proficiency by focusing on the narrow functional scope. There is some truth, but does not provide the complete picture. Learning comes from the feedback and the collaboration with other functions too.

Blog - cross-functional team 2.jpg

R1-loop: Reduced learning leads to less efficiency 

As we reduce team's functional scope for more efficiency in B1-loop, the functional silo gets stronger and the feedback speed gets slower, which reduces learning. It eventually decreases functional skill and makes it less efficient. Together with B1-loop, they form the "fixes that backfire" archetype.

R2-loop: Reduced learning leads to lower quality

The dynamic on quality is similar to the one on efficiency. We reduce team's functional scope for higher quality, but the reduced learning eventually leads to lower quality. B2-loop and R2-loop form the "fixes that backfire" archetype too.

This adds more advantage on cross-functional team, as it both provides broader context and speeds up the feedback to support learning. However, this means to abandon the traditional waterfall development practices, but to adopt Agile engineering practices especially specification by example to make the cross-functional team collaborate in a truly different way.

Functional sub-optimization

Functional team tries to optimize in its own scope, which often leads to sub-optimization.

Blog - cross-functional team 3.jpg

B4/B5-loop: Increase WIP for cost saving

Driven by the cascaded goal on cost saving, functional team increases WIP in its function. This achieves more efficiency, which leads to lower cost in its function, then, lower overall cost. One such common action is that testing team would accumulate many requirements to test altogether, as this is the most cost efficient way from their perspective.

R3-loop: High WIP increases cost of delay

As WIP gets higher, the cycle time gets longer. This increases cost of delay, which adds up to overall cost. The cost of delay includes both for the development (e.g. increased cost on rework due to delayed feedback from testing) and for the product (e.g. decreased customer value due to delayed releasing to market). B5-loop and R3-loop form the "fixes that backfire" archetype.

As team's functional scope gets bigger, it is more likely to make global optimization.


In the short term, this choice is about the tradeoff between efficiency & quality and speed. However, learning also benefits from the feedback speed and cross-functional collaboration associated with cross-functional team. Therefore, in the long term, cross-functional team could lead to high efficiency and quality as well. Moreover, we shall be cautious of the sub-optimization often made by single-functional team, while it is more likely for cross-functional team to make global optimization.

Revisit feature team - cont'd

Two years ago, I wrote a blog article called "Revisit feature team". I felt not quite complete, thus, the thought went on, until I discovered what was missing recently.

Collective ownership

Let me recap the scenario here. There is one so-called feature team, in which small groups work on different features. The team is stable, while those small groups are dynamic, as shown in the below picture.

Blog - revisit feature team 1.jpg

Within those small groups, they take collective ownership for delivering the feature. However, as the big team, they do not take collective ownership for all features. Therefore, it is not a real team. To make it a real team, it must take the whole-team approach, meaning that the whole team takes shared responsibility to deliver all features, as shown in the below picture.

Blog - revisit feature team 2.jpg

What does the whole-team approach mean in practice? How is it different from the above scenario?

Resilience and Overhead

Let's understand more about the whole-team approach from Scrum.

Blog - revisit feature team 3.jpg

Think about a team with 5 features to deliver in one sprint. A good team does not work on all features in parallel, but they may still work on a couple of features in parallel, as shown in the above picture. Are A1/A2/A3 and A4/A5/A6 also small dynamic groups in the team? Yes and no.

Yes in the sense that A1/A2/A3 working on feature 1 collaborate more closely and learn more details on that feature. They are more strongly connected on those days, during which they are working on the same feature.

No in the sense that the whole team learns about all features in the backlog refinement and planning, and every member inspects the progress in the daily scrum and is ready to jump in.

On one hand, we want to create resilience, so as to take advantage of the whole team's skill and capacity to deliver high-priority features. On the other hand, we want to have reasonable amount of overhead, as everybody in the team would spend effort in learning a bit more than what he/she absolutely and immediately needs.

Blog - revisit feature team 4.jpg

B1-loop: Increase the team size for more resilience

The bigger team, the more people who could swarm, the more resilient we are as a team.

B2-loop: Decrease the team size for less overhead

The bigger team, the more people who prepare themselves to swarm, the more overhead there is, till the point where we could not afford any more. 

It is the team size that balances these two factors. In my experience, the sweet spot for team size is usually 5-7 people. A team of 3 people does not create sufficient resilience, while a team of 10 people brings too much overhead.

Two alternatives

What are alternatives than what is in the original scenario - one big feature team, in which there are small dynamic groups on various features?

1. Split the big feature team into 2 small feature teams, as shown in the below picture.

Blog - revisit feature team 5.jpg

This alternative was suggested in my previous blog article. This is straightforward.

2. Keep one big feature team, in which there are small dynamic groups on various feature sets, as shown in the below picture.

Blog - revisit feature team 6.jpg

This differs from what is in the original scenario, in that the dynamic group is on feature set, rather than on one feature. This creates more balance between resilience and overhead. The collective ownership happens in those medium-sized feature groups, while the stability is kept in the big feature team.

It is indeed more complicated than the first alternative, then does it bring in any advantage? It avoids to force splitting the related work into two teams. It is more cohesive for one group to take all related work. This is essentially the same argument as whether it is good for timebox to force splitting the related work into two sprints.

In part 1, we looked at the case of platform as product. Now, we are going to look at the case of product area as product. Those products all have customer views, but there is possibility to define a broad product, then the products become product areas in the broad product. Let's separate them further into two cases, one is defining product solution as product; the other is defining product family as products.

Product solution as Product

The product solution includes several products that interact to create customer value. Let's take a couple of examples. In telecom, RAN (Radio Access Network) is a solution, while BTS (Base Transceiver Station) and RNC (Radio Network Controller) are separate products - network elements inside the network solution. In e-commerce, the e-commerce platform provides the end-to-end solution for customer, while shopping, payment, logistics are separate products - elements inside the solution. Usually, the product solution evolves to an open ecosystem. We could redefine product solution as product, then those products in the same product solution become product areas.

1. Productization, synchronization and flexibility

Even though the relation among products in the product solution is different from the relation between application product and platform product in part 1, the below dynamic is similar. 

Blog - narrow vs broad product definition 5.jpg

The productization is a key drive for narrow product definition, which is illustrated by B1-loop. The support on productization includes marketing, sales, budget, etc. Once there is gap, we define them as separate products under the same product solution. This increases the product orientation, leading to better support on productization, thus closing the gap.

To deliver the value at the level of product solution, those parts still need to be in sync. The separation of products decreases the extent of synchronization, thus, extends the cycle time. The longer cycle time raises the time pressure, which acts as a force against the separation and narrow product definition. This is illustrated by B2-loop.

The separation also creates silo effect among narrow products, which reduces the overall flexibility. When there is more valuable work in one product, it is hard to move teams from other products to this product. When the whole product solution is still full of uncertainty and the size of the organization is still small, the expected flexibility is high. Thus, it creates a force against the separation and narrow product. This is illustrated by B3-loop.

Similar to turning a platform to a real product, the separation of products in the product solution is better to emerge than to plan upfront. The premature separation creates more problems than what it solves.

2. Local innovation and holistic innovation

There is another tradeoff between local innovation and holistic innovation. Local innovation means the innovation within each narrow product, while holistic innovation means the innovation at the level of product solution.

Blog - narrow vs broad product definition 6.jpg

Narrow product definition helps close the gap on local innovation, which is illustrated by B4-loop. This acts as a drive for narrow product definition. However, the product separation creates the silo effect, which harms the collaboration, then reduces holistic innovation. When a gap is perceived, we define broad product to reduce silo effect and increase collaboration, holistic innovation goes up, which closes the gap. This is illustrated by B5-loop, which acts as a force against narrow product.

Organization may choose a different balancing loop to address the lack of holistic innovation. Instead of defining broad product, they create cross-product task forces to increase the collaboration, thus, promote holistic innovation. This is illustrated by B6-loop. In theory, this is a good idea. However, in practice, it is a challenge to implement the outcome from those task forces into those separate products. Defining broad product and having task forces could be complementary too.

Product family as Product

The product family includes several products targeted for the same market but different customer segments, e.g. some for high-end, the other for low-end. Usually they share a large portion of code base too. We could redefine product family as product, then those products in the same product family become product areas.

1. Attention, competition and confusion

We first look at the dynamic regarding business and customers. Attention on customers increases customer satisfaction, while confusion by customers decreases it. The competition means that  products in the same product family compete for business and customers. 

Blog - narrow vs broad product definition 7.jpg

One drive to define narrow product in product family is to serve their customers better. The narrower the product is, the more attention those customers get. This increases customer satisfaction and relieves customer pressure. This is illustrated by B7-loop.

When each product in the same product family goes on their own, the alignment drops. The competition among products increases, till the point of having alignment gap, which triggers to redefine a broad product. The broad product definition increases the alignment then closes the gap. This is illustrated by B8-loop, which acts as a force against narrow product definition.

What's interesting is when alignment is lower, the confusion by customers increases as they may use multiple products in the same product family and get different even conflicting marketing messages. The confusion decreases customer satisfaction. This unintended consequence is illustrated by R1-loop. B7-loop and R1-loop form the "fixes that backfire" archetype.

2. Duplication and common components

Let's look at the dynamic regarding development. The duplication has negative impact on development cost, while common components help lower the cost. 

Blog - narrow vs broad product definition 8.jpg

When each product in the same product family goes on their own, the transparency across them becomes lower, which makes fewer common components, leading to more duplication. The duplication increases the development cost, then raises the cost pressure. In response to it, one solution is to define product family as the broad product, thus, all previous products become product areas under one product. This increases the transparency, which enables more common components, leading to less duplication. This decreases the development cost, then relieves the cost pressure. This is illustrated by B9-loop, which acts as a force against narrow product definition.

There is another common solution in response to the duplication. We create organizations around potential common components, which drive their usage to make them become real common components, leading to less duplication. This decreases the development cost, then relieves the cost pressure. This is illustrated by B10-loop. As you probably have noticed, this is essentially the case of platform as product - the platform is a component, which has been described in part 1.

B9-loop and B10-loop are two different ways of creating common components, one is to enable it via transparency; the other is to define it. In my experience, it usually works better to emerge than define upfront.


Narrow vs. broad product definition is a big topic and the contextual difference is massive. These two articles (part 1 and part 2) are far from comprehensive. I summarize the major tradeoffs and pitfalls here.

  • Productization is a key drive for narrow product definition. As the right narrow product emerges, we should avoid premature separation.
  • Cycle time and flexibility are main forces against narrow product definition. This applies for both real product and platform/component.
  • Common components and reusable platforms help reduce the development cost, but they are not necessarily defined as product associated with development organization.
  • Narrow product definition may promote local innovation at the expense of holistic innovation.

P.S. While writing these two articles, I gained much insight and clarity from the discussion with Jurgen De Smet, thank you!

What is the product? This is a critical question in organization design. You define the product narrowly or broadly, and the scope of the product is a continuum. We are going to see the factors and dynamics behind different choices in two parts. In part 1, we shall look at the case of platform as product; while in part 2, we shall look at the case of product area as product.

Blog - narrow vs broad product definition 1.jpg

Platform is a popular concept in many product organization. It is often defined as product associated with organization - product backlog and teams. In most cases those are essentially components, as they are not facing external customers. They form one product together with the application. This is illustrated by the left part in the above picture. In some cases those are indeed products, as they have separate external customers than the application. There are two products with different customers. This is illustrated by the right part in the above picture. Let's look at them separately.

Platform is a component

Blog - narrow vs broad product definition 2.jpg

Why does organization want to define platform as product, even though it is essentially a component? For reuse - multiple applications would reuse the same platform, so as to save the development cost. This is illustrated by balancing loop B1. The goal is the cost budget. The action is to create narrow product (i.e. platform) to promote the reuse. The rationale is that platform increases the extent of reuse, thus development cost is reduced, then cost pressure is relieved.

Why does organization NOT want to define platform as product? There is another balancing loop B2 involved. As smaller platforms are defined, more platforms are involved in delivering value to customer. The extent of synchronization gets lower, thus, cycle time gets longer. This creates time pressure, which drives against defining more platforms as products. It is a matter of which balancing loop dominates at certain period.

What's more interesting is that the asynchrony causes the waste of waiting, thus, increases the development cost. That forms a reinforcing loop R1. B1-loop and R1-loop together create "fixes that backfire". While B1 dominates, R1 is in vicious cycle, thus harms the goal of meeting cost budget. While B2 dominates, R1 is in virtuous cycle in helping meet the cost budget too. This dynamic is shown in the below diagram.

Blog - narrow vs broad product definition 3.jpg

Back to reuse, what are alternatives that could still increase the extent of reuse while not defining platform as product? Internal open source is one alternative approach. The most challenge in adopting this approach is its organic nature, which can not be controlled but only be nurtured.

Platform is a product

There is a different tradeoff involved when the platform is indeed a product, facing external customers, besides internal applications.

Blog - narrow vs broad product definition 4.jpg

In this case, the main drive is not the development cost, but the focus and support necessary to bring a product into the market. B3-loop illustrates this. The support on productization includes marketing, sales, budget, etc. Once there is gap, we define platform as separate product than the application product. This increases the product orientation, leading to better support on productization, thus closing the gap.

Meanwhile, this has an impact on application product. As platform goes on its own, the request from application may not be done in synchronous manner. Thus, the cycle time gets longer, which increases time pressure. This is the previous B2-loop, which creates a balancing force against defining more platforms as products.

In reality, platform product emerges much more than being correctly predefined. I have seen that many platforms never became real product. Those that did become real product were seldom predefined. Same as reuse, the platform product is better nurtured than controlled. When done prematurely, it sacrifices the application product, meanwhile does not gain in making successful platform product either.

In part 2, we shall look at the choice of defining as a narrow product vs. as a product area in the broader product.


Seeing the system dynamic: requirement vs. task

One important leverage in coaching Agile teams is to increase the focus on requirement, rather than task. This article describes the dynamic behind it.

Traditional project tracks the progress at two levels. One level is the milestone, which is often associated with stages such as requirement analyzed, ready for integration, testing done, etc. The other level is the task status often through weekly report meeting. In contrast, Agile development tracks the progress in requirements (note: better to track the value of those requirements, but out of this article's scope). We shall see the dynamic behind different choices, and this understanding helps us make successful change.

Why tasks?

There is a reason to focus on tasks.

Blog - requirement vs task 1.jpg

Task focus essentially represents resource focus. When facing cost pressure, we try to increase resource focus, then resource efficiency, so as to reduce cost pressure.

How do we increase resource focus? One way is through tasks. In fact, when tracking tasks, the sequence is often person by person, asking what tasks each person is doing. This makes sure that every person is busy. What if there is no suitable task matching their skills? We create tasks to accommodate their skills. This has intriguing impact as we shall see later.

Why requirements?

There is a reason to focus on requirements too. 

Blog - requirement vs task 2.jpg

Requirement focus represents customer focus. When facing market pressure, we try to increase customer focus, then flow efficiency, deliver more value, so as to reduce market pressure.

How do we increase flow efficiency? One way is through requirements. Instead of tracking tasks and persons, we track requirements and make sure that they are flowing. The focus is less on who's idle and more on how requirements could flow smoother.

The tension

With two separate balancing loops, both goals regarding cost and market could be achieved. However, there is the tension between resource efficiency and flow efficiency.

As we mentioned for resource efficiency, when there is no suitable task for some people in one requirement, we start another requirement with tasks matching their skills for resource efficiency. Please note that it is not resource efficient if it involves learning. Therefore, resource focus has negative impact on customer focus.

It works vice versa. When we focus on customer and pursue flow efficiency by limiting the number of requirements working in parallel, it inevitably creates the situation where some people will have less suitable tasks to do, which is not resource efficient. Therefore, customer focus has negative impact on resource focus. 

Blog - requirement vs task 3.jpg

Now, two balancing loops interact. When market pressure gets higher, customer focus increases, and so does flow efficiency. Meanwhile, resource focus decreases, and so does resource efficiency. Thus, B2-loop dominates. When cost pressure gets higher, resource focus increases, so does resource efficiency. Meanwhile, customer focus decreases, and so does flow efficiency. Thus, B1-loop dominates.

Understanding this tension helps see the resistance in a different way. Even though the customer focus is hard to refute, the underlying systemic structure creates the force against it.

The tension also raises an important question about system goal. For your specific organization, which goal do you optimize - resource efficiency or flow efficiency?

The leverage

Is it possible to achieve both, or take one as primary and the other as secondary but still considered? 

Blog - requirement vs task 4.jpg

Look at how we achieve resource efficiency. We start more work in progress by accommodating the skill at the expense of customer focus. Instead of B1-loop, we could initiate the B3-loop, which expands the skill breadth via learning, and eventually increases resource efficiency. B3-loop does not have negative impact on customer focus, however, learning also takes time. Not surprisingly, the real leverage lies at how effective we could learn and expand skills. 

Blog - requirement vs task 5.jpg

The above is the efficiency matrix from the book "This is Lean". The blue line shows the evolution path towards "The perfect state", first achieving B1-loop (flow efficiency) then B3-loop (resource efficiency). However, many organization perceives their starting point as "Efficient islands", in which B2-loop dominates, thus the evolution path becomes the red line. The red line is hard from change management perspective, as it means the drop in resource efficiency firstly. You either change the perception to start from "Wasteland" as it often actually is, or make sure that the drop in resource efficiency is manageable.

The choice of focus on requirement vs. task is essentially the choice between customer focus and resource focus.

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.


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.


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.

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

  • Blog - cross-functional team 3.jpg
  • Blog - cross-functional team 2.jpg
  • Blog - cross-functional team 1.jpg
  • Blog - revisit feature team 6.jpg
  • Blog - revisit feature team 5.jpg
  • Blog - revisit feature team 4.jpg
  • Blog - revisit feature team 3.jpg
  • Blog - revisit feature team 2.jpg
  • Blog - revisit feature team 1.jpg
  • Blog - narrow vs broad product definition 8.jpg