Plans are worthless, but planning is everything. Dwight D. Eisenhower.

One of the more misunderstood aspects of SAFe is its Program Increment (PI)/release planning event. At mid to large scale, this is one of the most innovative aspects of SAFe. It greatly increases the opportunity for collaboration, Some misunderstand it and consider it to be inherently a big batch up-front planning mechanism and then infer that the implementation of the plan is also based on big planning. While it definitely can be a bigger planning event than required, it doesn’t have to be implemented as a big implementation.

Unfortunately, many people adopting SAFe focus on its practices and forgets that above all, SAFe should be adopted as a Lean-Agile based framework. To avoid SAFe becoming heavy, it is critical to understand the intent of and principles underneath the planning event in order to keep it effective when things don’t go as planned. We must understand intentions of the planning event and pragmatically look ahead, fostering collaboration and creating a baseline for adaptation for a large organization.

PI/Release Planning

Let’s look at what happens in the planning event. Teams within the release train (essentially all of the people in the value stream of the software being built) get together for two days to discuss the work they will be doing for the next 4-6 sprints. The output of these two days includes:

• The planned backlogs for all but the last sprint (which is used for hardening, innovation and planning the next PI
• The objectives for the PI
• A list of dependencies between all of the teams
• The list of features that will be implemented during the PI
• A better understanding of when releases will occur

When one looks at these artifacts it’s not surprising that one thinks SAFe is just a big-batch, plan up front waterfall in Agile clothing. But the difference between waterfall and the SAFe planning event, one works to the plan and the other uses the plan as a baseline to realize things aren’t working as planned.

The mindset of SAFe® implementation

I’ve already mentioned that SAFe is based on Lean principles. But, first and foremost, SAFe is pragmatic. This means that we do what works, while following Lean principles. Clearly sticking to a plan – “because it’s the plan” doesn’t work. The same could be said about the practices one uses to start any Agile endeavor (whether it be Scrum, Kanban or SAFe). Pragmatism dictates that practices are how you start, but principles are what you use to adjust.

So the SAFe planning event is a start. Sure, we’d like it to work. But we’ve all seen plans break down. The fourth value of the Agile Manifesto is “Responding to change over following a plan.” Given SAFe is Scaled Agile Framework, this means that we must respond to reality when it deviates from our plan. In other words, we adjust our actions to the reality we now perceive in order to achieve the results we want to achieve.

The results of the PI/Release Planning Event

All too many methods focus on the practices we use to start with. But either when you run into challenges or you learn the basic skills of the method you want to start focusing on the results you want to achieve. This moves us from prescriptive to guidance. There is no reason Agile Release Trains (ARTs) can’t do this right from the beginning. The results of the PI/Release planning event we want to achieve are::

• Collaboration
• Dependency identification
• PI objectives (that is, what value we think we will be delivering throughout the PI timeframe)

Collaboration is within the teams, across the teams, and across management. Anyone who has not had the experience of a SAFe planning event has no real idea of the awesome collaboration that takes place. I have seen this one event shift (at least temporarily) the ways an organization works. The biggest shift is in how teams get to see that their management is committed to them because they are present throughout the event, helping them understand what is needed and lending their support to have them achieve it.

Working the plan

SAFe is also based on Lean-flow, so let’s consider how a Lean-flow attitude would help us manage our PI after the planning event. At a high level, Lean suggests we manage our work in three steps:

1. Identify the most important work to be done (this includes finding that subset of our features which may be delivered early so as to achieve value delivered quickly)
2. Allocate the right people/resources to the most important work and start working on it
3. Use a pull system to manage the work flow from product managers/product owners to the team

The trick is to continue this through the PI. Essentially step 1 is a way to create effectiveness and steps 2 and 3 are about being more efficient. The planning event is essentially steps 1 and 2. Let’s walk through how this works. After the planning event we will have the following sprint backlogs:

Figure 1: Sprint backlogs after planning event.

 

Now let’s take these sprint backlogs and have each team make one large product backlog as shown in Figure 2.

Figure 2: Combined sprint backlogs into 1 product backlog per team

Using pull

At this point we can have each team pull from their backlog as normal Scrum would have them do. Note that if everything goes according to plan, we’ll just be working on the teams’ product backlogs in exactly the same way as a normal Scrum team. However, this rarely happens, of course. Instead, some teams go faster and some teams go slower than anticipated. Each Sprint gives us an opportunity to track how we are doing on how our dependencies are unfolding. They also give us a chance to check if our PI objectives are going to be met.

Adjusting as needed

So what do we do when things don’t go according to plan? We adjust. If a dependency isn’t going to be met in time we might have the teams involved work together more. If an objective isn’t going to be met we can decide to either delay the release or we can see if we can cut some scope. But either way, we can adjust. We’re just now adjusting with a holistic view and basing our decisions on what is planned to be released.

What we shouldn’t do is:

• Have people work overtime to make up the shortage
• Figure we can use the Hardening, Innovation and Planning (HIP) sprint to make up for lost time
• Make the teams wrong for not keeping their commitments

Shorter PIs are good in the same way shorter sprints are

The planning event is to provide us the collaboration and big picture we need. It is not meant to be big planning up front. We often recommend to our clients to use 3 sprints plus a HIP sprint that can eventually be reduced to a week as the need for hardening is eliminated and the innovation gets integrated into the first three sprints. This speeds up learning and enables organizations to eventually do two PIs per quarter.

Summary

The key to remember is the mindset from which you come in implementing SAFe. If it isn’t Lean, you won’t implement SAFe in a Lean way. If it is, you’ll manage to use the SAFe practices as a starting point for developing pragmatic Lean practices. Use the planning event to get the collaboration, dependency identification and PI objectives. Then use Lean to achieve as best you can.