Liberate SAFe's Agile Release Trains with outcome-oriented goals

Focus on the outcome to foster creativity and collaboration

In my previous article, I discussed how the PI (Planning Interval) Planning can be a great event. But sadly it often is the moment when Agile teams are bound to a highly complicated web of feature delivery plans.

Agile Teams bind themselves to a plan that spans multiple Sprints to deliver predetermined features. On top of that, Agile Teams will have to deal with many dependencies. These dependencies make the ARTs even more rigid. The focus is completely on the aim to deliver according to the plans.

All of this isn’t an issue when your product environment is predictable. When you may expect that the features you deliver will meet the demands of your users and you don’t expect many blockers to deliver the features. But how many product environments are this predictable?

I argue this is not why you would want to use an Agile approach. SAFe is supposed to be Agile. It has Iterations to allow for inspection and adaptation. But as long as these are driven by feature-focused PI plans, the options to actually adapt are limited.

Therefore, I proposed to center the PI Planning around why the PI is valuable and define an outcome-oriented goal for the PI. And I suggested only planning for the first Iteration to allow teams to remain flexible.

My article on the topic was quite brief in explaining the consequences of this approach. In today’s article, I will discuss the practicalities and benefits in more detail.

Photo by Tim Mossholder

Determine a PI Goal

To ensure teams have the outcomes in mind, I recommend defining a PI goal. It works just like Scrum where the Product Goal is the desired future state of the product, serving as a target for the Scrum Teams.

A PI Goal has the same purpose. It should help the Agile Teams to assess what they need to do to maximize their chances to achieve the PI goal.

Here’s an example of a PI Goal:

“By the end of the PI, we want to have proven that our idea to create an online reporting tool can actually work. We aim to do this by creating an MVP using actual data.”

A PI Goal like this gives a clear direction to the Agile Teams but also enough space to be creative and collaborate.

Working with outcome-oriented PI Goals works in a different way than with output-oriented goals:

• During the PI Planning, Agile Teams can suffice with planning one Iteration at a time. Instead of planning all Iterations of the PI, the teams can limit themselves to the first Iteration.

• Agile Teams should align on their Iteration Goals (every Iteration of the PI).

• Agile Teams should have one combined Iteration Review to show what they created to the stakeholders and learn what makes the most sense to do next to move to the PI Goal.

This will enable the teams to be more creative in finding the best ways toward their goals and allow them to be more responsive as well. These aren’t new practices by the way. You may notice that this is essentially what the LeSS framework and the Scrum framework say.

It is all about using common sense. By removing the output-oriented multi-Iteration PI Plan and introducing an outcome-oriented PI Goal, you can embrace LeSS and Scrum practices that focus on empiricism, gaining knowledge from experience.

On top of that, the PI Planning event can be radically shortened. You don’t need the multiple planning and review sessions and you don’t need to register the risks. I argue one day should easily suffice for the event.

What’s more, by aligning all Agile Teams with every Iteration Planning and every Iteration Review, you can also remove the inter-team sync sessions. The syncing of the Agile Teams takes place at the mentioned events and there’s no need for more syncing.

Iteration Planning - Determine Iteration Goal

Every Iteration, the ART together has the Iteration Planning event. They discuss the current situation and what would be the best next steps to move toward the PI Goal.

The end result of the discussion should be that every team has defined an Iteration Goal that brings them closer to the PI Goal. Let’s take the example PI Goal from this article:

“By the end of the PI, we want to have proven that our idea to create an online reporting tool can actually work. We aim to do this by creating an MVP using actual data.”

Suppose we are at the start of the journey with this product. We have some assumptions and a rough idea of the architecture. The challenge of this functionality is that it will display everything that happens immediately. As we are talking about millions of payments a day, this is quite a challenge.

The market in which the company operates is particularly volatile. Developments follow each other very fast and the company needs to be on top of them.

The product has the potential to disrupt the market. But it has unknowns that may put the endeavor at risk. Currently, the most important three unknowns are:

