Scaled Agile Framework (SAFe) is a framework for developing agility at scale. While most companies work with SAFe, others think that this framework is not agile because of its complexity and low flexibility. How true is this? In this article we will discuss the main advantages and disadvantages of SAFe.
When we talk about Agile, we imply a specific mindset that is based on principles of flexibility, simplicity and adaptability. Scaled Agile Framework (SAFe) offers organisational pattern that empowers big and complex organisations use the benefits of a Lean-Agile mindset (Lean, Agile, systems thinking, DevOps) at enterprise level. While many organisations willingly introduce SAFe framework, there are many fears that SAFe isn’t Agile, nor « safe ». In this article we will see the benefits and drawbacks of this scaled framework.
Arguments around SAFe:
1. Too heavy and complicated
It is enough to look at the picture that explains SAFe to be willing to argue how complicated and overwhelming this methodology is. Many levels of management combined with many roles and new terminologies can indeed create confusion. There are tonnes of pages to explain how it actually works and hundreds of trainings materials and videos. While the Agile manifesto creators wanted to find more lightweight way to organise work, SAFe instead made it unnecessarily too heavy, complicated and bureaucratic. It is also argued that when enterprises think of “scaling up Agile”, they are already off the track about the whole understanding of Agile. Agile in essence wants to “descale” management and empower small self-managed teams take decisions.
SAFe is designed for big enterprises that run multiple projects and involve numerous teams, but still wish to implement Agile and Lean principles in their work processes. If the organisation’s structure becomes more complex, naturally, the processes it governs also become more complex. Even if many small self-organised teams already exist in the company, they have to find a way to co-exist and coordinate with each other to not get off-track. Proponents of SAFe state that it helps to scale up and apply Agile to the entire organisation, involving not only developing teams, but also chief executives, finances or HR.
2. Too many of processes
Another criticism states that there are too many layers of processes, up-front planning and heavy top-down approach imposed. Critics argue that complicated structure of coordination events make the framework more “waterfall-like” rather than Agile. The planning meeting Program Increment Planning (PI) takes over two days to discuss and build a roadmap for the next 10 weeks or 5 sprints. Additional numerous interactions are viewed to be excessive and considered more as a waste of time rather that efficient coordination.
Proponents of SAFe argue that even though it adds additional events, the only purpose of them is alignment on the vision and action plan; and this is needed for efficient coordination of complex organisational structures. Without constant communication and collaboration, it’s hard to achieve full transparency, some details might be missed and teams can go off the track, which might lead to even more inhibition and higher costs. The key is to find a right balance, where the meetings won’t be considered a waste of time, but rather an opportunity to put everyone on the same page.
3. Too many layers of management
Additional layers of management in SAFe are considered to add only more levels of unnecessary control and make decision-making more centralised. While Agile tries to give more autonomy to the teams in decision making and risk management, SAFe rules impose more bureaucracy that can lead to confusion and even slow down the overall workflow. Rather than being more independent in their work and decisions, teams don’t have the freedom for manoeuvre, as they comply with the Portfolio Epics and the general Program Increment Planning. Teams are also involved in Agile Release Trains, where everyone is interconnected and dependent on each other, which also slows down work efficiency.
The main motive behind adding organisational layers and new roles is to seek more coordination across multiple teams and hundreds of people that are involved in product delivery and that might be spread across many locations. It might seem frustrating for small teams who already practice Agile, but the existence of these management layers explained by the need to manage more complex projects, rather than a small team of 5-10 persons. If all teams are dependent on each other, SAFe suggests a model that ensures alignment of business strategy and software development, cross functional communication and synchronisation whilst, at the same time, allowing for Agile teams to organise their work within their group as they see fit.
4. Not flexible for change
Many Agile experts agree that the issue in SAFe lies with how it makes the process too rigid and leaves teams unable to rapidly respond to a change. In SAFe, planning and commitments are taken up to 5 iterations (10-12 weeks) ahead. This leaves no room for flexibility in case of needed improvement. As a consequence, it can make the results of a several-days PI planning meeting outdated as soon as participants leave the room. Additionally, the period within which feedback is received is also prolonged, that reduces the capacity to quickly adapt and respond to change.
Proponents of SAFe point out that it is hard to run successfully a big organisation with a two-weeks plan and without clearly defined vision or a roadmap. Working with numerous teams and dozens of people requires a clear understanding for the product development and deliverables at least 3 months ahead of time. For this reason, SAFe provides certain visibility to the business and assures predictable delivery of product increments. Some also argue that big organisations rarely want to change more often than every 3 months. SAFe helps to see a bigger picture and tries find a balance between long-term strategy and short-term flexibility.
To conclude
From first glance, SAFe framework seems to be too bureaucratic and top-down to be called truly Agile. The Agile manifesto promotes simplicity, self-organisation and quick responses to change, which can be well-applied in small Agile teams. However, if the product is very complex, and the organisation counts of dozens of such self-organised teams, it can become more complicated to manage. For these cases, SAFe framework suggests a solution, but is criticised by many for imposing “non-Agile” layers of additional management, control and processes.
If the projects and teams are too numerous to coordinate, aligning the common vision and delivering product increments in certain intervals is necessary. Keep the balance between being flexible and prevent teams from take their own direction as much as possible are challenges that big enterprises face. In these cases, SAFe framework seeks to ensure that a product is consistently evolving, small self-organised teams are in sync with each other and business and nothing is off-course. Even though SAFe might seem far from being fully-Agile, it helps transform and introduce Agile to the whole enterprise. Many organisations introduce SAFe gradually, first within few teams and only one Agile Release Train, to see its benefits and drawbacks in practice. In the end, following principles of inspection and adaptation, every organisation is free to adapt any framework to better suit its context and needs.
