The eighth blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

In this blog, a short description of one workshop from Chapter 11: Guiding The Product Ownership.

Avoid Product-Part Owners

Misconceptions about the Product Owner (PO) role often lead to reduced agility, development bottlenecks, and teams that do not understand the customer domain well enough to make autonomous decisions during a Sprint. 

A common mistake in large product development is having POs who work on a product part instead of the complete product. Although people call such a person the PO, they often work solely on requirements gathering and play the PO role for one single team. Such a team PO manages a team product backlog, and acts as a liaison between the developers and the users, customers and other teams

The more the team PO acts as a go-between documenting and handing off the “requirements”, the less time the team collaborates directly with the users. Instead, the developers must read the requirements to understand the users’ problems. So it is hard for them to deeply understand the user. Poor understanding of the users’ needs makes it hard to make decisions about solutions, and over time the teams become over-dependent on the team PO. As a result, the teams may make many incorrect decisions or become highly dependent on the PO, which then bottlenecks the team’s performance.

Replace Product-Part Owners with a Product Owner

Teams can develop a good customer understanding when they work closely with customers; they can learn about the customer domain, needs, and problems. Better customer understanding will not only result in better solutions but also increase the autonomy of the teams because they can make more correct and fine-grained decisions on their own; this also increases your organization’s flow and adaptability. A good way to promote team-customer understanding is to eliminate the team Product-Part Owner role, and replace it with 1 Product Owner for the whole product. The team POs are promoted to developers and the teams refine Product Backlog items directly with the users ( as e.g. described in LeSS). The team PO is then no longer responsible for “the requirements” but rather is responsible (just like all other developers) for helping the other developers deliver a valuable product increment.

After eliminating the team PO roles, all the teams work with one PO that is responsible for the whole product’s success.

The Product Owner in a Senior Position

To be successful in large-scale development, the PO needs:

  • An understanding of the organization and its market, customers, and users to make informed decisions about investment, priority, and release dates.
  • The mandate to make decisions that will have a substantial impact on product success

The PO’s decisions significantly impact the organization’s financial results. So, consider placing the PO role at a senior management level, for example at the board-1 or maybe at board-2 level. Why? at this senior level, the PO can take responsibility for product success and the financial results for the product.

Figure 0. Example Product Group

Remove Managerial Activities from the Product Owner Role

Many senior roles comprise general managerial activities. In organizational role descriptions, you can find responsibilities including:

  • Appraisals
  • Hiring
  • Vacations planning 🙂
  • Resource planning 
  • Talent development
  • Culture
  • And many more.

Although these activities are all important, not all are directly related to product ownership. Try removing most of the managerial activities from the PO role so that the PO can focus on the product. The PO or the teams perform all product-related activities, and the remaining general managerial activities are done by—yes, you guessed it—managers. Ensure that the PO is outward-focused on customer and user understanding and not so much spending time in internal ‘run the business’ management meetings.

Typical PO activities are:

  • Customer research to understand customer segments, motivations, and purchase behaviors of the targeted customers
  • Stakeholder management and alignment
  • Financial management such as budgeting to obtain resources needed to develop the product
  • Driving the direction of development through the visioning and ordering of the Product Backlog
  • Ensuring the right teams and people are hired to develop the product.

A workshop to start Product Owner role design

The PO role is often a new, full-time role in an organization owing to its accountabilities, responsibilities, and reporting, rather than the addition of activities to an existing role. We often use the following simple workshop format to separate inward-focused management activities from outward-focused PO activities.


Ensure all participants understand the role of the Product Owner and Manager before the start of the workshop.


Invite managers from that work as, for example, product managers, program managers, project managers, line managers, senior managers, and team product owners. 

The steps we usually take in this workshop are as follows:

Step 1. Explain that the workshop’s purpose is to separate managerial activities from PO activities. Ask the participants to form into small groups and write down the tasks (one per sticky note) that they do? You might, for example, use the liberating structure 1-2-4-All for gathering input from the participants.

Step 2. Ask the participants to place the tasks from the previous step along the scale Managerial Focus ↔ Product Focus as in figure 1. Use affinity mapping to identify clusters of similar tasks. When complete, the result should look something similar to Figure 1.

Figure 1Product versus management task focus.

Step 3. Using a Q&A format, facilitate task division the PO, developers, and general management as illustrated in Figure 2. Actively facilitate this step and take the opportunity to clarify any questions or details about the PO activities.

Product Owner vs Management Tass

Figure 2Task separation per role.

Step 4. Closing. Facilitate a group discussion to distill the potential changes required in management and Product Owner roles descriptions. Consider the following questions:

  • How are the current management’s and PO’s activities impacted?
  • What changes, if any, are required for the PO and management role?
  • What first actions can we take to implement this new setup?

You can use the workshop’s outcome to start defining the Product Owner’s role in large-scale development.

In our last blog, we give an overview of:

  • Emergent Framework—coaching approach

The seventh blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

Individual and Team Performance

A Scrum Team is multidisciplinary and contains a whole arsenal of skills and competencies to deliver value to users. The workload on a single specialty is mostly uneven in a complex environment and therefore such teams are very susceptible to bottlenecks. Peak loads on a specific specialty may vary from iteration to iteration. For example, in Iteration N, the team may have a peak workload in the business analysis skill, in Sprint N + 1, it might be testing.

