Is SAFe the right recipe for your organization?
Is SAFe the solution to becoming Agile?
Whether your large enterprise should embark on the SAFe journey depends on how Agile you need to be and your starting point. Maybe the most relevant question is why you need to become Agile.
Agility works best in a complex environment where it is hard to predict the outcome. The company that quickly responds to feedback in a changing market with unpredictable behaviors wins in environments having no obvious cause-effect.
Changing direction is more manageable if you have only a few teams in a nimble company than when you have a sizeable hierarchical enterprise. Obviously, we have seen how start-ups quickly get market shares with new disruptive technologies. They don’t have the economic muscles of a well-established company, however. The problem for the large company is that they are not as responsive or nimble. But they want to be.
SAFe has the ambition to make enterprises more Lean and Agile.
SAFe is a framework constructed for large enterprises by mashing together several practices such as Lean, Agile, DevOps, UX, Design Thinking, and more. SAFe combines these yummy good practices into a lovely recipe for how large enterprises can become Agile.
Now, the question is: “if you follow the recipe, will it work?”
It is in the eye of the beholder.
SAFe will seem like a monstrosity with hierarchies, handovers, queues, and specialization, impossible to get an overview for anyone who has worked in a smallish company with a few teams.
On the other hand, if you have worked in a large organization used to projects running for years, SAFe can offer a new way to deliver more often. Still, I know people from a project background not enjoying SAFe, thinking the framework is too chaotic without processes where no one has any clue what is happening.
SAFe introduces many good concepts. The problem is the framework introduces way too many great ideas. I notice that trying to understand SAFe; you focus too much on what SAFe tells you to do. The result is that you miss focusing on the Lean or Agile principles. You miss the trees for the forest. Instead of asking yourself, “How can we deliver something of value faster to the customer,” you ask, “Are we following the recipe of SAFe?”. You need to customize the recipe to your liking. However, you need to understand the why before changing the recipe. Most companies implementing SAFe are not there.
So can you be Agile with SAFe? That depends on how fast you need feedback and be able to react. When you write software, you don’t know if anything is valuable until the user tries it for the first time. That is the moment of truth. To not invest too much money, you want feedback as fast as possible to see if your assumptions were correct and test if anyone is willing to buy what you have produced. The longer it takes before you can test your hypothesis, the more money you will have to invest and wait until you know.
In SAFe, the smallest unit is an Agile Release Train (ART), and the recommendation is for a Train to have 50–125 people. An ART belongs to a Value Stream that can have one or more Trains. You can have many Value Streams, and if that is the case, you might need SAFe’s large solution to synchronize across Value Streams. A company with 800 developers might then have eight Trains divided into three Value Streams consisting of 70 teams or so.
SAFe plans in iterations of three months to synchronize delivery using something called Program Increment Planning. The idea is for teams to commit to PI objectives and Sprint Goals.
My experience is that this event, in practice, becomes output-focused. Focusing on what the teams can deliver during these three months. The approach is unfortunate, making the teams focus on writing down estimates and committing to deliverables. It is easy to go back to a fixed scope and deadlines, or project management, because of this. We should avoid commitment to deliverables and focus on goals and outcomes.
In my experience, the focus on having a cadence of three months and committing to deliverables also have another terrible side effect. Lean Business Cases are written and prioritized, perhaps at the portfolio or solution level, usually going through Kanban stages such as funnel, analyzing, implementing, etc. Now, as trains commit to a plan for three months ahead of what work they can deliver, they are very unwilling to accept new high-priority business cases after the planning — causing frustration for the Epic Owners who continuously work on maturing Epics. To add new features from an Epic would disrupt the entire plan for the Program Increment, which means that in the worst case, an Epic Owner has to wait for another three months before any train agrees to work on their features. Then another three months before anything is delivered. Suddenly SAFe doesn’t feel very Agile anymore. Now, if you used to be able to show a working product every twelve months or so, it is still an improvement.
Why then not shorten the Program Increments to be shorter. Let’s say every month. The truth is that aligning all persons in a value stream takes time, and there is a lot of overhead. A PI planning usually lasts two or three days. There are a lot of persons involved, a lot of syncing, knowledge transfer, and upfront work. The overhead and cost would be too much for a monthly PI planning with all these persons involved.
There is no easy way out of this. Adding more persons requires more communication and persons working solely on coordinating. That is what you get with scaling. My experience tells me often; you need to double the number of persons every time you want to double output. You need two teams to double the amount of output one team can do. To get 300%, you need four teams. 400% requires eight teams.
Outcome and output are very different things. However, you need some output to test the outcome. A few teams can deliver more relative to their size than many teams. My experience is that when you add more teams, your feedback loops also become slower. You have to involve more persons, meaning decisions take longer; you get more dependencies. Suddenly a single team cannot take something from start to end user themselves, introducing handovers and waiting times.
Companies that implement SAFe do it because they are not Agile. The orchestration of many teams is an art. Unless everyone has a profound understanding and experience of Lean and Agile, you will likely revert to traditional project management.
Why, you might ask? Because of the complexity of SAFe. You will have politics, dependencies, wrongly formed value streams, old legacy systems, etc. You will have waste. The natural response for most companies used to traditional project management is to try and control the situation by asking for deadlines, estimates, more resources, and follow-ups. The effect is a breakdown of the Agile mindset.
If you need to get quick feedback from customers, deploy weekly and be able to respond very quickly, then my experience is that SAFe will not help you.
If you are happy to have a time horizon of roughly three months and have the money and risk appetite to allow three months of work from 50–120 persons before you know if the teams created anything of value, then SAFe might work for you.
Just don’t believe you can compete with nimble start-ups or companies who have Agile and Lean ideas in the DNA; you won’t be able to do that with SAFe.
“Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
– Thomas A. Edison
