SAFe: The elephant in the room...

Are you working with, or considering to work with one of the many SAFe models on the market to align your Agile teams across multiple projects? Then I would like to invite you to join me on a short exploration into the foundation of Agile/SCRUM. So that you will understand why it is not really working for you...


Let's do a 'gedanken' experiment: Imagine a single team, working in Agile, using sprints, daily scrums, scrum master, etc. Now, if they only have one project, the project takes a certain amount of Sprints, say half a year worth of Sprints, right? If a second project gets released when they are still working on the first project, what will that do to the cycle time of the remaining work? It most likely will take twice as long, as the team will now be trying to make progress on both projects. And what will it do to the effective cycle time of the second project? Correct, it also will take twice as long. Still with me? Simple and obvious? This is not happening with you? If it is, let's see what is one of the consequences...

If we have the team working on more than one project, what difference will it make if we are able to improve efficiency with 10%? It will most likely be negligible, compared with the damage of working on too many projects and the waste that switching between projects is causing. But then, how much faster are we able to work when we freeze one of the two projects? Now that is significant, at least 50% or more! And we will not do less projects in a year, the second project will not be any later. If anything it will be sooner, often significantly, depending on the losses associated with switching between the projects for this team and other teams around them.
The implication of this is that effective loading of your team(s) is going to be at the basis of any improvement in speed, productivity and/or predictability. But how do we know the loading of your organization? This is a simple question when working with one team, but for  large multi-team organizations, this can be a daunting challenge.
Comes in SAFe. Every SAFe method will tell you how to scale up your organization and how to align the teams with each other. It will communicate priorities to the teams. But how many SAFe methods do you know that start with a good loading model of the organization? With effective tools on when to release the next project and, even more important, when not? I haven't seen them... I see companies struggle with this issue. SAFe is often used to reduce the impact of overload. It helps the teams to keep some overview of the priorities in an overload situation. It is definitely not used as a tool to rigorously prevent overload. 
Remember, the team will still be working on 1 project at a time, every Sprint. But it will definitely also start switching between projects between Sprints if we release only one project too much! This simple statement should be the alpha and the omega of every SAFe implementation, not because it is the ONLY thing that determines productivity, but because it is the foundation, the starting point, the prerequisite to achieve any productivity gains at all. 
Now we have mentioned the elephant in the SAFe room! Every SAFe implementation will tell you that inflow control is important, but no SAFe method will tell you HOW to do it. SAFe is very good in aligning priorities (remember, aligning priorities, not necessarily aligning the actual work!) across teams, but it is also very good in facilitating and managing overload in a single team. 
Why is this problem so difficult to solve within the SAFe context? One of the corner stones of Agile is the productivity (velocity) of every team. And the underlying idea is that if we can maximize the velocity of every team, we maximize the productivity of the organization. Now, there is a little problem here. If we focus on team productivity this almost definitely will guarantee that we will release too many projects. Even worse, that the teams will insist on too many projects! The reason for this is simple, if we do not have too many projects, there might be idle time here and there. Imagine what even a little idle time is going to do with the productivity of a team. Any form of idle time will cause havoc to team-based productivity targets.
So there we are. We have a company where every team has a dazzling good productivity. However, projects take forever and no one is able to tell you if and how much you have overloaded your organization.
So, yes, by all means, go ahead with implementing SAFe, but pay attention to the elephant in the room, do effective release control of projects. How you do that? Ask me!
Now, this is only one and often the most fundamental issue with Agile. I hear many complaints and I see many companies struggle with predictable delivery of projects or integration between SW and non-SW functions. Are you struggling with these or other consequences of Agile/SAFe? I might be able to help. Drop me a not on This email address is being protected from spambots. You need JavaScript enabled to view it. and we can see if and how I can help you.

All blog posts