Why we have decided not to use SAFe® anymore
Short version
The purpose of this article is not to say whether SAFe® is a good framework or not for Agile at Scale. It explains why we concluded that it was not suitable for us.
Target audience
Anyone wondering how to get organised in a changing environment and is interested in SAFe® on any level.
Long version
Sometimes, there are things you will learn that will help you throughout your life. And then there are those that only last for a while, as using SAFe® was for us.
To understand how we came to the conclusion that we needed to take a new path, we need to rewind a little. A few years ago, we decided to expand into the BtoB market and offer a new marketplace-as-a-service product. In the world of products, this is what is called a “big bet”. We were not just adapting an existing product like Cdiscount’s B2C marketplace, we were very much taking on a new challenge.
We needed a new organisation for our teams for this launch and we felt we needed a framework that could help us grow while staying focused and aligned. So, we looked at SAFe®, which helped us to structure our approach in a general way, but which ultimately proved to be more of an inconvenience than an advantage.
It’s all about response time
Cdiscount is a company that has always been able to adapt quickly. When events arise that change our perspective, we make every effort to take appropriate action and change our position quickly. Culturally, adapting to change is valued, which means that while our targets change very little, how we achieve them can changes significantly. One of the pitfalls with SAFe®, which we encountered like many other companies, is that issues are handled in two consecutive steps: first, a discovery phase on a PI and, only then, the delivery PI. This makes the value creation cycle take twice as long, which for us means that we were only able to release into production after a minimum of six months. Which, quite frankly, is not very fast.
A tendency to saturate the system
SAFe® also has another rule, which is that a PI’s scope must stay the same for the upcoming quarter with few changes in content. We managed to avoid stopping issues that were in progress, but we had a hard time ensuring that teams’ priorities remained stable. It is not part of our culture to freeze a scope for three months, nor do we think that is a good idea. The world is far too uncertain for what is essentially a mini-batch to be set in stone. While we think it is realistic to prioritise by scope (instead of by sorting) when working with two-week iterations in Scrum, we have realised that it is difficult in practice for us to do this for three months. If a priority changes or a dependency is not anticipated, the scope changes. Since we handled dependencies during the planning PIs and not elsewhere, we realised that changing a priority meant adding more work for teams. We rarely managed to remove something when adding something else, which meant teams became overloaded with work.
A tendency towards imitation
What is good with SAFe® is that everything is described. What is not as good with SAFe® is that everything is described. It is a very rich framework, and that was too rich for us. It is odd that SAFe® highlights Team Topologies, which promotes proactively managing mental workloads, while SAFe® tends to do the opposite. We found ourselves with SAFe-styled, delivery-oriented ARTs, RTEs, and POs and a system team, but it was so complicated in practice that we had people who applied the methodology without really understanding why. It became very hard to get perspective on each unit of the practice so that we could only keep what brought us value. SAFe led us to focus heavily on delivery and deliverables. We were less focused on what our customers wanted and what they expected us to offer.
The beginning of the end
That was when we realised that SAFe® was not suitable for our culture and context. In some way, it even held us back from greater agility and product focus while worsening our teams’ working conditions. We were missing a prerequisite, which was changing our approach to dependency between teams. We chiefly managed them though synchronisation points without looking to break them down.
So, we took advantage of a reduction in the number of teams working on this new product to go down the opposite road. While reorganising the teams, we have broken dependencies between them as much as possible so that we only had to manage those that remained.
Once the value chains were less interlinked, we looked at what benefits the planning PI offered. We stepped aside and took a good look at our problems: changing priorities, a saturated system and people blindly following a framework. In the end, we concluded that it was better to go back to the basic concepts that SAFe® had gathered under its umbrella instead of applying an “all-inclusive” approach. We will tell you about these changes in our upcoming article, “We quit SAFe®: what has changed”.
