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.

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.