The theory of constraints implies that the system’s performance is going to be limited by the bottleneck. If there is no change to the bottleneck, the system will not improve. When the bottleneck is influenced, the system changes (McKey, Zoe. Think in Systems: The Art of Strategic Planning, Effective Problem Solving)

Note that a bottleneck determines a system’s throughput, and that spending time optimizing non-bottlenecks will not provide significant benefits. Figure 1 shows what a typical team board could look like at the end of the iteration if everyone is equipped with an individual performance strategy.

Figure 1 Visualizing bottleneck in a flow

As you can see, the bottleneck at that moment is in testing because the largest queue is right before it. If such a picture is repeated consistently in a team, then testing is considered a system bottleneck. When the rest of the team continues doing more Analysis and Coding tasks, this will overload the bottleneck even more. This is pointless (a suboptimization) if we want to optimize the system performance.

In other words, team members can be productive on their isolated expertise at the expense of the team performance.Therefore, using the strategy of maximizing individual skill utilization in teams is not optimal in a team context. Instead, create a team where its members can work on multiple kinds of tasks; A team of multi-skilled individuals.

What can you do to help the teams?

Below are some guidelines that worked for us:

  1. Visualize Flow of Work

Visualization is critical for any Agile organizations as it unfolds the queues and helps to optimize the flow of work. In service organizations in contrast to assembly lines, inventory is invisible. It is stored on hardware disks and walking along the office doesn’t give you an overview of how much waste is really being created.

Figure 2Massive Work-In-Progress (WIP)

If we could do just one single thing when coaching a team, we would visualize the flow of the work. As an example, see Figure 2. By visualizing the flow of work one can see the bottlenecks and create awareness.

  1. Introduce a StarMap

starmap is a simple competency matrix that visualizes the cross-functionality of the specific team. It reveals gaps in knowledge, uncovers potential bottlenecks. The rows of the table are just a list of team members, the columns contain the competencies and skills needed to deliver value (see Figure 3).

Figure 3Example StarMap

Ideally, we would like to see two or more stars in each column. Because then the team becomes truly flexible and can fight the peak loads. The combination of the start and the dot is a good one too. If we find columns with no stars, this is a wake-up call. The team needs coaching and assistance; otherwise, they might have quality problems for work in this competence. But the most problematic columns, in which there are no designations (except for books), indicate dependence on external expertise. Dependencies rob the team of autonomy and prevent the delivery of value. Dependencies block work and significantly increase Lead Time and, as a result, reduce organizational flexibility. In our book we introduce a workshop to initialize the StarMap as well as other tips on how to work with this tool.

  1. Use Three Modes of Development

We are convinced that there is no better way to strengthen cross-functionality and simultaneously reduce work-in-progress (WIP) in an Agile team, than by continually working in one of three modes as illustrated in Figure 4 and described in the list that follows.

Figure 1.6Three modes of development.

  • Pair programming: Working on one or more features in parallel in pairs.
  • Swarming: Working on one feature at a time (WIP = 1), not structured, teams self-organize their work. They could work in several pairs or triads or any other way.
  • Mob programming: Working serially on one feature, a technique that has been gaining momentum in recent years. The team is working on one feature at a time using one computer and a large screen / projector.

Mobbing is a single-piece flow activity, and from a flow efficiency perspective the most efficient way to develop, if a team can reduce transaction costs to the point where it becomes economically feasible to work on one feature from start to Done state.

Working in three modes has many advantages. We list just some of them:

  • It is one of the best ways to enable multi-functional learning in a team.
  • No or little extra code review needed.
  • Trust increases, the team is forced to learn to negotiate and listen to different points of view, to come to a consensus.
  • No transfers or losses of information.
  • Collective code ownership.
  • High quality decisions, everyone knows what is going on.
  • Perfect flow, the team works in one feature at a time —one-piece flow (WIP = 1).

The three modes are so counterintuitive that it takes a lot of patience and training to start. To ensure that your approach to the three modes is successful, we have several guidelines in the book.

  1. Introduce Slack Time

Full utilization does not lead to better system performance. Under full utilization, there is no room to absorb variation in work. Let’s say an urgent bug comes into a Sprint; If a team is operating at full capacity they have no capacity left to handle that bug. Under pressure, the team might neglect writing tests, avoid refactoring or create any other form of technical debt in order to complete work on time.

Therefore, we recommend using Slack Time practice described in eXtreme Programming. It is a time buffer that a team explicitly associates in an iteration for unexpected work and multi-functional learning.

A slack task is:

  • a valuable task that helps the team work more effectively
  • and a task that can be instantly postponed for an iteration without doing lasting damage.

Slack Time has many forms and could be used for:

  • Book clubs
  • Self-directed discovery and exploration time
  • Adding tests to legacy code
  • Paying off technical debt
  • Architectural redesign
  • Participating in Communities of Practice (CoP)


The work of solving a complex problem (for example, a feature) with interdependent tasks rarely distributes evenly among the people in a cross-functional team. The solution is a team of multi-skilled specialists. A team of multi-talented people experience fewer bottlenecks as they can help overloaded team members, and therefore reduce the time to solve a complex problem end-to-end. The team develops multi-skilled members by working in three preferred modes: pairing, mob-programming, and swarming continuously. Some other techniques are: StarMap, visualizing the flow of work, and Slack Time. 

In our next two blog posts, we give an overview of:

  • Transitioning to the Product Owner at scale
  • Emergent Framework—coaching approach