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.

Different context, same resource thinking

Almost a year ago, I wrote about "Seeing the underlying resource thinking". It was in the context of large-scale product development. In my recent training and coaching, I face more holistic product development including not only software, but also hardware, mechanical, supplier chain, etc. It is a different context, but we see the same resource thinking underneath their common practices.

In my view, resource thinking can be illustrated by the below assumptions and practices.

  1. People can only work on their speciality, i.e. they cannot learn or learning means inefficiency.
  2. Due to point 1, it is common to have partial allocation, in order to fully utilize people's specialty.
  3. Due to point 1, and work is dynamic, it is common to have temporary group, assuming that people are interchangeable parts, thus, no cost incurred by moving them around.

Putting these into the context of holistic product development, it adds more challenges than software product development.

  • There are more specialities involved. It could even be 20+ functions involved for holistic product development. Many of them only have minor allocation as the need for their speciality is limited.
  • Cross-learning is more difficult. Think about it is relatively easier for back-end developer to learn front-end development, while it is more difficult for mechanical engineer to learn software development.
  • Temporary group is even more loosely organized, it is often not clear who are in the group.

Scrum provides an alternative approach based on different assumptions than resource thinking.

  1. People can learn. The more learning, the better they learn. And the learning helps efficiency.
  2. Due to point 1, every team member is fully dedicated. When there is mismatch between work and skill, people cross-learn and expand skills.
  3. Due to point 1, and believe that team stability is necessary for team's high performance. Stable team is created and it continuously improves.

Considering the context of holistic product development, it is indeed more challenging to apply Scrum literally. We need to think about the principles and apply the art of the possible here. One possibility could be:

  • Identify core specialities necessary for the holistic product development, build a core team around those specialities by having members fully dedicated. Treat the rest as external dependency and support.
  • Keep the core team stable, so that they could continuously improve as a team.
  • Create cross-learning among core team members, at least enable some members to develop themselves into generalizing specialists. I have indeed seen people who could work across hardware, software and mechanical engineering, even though it is rare. For many, it is possible to expand a bit, but that would already be helpful for the flexibility.

Once you learn to see resource thinking, start to apply different sets of assumptions and principles. With the art of the possible, you will find a way forward in whatever context.

Seeing the system dynamic: 1 vs. n product owners

I thought that this choice was essentially the same as the choice of 1 vs. n Product Backlog. When I examine more, I find it worthwhile to write it as a separate topic. As the two most popular scaling frameworks - SAFe and LeSS, they made different choices on this. ART in SAFe and LeSS (up to 8 teams) in LeSS are comparable in size. In ART, there are product manager and team POs; while in LeSS, there is only one PO working with all teams. In this article, we shall explore the dynamic around having 1 vs. n POs.

In the description of ART in SAFe, it states the reason of having team POs.

"At scale, a single person cannot handle both product and market strategy while also being dedicated to an Agile Team. Therefore, the 'PM/PO' team steers the train together."

Let's explore the dynamics of why doing so and what consequences it causes.

Prioritization over Clarification

The below CLD illustrates the dynamic about introducing multiple POs to share the workload of requirement clarification.

Organize people - 1 vs n PO - 1.png

Introducing multiple POs as a solution to reduce the workload of requirement clarification by one PO is reflected by B1-loop, which can read like this:

  • Higher workload of clarifying requirements by one PO
  • More POs
  • Lower workload of clarifying requirements by one PO

Behind the solution, there is a common misunderstanding about PO solely responsible for requirement clarification. In one-team Scrum, it is more a matter of choice, as described in Scrum guide.

"The Product Owner may do the above work, or have the Development Team do it."

The above work includes requirement clarification.

While in multiple-team Scrum, it is more a necessity if we would like to enable one PO to work with multiple teams, as described in LeSS.

"A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, he encourages and helps the teams enter into a direct conversation with true users and customers for clarification. He acts as a connector, not an intermediary."

This alternative solution is reflected by B2-loop, which can read like this:

  • Higher workload of clarifying requirements by one PO
  • More participation on requirement clarification by team
  • Stronger ability of working with customers by team / Richer business domain knowledge by team 
  • Lower workload of clarifying requirements by one PO

The R-loop explains why it is so common to stick with multiple POs. It can read like this:

  • Higher workload of clarifying requirements by one PO
  • More POs
  • More dependence on POs
  • Less participation on requirement clarification by team
  • Weaker ability of working with customers / Poorer business domain knowledge by team
  • Higher workload of clarifying requirements by one PO
  • More POs

If you have read the previous blogs in this series, you must have recognized the system archetype of "shifting the burden" here.

Status Quo of Contract Game