• Can this online product actually handle the required capacity? The payment flow is huge. Especially the real-time replication of the data could be challenging.

• How difficult is it to create this product end-to-end? The company doesn’t have any experience with this type of product. They need to reduce the risk of unknown challenges quickly.

• What is the actual need of the customer? Is our product indeed as valuable as we expect? The company needs to verify if the product has potential, but also what functionalities will be most appreciated.

Let’s say we have three Agile Teams in the ART. They have the following topics to address immediately:

• The main concern involving capacity is whether the replication process can manage the load. While other aspects of the product should be checked too, this is unchartered territory and needs immediate attention.

• The other question that needs a swift answer is if the end-to-end solution can actually work.

• Thirdly, they wish to find confirmation that their users are actually interested in this product.

This is why they define the following three Iteration Goals:

• Agile Team 1 wants to prove that the replication process can handle both the expected load.

• Agile Team 2 aims to prove that the end-to-end solution is technically feasible.

• Agile Team 3 will create a mock-up of the functionality to get feedback from the clients.

The three Agile Teams then separately continue the Iteration Planning to define what work they need to do to achieve their Iteration Goals.

During the Iterations, the 3 Agile Teams all work towards their Iteration Goal. At the end of the Iteration, they have a shared Iteration Review.

Iteration Review

The Iteration Review has the complete ART and their key stakeholders as attendants.

The first Agile Team manages to show how the replication works. But two parts of the replication functionality need to be altered to make the solution stable. This requires immediate attention.

The second Agile Team has successfully created a POC of the end-to-end functionality. There’s one small issue with grabbing the data from the data lake. This should be fixed for the first increment of the product.

The third Agile Team has valuable data from the mock-up. The most important feedback is that clients are very interested in the concept and that most of them would like to have the functionality of displaying fraudulent payment attempts first.

The ART and its stakeholders agree to repair the issues and also work on creating the first version of the product. They will focus on displaying all the potentially fraudulent payment attempts. All this information will help the Agile Teams to define their next Iteration goals.

The cycle repeats for every Iteration.

Inspect and Adapt event

At the end of the PI, SAFe has the Inspect and Adapt event. However, when the Iteration Review already has the complete ART and its stakeholders attending, this Inspect and Adapt event may be redundant. After all, it will have the same purpose as how I describe the Iteration Review. Especially when the last Iteration Review of the PI also discusses whether the PI Goal was met and what can be learned from that for the next PI.

Hence, when you focus on an outcome-oriented approach with your SAFe implementation, I suggest dropping this event. It becomes superfluous with the Iteration Review as I propose.

Next PI

The next PI starts with the PI Planning and it has as input all the learnings of the previous PI, including if the PI Goal was met. All of this serves to make an informed decision on what would be the next PI Goal.

There’s also the Retrospective

Until now, I only talked about product-related aspects. I did not discuss the events where Agile Teams inspect their own effectiveness and define ways to improve. This is on purpose because I wanted to focus on creating value. But it needs a brief mention.

You could either continue to have retros as described by SAFe. However, you could also do it as discussed by LeSS, where first you have team retrospectives and then an overall retrospective.

Radical changes

As soon as you move your focus towards outcomes and define outcome-oriented goals, you will need to radically change the way you work. Working towards the outcomes is different from working towards the outputs, assuming the outputs will bring the desired outcomes.

I propose radical changes to the PI layer of SAFe. These changes will however bring many benefits:

• Focus on outcomes instead of features only.

• Increased sense of ownership as everyone is working towards the same goal.

• Increased alignment between Agile Teams as everyone focuses on the same things.

• A higher degree of self-organization within the Agile Teams as they can find their own best way to achieve their goals.

• Shorter but more effective events.

• Fewer events because of redundancy.

• Better opportunities to change course to maximize the chances to achieve the goals.

The PI Planning becomes the event to define the outcome-oriented PI Goal. The other events of the PI are focused on inspecting their progress toward the PI Goal and adapting their approach if needed.

SAFe without a laser focus on features. Is it still SAFe? Who cares. As long as it works!