Created in 2011, Scaled Agile Framework is now the market standard for companies that want to extend agile principles beyond a few teams. Its website, which freely offers rich and well-organized content, partly explains its meteoric rise.
This showcase is thus particularly appealing to companies that don’t necessarily know where to start their agile transformation, and are looking for a clear and structured transformation framework. The many certifications SAFe offers also lend credibility to the proposed model, on top of being extremely lucrative for SAFe’s creators.
Setting aside any criticism of the business model, let’s look at the soundness of the SAFe model itself.
In the rest of this article, we will go over the main flaws that can make SAFe ineffective, or even counterproductive, in the field:
- Trains created in abundance
- The lack of guidance on management
- An organization that is too virtual
- An extra layer of complexity
1/ “Agile Release Trains, by the dozen”
After the many rounds of training and certification, the first real step in implementing SAFe is identifying the value streams. SAFe recommends starting from the business need, identifying the IT teams that contribute to it, and then coordinating them through a train. From this rather healthy premise, we quite often see a significant bias when these recommendations are put into practice.
For example, SAFe asks that a train only bring together the teams that need to coordinate with one another. But we often see companies, after analyzing their value streams, group all the teams of a given scope into trains, and not just the teams that need it, so as not to leave any team “alone”.
Two perverse effects then appear:
- teams take part in trains even though they have nothing to share there, or have no real dependency on the other teams
- trains are implemented for only 2 or 3 teams, with no real need for coordination
One point transformation teams sometimes overlook is that a PI Planning bringing together several dozen people for 2 days costs tens of thousands of euros, not counting logistics expenses and the hidden costs of preparation and coordination. It is therefore essential to implement heavy synchronization mechanisms like the SAFe train only when teams need them, and only if that need lasts over time.
A SAFe train should thus be an exception used to handle coordination issues, not the default standard for rolling out agility across all teams.
2/ “Self-managed teams, but with bosses, but we’re not quite sure who”
Like many scaled agile frameworks, SAFe does not directly address the question of management.
Who is the line manager of the team members? The RTE? A team lead? The tech lead? The product owner? Someone else?
No answer is given. In practical terms, this means that a company that chooses SAFe will deploy an entire structure to coordinate its teams and prioritize its activities, but at no point will it question its historical reporting lines, and therefore the decision-making centers of its organization.
What is the point of a PI planning if, at the slightest gust of wind, a team’s manager can change priorities at will by putting pressure on their subordinates?
Although these behaviors are neither agile nor aligned with the leadership SAFe promotes, they are still often a reality in many companies.
By not redefining the role of the boss, SAFe leaves the door open to every possible interference by the line manager within the team. Of course, there is no generic solution that applies everywhere, but not offering any leads on this question causes many difficulties in the field.
3/ “A virtual structure on top of a very real organization”
Following on from the previous point, SAFe does not encourage companies to rethink their organization when they move to agile at scale. After identifying the value streams, SAFe could suggest redesigning the organization along those value streams, and aligning IT teams with business stakes. All the more so since SAFe is well aware of this alignment problem and of the difficulties it can cause:
But the approach it proposes is, on the contrary, to quickly launch a first train and then build a virtual organization made of trains and portfolios on top of the existing teams and departments. This choice, which may seem pragmatic in the short term, causes many difficulties for companies in the long term:
- Alignment: how do you reconcile the priorities and objectives of the hierarchy with the priorities and objectives of the virtual organization decided during the PI Plannings?
- Funding: SAFe recommends funding initiatives and trains, which are virtual structures and often do not exist as such in the organization’s reference systems. How do you allocate a budget to an initiative? To a virtual team? Who is accountable for it? How do you track its spending? How do you actually switch to capacity-based management?
- Handling support/run: SAFe explains that each team must be in charge of its own support, but this vision is not possible in 100% of cases (example: what is the minimum number of people needed to provide 24/7 support? answer: 5, i.e. almost an entire Agile team). By proposing a model that integrates support activities poorly, SAFe sets aside between 10 and 40% of an IT department’s teams and costs, and does not push for their rationalization.
- Shared components: by definition, a shared component is a pooled element that serves many business lines and therefore many different value streams. Which PI planning takes care of prioritizing its activities? How are competing priorities handled? Only with a Solution Train?
4/ “SAFe, or the extra layer of complexity”
One of the structuring principles of agility is simplicity: “Simplicity—the art of maximizing the amount of work not done—is essential”, according to the agile manifesto. By offering a very detailed and structured methodology, SAFe sometimes loses sight of this basic principle. Or rather, by building a methodology that can be applied everywhere, it actually offers a framework that doesn’t truly suit anyone without many adaptations.
Like “ready-to-wear” clothing, SAFe provides, off the shelf, a number of rules, practices and processes that allow a company to structure its activities. But these practices are not always the ones that best suit the company, nor the ones that allow it to transform itself to truly become more efficient.
It is therefore essential to step back from these recommendations and seek advice from experienced (and not merely certified!) consultants or coaches to adapt these practices to the company’s context.
Even if, in our everyday lives, wearing tailor-made clothes isn’t necessarily required, in the competitive world of business, a tailored operating model is an essential lever to make a company efficient.
Conclusion
As with all the other Agile methodologies, SAFe remains nothing more than a toolbox serving the company’s stakes.
The richness and size of this toolbox must in no case replace the critical eye of the transformation team. Other models exist; copying a concept “because it’s in SAFe” cannot be an acceptable argument in a transformation, where the goal is not to “do SAFe”, but to define and implement the operating model that brings the most value to the company.