March 2017 Archives

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.

About this Archive

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

February 2017 is the previous archive.

June 2017 is the next archive.

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