The below CLD illustrates the dynamic about introducing multiple POs from R&D to accommodate the change resistance on business side.

Organize people - 1 vs n PO - 2.png

Traditional way of working between business and R&D is through contract game. Business and R&D negotiate a contract for the release, then, business leaves R&D to deliver the contract. There was no sprint-based collaboration between them before adopting Agile. It means more change needed on business side when you want to have more POs. The resistance ensues and more POs in R&D are created as a result. This solves the resistance problem meanwhile fulfills the need to have POs. The status quo is maintained.

The B1-loop is the quick solution, which can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more POs in R&D introduced
  • the less change needed on business side

The B2-loop is the fundamental solution, which can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more coaching for business
  • the more collaboration introduced between team and business (either as POs or as stakeholders, but the key is to collaborate sprint by sprint)
  • the more value it creates and the more flexibility it creates
  • the less change needed on business side

The R-loop explains why it is so easy to revert back to status quo. It can read like this:

  • the more change needed on business side (more POs needed)
  • the more resistance it creates
  • the more POs in R&D introduced
  • the less collaboration between team and business (as PO-team collaboration becomes internal for R&D)
  • the less value it creates and the less flexibility it creates
  • the more change needed on business side

Again, you see the system archetype of "shifting the burden".

Conclusion

I have seen two common setups when having multiple POs for one product.

In many Internet companies, those team POs are product managers at the low level. They are working mainly on tactical level, not much on strategic level. When they feed teams with detailed specification and UI sketches, the level of team engagement in product discovery is low. This not only misses the opportunity for team to contribute, but also creates barrier to reach shared understanding for delivery.

In more traditional industries, it is common to introduce team POs inside R&D. When they are focused on requirement clarification, they essentially regress to traditional BAs. There are many arguments against BA role, and my favorite is the keynote from Martin Fowler and Dan North in QCon London 2007. In short, "bridges are better than ferrymen".

Be aware of the consequences when you choose to have multiple POs.

Seeing the system dynamic: Sprint vs. PI

Regarding time dimension, SAFe introduces another concept called PI (Program Increment) besides Sprint. This is a super Sprint, by default consisting of 4 normal Sprints plus 1 special Sprint called IP (Innovation and Planning). In Scrum and LeSS (LeSS is still Scrum), there is no such concept, and Sprint is its sole focus. In this article, we are going to explore the dynamic behind Sprint vs. PI.

In order to model the system dynamic around them, we need to first understand the essential difference between Sprint and PI.

In Scrum, planning horizon and releasing frequency are often coupled on Sprint. In fact, this distinguishes the timebox approach from the flow approach in Kanban. However, they are also not fully coupled, as in practice some teams are releasing on Sprint cadence, other teams are releasing more frequently - even continuously, still other teams are releasing less frequently - releasing after a few Sprints.

PI is still a timebox, thus coupling planning horizon with releasing frequency. PI talks about "plan on cadence, release on demand", which is essentially the same as Sprint. Some teams are releasing on PI cadence, other teams are releasing more frequently, still other teams are releasing less frequently.

When modeling, we separate planning horizon and releasing frequency as two variables. And we make the following assumptions.

  • Planning horizon with PI is longer than with Sprint, but shorter than with traditional release.
  • Releasing frequency with PI is lower than with Sprint, but higher than with traditional release.

The below CLD (Causal-Loop Diagram) illustrates the dynamic around this topic.

Organize time - sprint vs pi.png

Shorter planning horizon and higher releasing frequency

1. Why?

As we move from traditional release to PI then to Sprint, we shorten planning horizon and increase releasing frequency. The R1-loop and R2-loop explain the key driving force, which is the flexibility, i.e. the ability to respond to change.

I often heard about comments of not having the need for more flexibility, as their market is rather stable and their customers do not change that often. There is a bit of truth in it, though it ignores the dynamic. The market change is also affected by our capability of responding to change. When the flexibility on our side is low, we try to control the changes instead of embracing them, which leads to the perception that we do not have much change. When one player in the industry starts to increase the flexibility, market and customers are exposed to more possibilities, other players have to follow.

2. Limiting factors

B1-loop, B3-loop and B5-loop illustrate the limiting factors to shorter planning horizon and higher releasing frequency. Combined with R1-loop and R2-loop, it forms two instances of "limits to growth" system archetype.

B1-loop and B3-loop limit R1-loop (towards shorter planning horizon)

B1-loop reads like this:

  • the shorter planning horizon
  • the more change resistance on business side
  • the longer planning horizon

As business side is familiar and comfortable with the contact game, the longer planning horizon, the easier to work with from their point of view.

