How to Make SAFe Work in the Real World
Introduction
SAFe (Scaled Agile Framework) is meant to bring structure and alignment to large organizations, helping teams work together efficiently. However, in practice, it often comes with challenges that don’t appear in training materials. As a Scrum Master and RTE, I’ve faced many of these firsthand—teams struggling with alignment, architects not being transparent, and the constant pressure to balance ongoing work with new ideas. In this post, I’ll share my experience and insights on making SAFe actually work, not just on paper but in reality.
Making SAFe Work in the Trenches
1. Transparency Isn’t a Given—You Have to Dig for It
One of the biggest issues I’ve encountered is the lack of visibility from architects and other key roles. While SAFe promotes transparency, in reality, people often don’t share their progress unless asked. To address this, I’ve had to be proactive, setting up regular check-ins, asking specific questions, and making sure that what’s presented in PI planning reflects actual progress.
The four Core Values of alignment, transparency, respect for people, and relentless improvement represent the foundational beliefs that are key to SAFe’s effectiveness. Together they help guide the behaviors and actions of everyone participating in a SAFe portfolio. As an RTE, Scrum master AND together with those in positions of authority, you can help the rest of the organisation embrace these ideals by exemplifying these values in their words and actions.
2. Aligning Teams Is an Ongoing Battle
A SAFe train should operate as a single unit, but teams often focus too much on their own backlogs. This results in dependencies that slow everything down. I’ve found that emphasizing cross-team communication during PI planning and regular syncs helps. Creating an environment where teams feel accountable not just for their work but for the train’s overall success is key.
Some specific ways to create and maintain alignment in SAFe are:
Of all these, although they work best together, the most important for an agile team is to understand your customer. This alone will allow you be in check with what the product has to be. Understanding the customer will allow the Product manager create the features backlog; it will allow the Product owners cascade down the objectives to the team; ultimately, it will allow teams to feel purposeful and feel the make a difference by creating value to the client(s).
Furthermore, I find that a sense of purposefulness is the glue that hold teams together, allowing them to pull towards the same goals and therefore plan accordingly. Which leads us to the next point.
3. Continuity Planning Is Critical
A common struggle in SAFe is ensuring that work continues smoothly between PIs. Some teams have clear roadmaps, while others struggle to find meaningful backlog items. Instead of letting these teams stagnate, I’ve worked on fostering a pipeline of continuous improvements, making sure there’s always valuable work lined up. Sometimes it’s tough, though. Having an absent client, for example, will make it really hard for your train/teams to plan future work and make the work they find, somehow, purposeful.
Therefore, your main concern would be to find out who your client is. Embrace “your customer is whoever consumes your work” and exploit their needs and improvement ideas that they can bring in order to fuel your backlog. Be relentless in understanding their needs, build KPIs in order to understand what they don’t know - and this is how you could form a good picture of what has to be worked on.
4. Metrics Matter, but Not Just for Show
As an RTE, I’ve had to define KPIs that actually help teams improve rather than just generate reports for leadership. Things like lead time, quality metrics, and team engagement give a clearer picture than just velocity or story points. Metrics should drive action, not just be a checkbox. Don’t fall into the trap of delivering KPIs to feed management’s fear of the unknown or answer to their micromanagement tactics.
Always seek to understand why a KPI is needed and how it is used before providing it. This is easier said than done. What if you just started a position as an RTE and you need to continue providing KPIs to the management? Of course you will not stop providing them just because you do not understand them. But in time, your goal is to understand what is being done after they are being reviewed and what are the repercussions of the numbers you provide (e.g. If you provide the velocity for multiple teams, will the management try to compare the velocity of two teams? If yes, explain them why it is not a good idea to do so and how velocity works).
Conclusion
SAFe, like any framework, is only as good as how it’s implemented. Challenges will always exist—whether it’s a lack of transparency, misalignment, or teams struggling with continuity. The key is to stay proactive, ensure real collaboration, and focus on meaningful improvements rather than just following a framework blindly. Agile isn’t about processes; it’s about people making things work together. And that’s where the real value lies.
You might also like these articles:
