How SAFe's PI-planning can make ánd break your Agile Transformation

SAFe (Scaled Agile Framework) is a quite populair Agile scaling-framework. I'll get into the reason for scaling in a minute. But first, let me tell you what you will get out of this article.

If you're looking for someone who's going to bash SAFe, you're in the wrong place. If you expect me to bring hail and praise to SAFe, you're mistaken as well.

What I would like to bring to you in this article is reasons why SAFe's PI-planning is a great idea for accelerating your Agile transformation. Also, I would like to bring reasons to you how this event could slow you down and possibly even bring you to a halt if you're not careful.

Scaling?

So let's start out with scaling in general. You hear people talking about it a lot and there are lots of frameworks out there to help you out.

Scaling Agile is about dealing with dependencies between teams who are working on the same product, code base or infrastructure. Forget about all the other reasons that you hear about: like stimulate working towards a common goal or making sure all the teams know what they need to do for the next three months.

Scaling Agile is about dealing with dependencies between teams who are working on the same product, code base or infrastructure.

Scaling can be necessary because Agile teams need to be relatively small to stay agile. Scrum teams consist of 3 to 9 members and therefor if you are working with multiple teams on the same product or service, you might need to scale.

First thing you need to do is see if there are relatively easy ways to deal with these dependencies. Maybe you need to re-arrange your teams in a way that they are able to deliver from concept to cash, through a value chain. These teams are called feature teams. Sometimes a Scrum-of-Scrums is all you need.

Scaling frameworks

However, you might need some more structure to help you deal with the remaining dependencies, because with these small teams there will always be some dependencies. There are a number of scaling-frameworks that can help you out. I won't dig to deep into all of them, because you can find a lot about that on the internet, but it's nice to have some overview.

These are the well-known (don't know about usage) in the Agile world:

SAFe (Scaled Agile Framework)

LeSS (Large Scaled Scrum)

Nexus (from Scrum.org)

The problem

"So, what is your problem?" is what you might be thinking right now. Well, suppose you have 15 teams building great software and services, but there are a lot more ideas and work to be done than those teams can handle! Being part of a large Agile transformation, (not implementing SAFe per say) one of the Agile Coaches (Gregor Heidinger, you should check him out) introduced the PI-planning to us. It's an event used to minimize dependencies in large scaled agile organisation and part of the SAFe toolbox. We started the PI-planning as a way to make all the work transparant and the choices we needed to make to prioritize work.

Note for the SAFe professionals: no we did not have release trains, no extra roles like RTE, no product management, no synchronized sprints, no architectural runway, no value streams... none of that.

We started the PI-planning as a way to make all the work transparant and the choices we needed to make to prioritize work.

The Satir model

When dealing with change, it's a good idea to look at the Satir model, created by Virginia Satir. This model explains what happens to performance when we create change in organisations. It helps you understand what will happen when you introduce a foreign element into an organization.

The horizontal axes represents time. The vertical axes represents performance.

The foreign element as a solution

The PI-planning is a great foreign element that can create a new wave in your transformation. It will create chaos, people will disagree, they will argue it takes too much time and is not necessary and a waste of time. But it turns out to be a great way to create transparency in a great number of areas:

1. The work that is created by the organization vs the teams that need to perform the work and what the balance is between the two.
2. The way teams are able to plan and execute the work that the organization created.
3. The way the organization is capable of creating an order in prioritization of work.
4. Possible risks that emerge and can be mitigated from planning the work.

Positives

Besides from the transparency on all those levels, which is a big plus, there are more benefits, which are not reasons for scaling, but are a positive side effect of this event:

• The positive vibe that emerges from an event like this. Everyone sees which teams are involved. It's a great way to get to know each other and to help each other out;
• Collaboration on a higher level than teamlevel. Because all the teams are involved and all teams are visible in a large room, collaborating is much easier;
• Critics of an event like this will claim it is too expensive and takes too much time (100+ people for one or more days). However, the fact that everyone involved and needed for planning the work is in the same room, the efficiency is immense. Just think about the time it will take when teams who are dependent on one another plan work via sending emails and having meetings with different groups of people. It will take way more time and effort to get everyone on the same page and get dependencies between teams out of the way.

Chaos

The chaos that emerges from this change is no more than a logical result of creating this foreign element in the organization. Experiencing this can be a great sign that change is happening. Of course it is important that the benefits outweigh the elements of chaos and that you use this momentum to engage in conversation, feedback and continuous improvement, so the performance will improve and ultimately become the new status quo.

Status quo

So now we get to the real downside and risk of doing this. The risk of any foreign object in the Satir model: the status quo.

You want to continuously improve and create an organization that is continuously learning. Having a new status quo doesn't help. It becomes the new way of working, thinking, planning etc. The problem is that you are not agile if you plan the work every three months. You are not agile if you synchronized your Sprints. Every three months new work emerges for the teams, while they are still working on the current quarter (and sometimes even the quarter before). And now it becomes hard to change this current status quo, because the organization is working on the current quarter and the quarter before, while work needs to be prepared for the upcoming quarter. So you cannot change the process of the upcoming quarter, but only the quarter after that.

The risk of any foreign object in the Satir model: the status quo.

Tips and tricks

Let's wrap up with some tips and tricks that can help you bring continuous change in your organization:

1. When you plan to bring a foreign element in: don't think this will solve your problem. Maybe it will help, but the organization will change as well, so you will need to adapt sooner than you think;
2. The PI-planning is a great way to create transparency on lots of area's, but it won't solve your dependency problem; collaboration will. And the PI-planning can help stimulate collaboration;
3. Inspect and adapt constantly. Make sure when you plan an event like this, people are aware that it will not solve everything, things will need to change and people need to know;
4. There will always be criticism, it's like that with change. Focus on the outcome, visualize and celebrate success and be ready for continuous improvement.
5. The PI-planning within SAFe is part of a bigger framework. Use it as a toolbox and find out what you need to make it work. Less is more and try to focus on what problem you are trying to solve.
6. Be ready to continuously shorten the feedback loop. Maybe you can start out with a quarter, but immediately look for ways of shortening feedback, dependencies and cadence.
7. Change is hard, but also fun! Don't be al too serious about all the hard stuff, enjoy the ride!