B3-loop reads like this:

  • the shorter planning horizon
  • the less synchronized
  • the longer planning horizon

As existing structure and capability constrain on how much synchronization we can get, the longer planning horizon, the less demand on synchronization.

B5-loop limits R2-loop (towards higher releasing frequency)

B5-loop reads like this:

  • the higher releasing frequency
  • the higher releasing cost
  • the lower releasing frequency

As releasing cost may be high due to weak test automation, inefficient deployment, etc. the lower releasing frequency reduces the total releasing cost.

3. Leverages

B2-loop, B4-loop and B6-loop provide the fundamental solutions in contrast to B1-loop, B3-loop and B5-loop respectively.

Coaching business side (B2-loop)

It is a big shift from working in contract game to collaborating on Sprint. Coaching business side requires skills and hard work, as well as patience. Regardless of PI or Sprint, close collaboration between business side and R&D, rather than relying on contract negotiation, is essential for achieving agility. Therefore, coaching business side in making the shift is the fundamental solution.

Improving synchronization (B4-loop)

In a scaling environment, many factors make multiple teams out of sync, such as team structure, way of splitting work, ability to coordinate across teams, etc. The fundamental solution involves changing team structure from component teams to feature teams, splitting stories into small, enabling self-organization for cross-team coordination, etc.

Reducing releasing cost (B6-loop)

While treating releasing cost as fixed cost, the only remaining way becomes reducing the releasing frequency. However, releasing cost can be decreased by improving deployment infrastructure, automating regression tests, preventing defects or finding them earlier, etc. These are fundamental solutions.

It is all about status quo

I have not described R3-loop, R4-loop and R5-loop. These are addictive loops in the "shifting the burden" system archetype. There are three instances. B1-loop, B3-loop and B5-loop represent status quo in the old system. R3-loop, R4-loop and R5-loop act as forces to maintain the status quo.

Status quo of contract game

B1-loop represents the status quo regarding the working way between business and R&D. For many organizations, the status quo is that business people do not work with teams on Sprint cadence, while only negotiate a contract with them during release planning. PI planning resembles the traditional release planning and commitment game, thus, makes it more likely to be accepted by business side. Comparing to Sprint based collaboration, this is not good enough. On the other hand, PI as planning horizon is shorter than traditional release, thus a step forward.

Status quo of coordination

B3-loop represents the status quo regarding team structure and coordination mechanisms. For many organizations, the status quo is component team structure and having coordination roles such as project managers to squeeze out value delivery. While Sprint makes status quo unacceptable, PI leaves more room to accommodate status quo. On the other hand, PI provides tools such as big-room planning to increase the coordination capability via self-organization. This enables the synchronization on every PI, which is a step forward than every traditional release.

Status quo of hardening

B5-loop represents the status quo regarding hardening, which is essentially the undone work. For many organizations, the status quo is having a hardening phase to remove any undone work before releasing. The special Sprint (previously even called HIP, where H stands for Hardening) accommodates it, which resembles the testing and bug fixing phase in traditional waterfall project. On the other hand, releasing on PI cadence is more frequent than traditional release, thus a step forward.

In summary, introducing PI may be a clever move as it resembles traditional release, thus reducing the change resistance, while still taking a step forward. On the other hand, it may not challenge status quo enough, thus grind to a halt after its adoption.

Product learning in Sprint review

Sprint review is the Scrum element for which I evolved my understanding the most during the past 10+ years.

There still exists two prevalent but mistaken views.

  • Sprint review is about showcase. The demo could be an effective vehicle for product learning, but showing "good" case, and hiding "bad" case completely miss the point of sprint review.
  • Sprint review is about acceptance. The deep mindset involved is still contract and blame, rather than collaboration and learning.

In my view, the proper focus of Sprint review is product learning.

Levels of product learning

We learn about product from what and why. For what, there are various levels. We learn about story details on acceptance criteria; we learn about release progress on release turndown; we learn about meaningful product slices on story map. For why, we learn about product goal on impact map. Let me explain.

  • what/story, on acceptance criteria

We learn if the team has delivered the right stories. The main learning here is whether we had the shared understanding for those stories. If PO and team collaborate well during the sprint, chances are, PO has already checked this with team. Then, it becomes mainly checking with stakeholders to see if they have the same shared understanding. The results lead to the acceptance or decline, and possibly some improvement ideas on story level, which may become new or updated stories.

  • what/release, on release burndown

We learn if the release is on the right track. This is more about project view than product review. Traditional release burndown helps us understand if the release deviates from the plan, and then we adapt by varying scope, schedule or cost. In an environment where right stories are more known, it makes sense that the learning about delivery progress becomes the focus. Otherwise, we shall go deep into further product learning.

  • what/product, on story map

The learning on story level may be limited, particularly when we split stories for delivery purpose but break the natural size of uses. During initial backlog creation and backlog refinement, you may have done some story mapping and mapped separate stories into user scenarios. Sprint review is the time to revisit your story map. The granularity of discussion is around user scenarios. This reflects better about the progress, as those are more meaningful things for users, rather than separate stories. This supports better in discussing about what's still missing and what's next. This connects better with users as they are more engaging with meaning product slices, which ofter leads to more insights and product ideas.

  • why/product, on impact map

The next level of learning is how much progress we made in achieving why. During initial backlog creation and backlog refinement, you may have done some impact mapping and mapped stories to the goal and measures. Sprint review is the time to revisit your impact map and assumptions. We collect data for the released stories in the past sprints. We evaluate the real impact and come up with next stories to learn or build.

Ways of product learning

Product learning happens with the right people. Besides PO and team, stakeholders such as users and marketing are invited.

I learned the below 4 quadrants of product learning based on what users say vs. do and qualitative vs. quantitative from a former Alibaba product manager Su Jie. 

Blog - product learning in sprint review.png

He puts one example method in each quadrant.

  • Interview, qualitative learning, based on what users say
  • Survey, quantitative learning, based on what users say
  • Usability testing, qualitative learning, based on what users do
  • Data analysis, quantitative learning, based on what users do

Inspired by this, we could organize product learning in sprint review with various ways.

  • demo stories and user scenarios
  • interview with prepared questions
  • survey with prepared questions
  • observe uses of stories and scenarios by users
  • data analysis to understand impact
  • ...

Conclusion

The number of emergent requirements from Sprint review is a reflection of the amount of product learning in Sprint review. My colleague Terry came up with Agility Index that beautifully illustrates this point.

Turn your Sprint review into a product learning session and let your valuable requirements emerge.

User role modeling

User role describes the relationship to the system. 

I read this from somewhere, but could not find its origin any more. In Mike Cohn's classic book "User Story Applied", there is a chapter dedicated on this topic called "user role modeling". It referred to Larry Constantine's work and his book "Software for Use", chances are it is from there. Do let me know if you happen to know.

Anyway, from my recent experience in helping team charter a new project, we encountered an example that illustrated this nicely.

It is a data application for internal use. Some common uses are as below.

  • Sales looks at product information and price information while creating quotation for customers.
  • Sales updates price information.
  • Marketing looks at product information and price information while building marketing campaign.
  • Marketing uploads product photo.
  • Product engineer adds new product information.
  • Product engineer restricts the access to certain product information.
  • Pricing group uploads price information.
  • Pricing group validates price information.
  • ...

It is tempting to define the following user roles.

  • Sales
  • Marketing
  • Product engineer
  • Pricing group
  • ...

Those roles come directly from work, thus, easy to access. However, those do not describe the relationship to the particular system - the data application. Why does it matter? Same roles have different intents onto the system, while different roles have similar intents onto the system. This makes it difficult to understand the system from those user roles. It makes it a lot easier to understand the system when you define user roles in terms of their relationships to the system.

For this data application, in terms of relationship, we define initial user roles as Producer and Consumer.

Considering two major data types in this application - product data and price data, we may refine the initial roles further like this:

Producer

  • of product data
  • of price data

Consumer

  • of product data
  • of price data

Product data contains text data and photo.

Considering different ways of producing and consuming data, we may refine the initial roles further like this:

Producer

  • creator
  • updater
  • controller

Consumer

  • viewer
  • validator

When we consolidate the user roles with those mixed, we end up with the following list.

Producer

  • Product text data producer (by product engineering)
  • Product photo producer (by marketing)
  • Pricing creator (by pricing group)
  • Pricing updater (by sales)
  • Pricing controller (by pricing group)

Consumer

  • Viewer (of both product and price data, by marketing and sales)
  • Product validator (by product engineer)
  • Pricing validator (by pricing group)

Mike Cohn in his book defines user role as "a collection of defining attributes that characterize a population of users and their intended interactions with the system." To me, this is the verbose version of "relationship to the system".

Recent Comments

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

Recent Assets

  • Blog - team PO 4.jpg
  • Blog - team PO 3.jpg
  • Blog - team PO 2.jpg
  • Blog - team PO 1.jpg
  • Work vs. People.jpg
  • Team design vs Coaching.jpg
  • Organize people - 1 vs n PO - 2.png
  • Organize people - 1 vs n PO - 1.png
  • Organize time - sprint vs pi.png
  • Blog - product learning in sprint review.png