Problems with Scaled Agile Framework

In today's fast-paced business environment, organizations constantly seek ways to enhance their agility and efficiency. Agile methodologies have gained widespread acceptance for improving collaboration, speeding delivery times, and increasing responsiveness to market changes. However, scaling agile practices across large organizations presents unique challenges. The Scaled Agile Framework (SAFe) has emerged as a popular solution for addressing these challenges, offering a structured approach to implementing agile at scale.

The Scaled Agile Framework, developed in 2011, is an online knowledge base that helps companies work effectively and rapidly so that their products and services can reach the end customer quickly. It is designed to help large organizations surmount the difficulties of large teams working on complex projects.

How does SAFe work?

A large project is mapped into smaller tasks, tackled in incremental steps called “Sprints.” The team responsible for completing the Sprint works directly with the client and provides a timeframe based on each team member’s input. The client evaluates and gives feedback as each Sprint is completed rather than waiting for the entire project to be delivered. This helps the client be involved in the entire project from the initial stages right up to the conclusion.

Problems with SAFe

Adopting the Scaled Agile Framework comes with a set of challenges. People tend to think that using SAFe will resolve all the issues that arise in project management. The truth is that organizations with fundamental problems in their functioning will continue to have problems, and sometimes, these could get exacerbated. Here are some of the issues of SAFe that one must know about.

1. Not having the right work environment

SAFe is designed for large-scale operations, and it is sometimes easy to overlook the most basic of considerations: the quality of coding. It is non-debatable that, before organizations commit to SAFe implementation, the company’s engineering practices should be thorough and up-to-date. Organizations that do not practice modern architecture, development, and testing techniques end up worse than before.  Teams should also be well-equipped and believe in Agile practices. There should be a collaborative working environment that is happy to accept innovation. Without such a strong base, SAFe implementation is bound to be a disaster.

2. Rigidity

SAFe grants little room for flexibility that may be needed for the way different organizations function. There is a lot of focus on planning, hierarchy, and standards. Once SAFe is implemented, it can affect the entire organization in one go. There is almost no option to keep some functions independent from this wave of change.

3. Increased management layers

The workflow and the processes are complex by themselves; besides, there are several layers of management within each part of the process. In theory, it is to help each part have full control over their area of work. In practice, it slows down the entire workflow because of how teams can function and make decisions.

4. Autocratic decision-making

Another problem with SAFe is that teams are viewed as groups that have a delivery function and are not strategic groups. For example, At the “Portfolio”- the highest level, SAFe supports the funding of an unlimited number of “Value Streams,” which are dedicated to supporting one or more solutions required by the customers. The “Lean Portfolio Management” authorizes the funding and decides which Epics (large initiatives for a significant solution development) move into which value stream. This means that many decisions are made at the top level, not by the most familiar people with the work. 

5. Overly complex

SAFe is so complicated that even someone who has worked and researched for a long time cannot fully understand its features. Despite the many checkpoints, getting all the stakeholders to work harmoniously isn't easy due to varying methods and values. This goes against the very basic Agile principle that “individuals and interactions are more important than processes and tools.”

6. Lack of Role Flexibility

SAFe team members are given rigorously defined roles. Even when it makes sense, SAFe does not support the permanent or even temporary swapping of roles. There is not enough focus on training team members to handle their own needs; instead, the team encourages dependence outside the team. Hence, team members do not develop a sense of complete ownership of their tasks.

7. Always the ‘Big Picture’

SAFe endeavors to focus on the big picture and not get bogged down in details. On the other hand, this emphasis leads to longer planning and delivery cycles in the development phase. Therefore, it is contrary to what a Sprint is supposed to do: deliver new products to the market in the shortest period.

8. Definition of terms

“Customers” in SAFe are not, as one would think, the end-user of the product or service. A broader definition includes financing the value streams and other collaborators with a vested interest. This goes against commonly held design thinking principles, which focus on what the consumer requires.

The term “Epic” was used before SAFe and meant a user story (product specifications looked at from the users’ point of view) that was too large to be managed within one Sprint and needed to be broken down. SAFe defined an epic as “initiatives that are sufficiently substantial to warrant analysis and understanding of potential return on investment before implementation.” The two definitions are completely different and can lead to confusion if not understood properly.

9. Identifying and prioritizing Epics

Since Epics requires detailed analysis before proceeding, projects in the pipeline should be tackled according to priority. Stakeholders must agree upon the epic's definition and purpose. Reaching an agreement on which projects should advance can lead to tough outcomes. 

10. Estimating the duration of an Epic

Because SAFe involves large teams with hundreds of people, the structure tends to have work done in large batches. Being able to estimate timelines is a crucial factor in the process. The duration of an Epic is calculated using inputs from external suppliers and the internal “Agile Release Trains” (ART – is a dedicated, full-time team that incrementally develops, delivers, and sometimes operates one or more solutions in a value stream). It requires extensive collaborative work and understanding of several data points, which can be pretty challenging.

11. Too much focus on planning

“Program Increments” (PI) are a significant part of SAFe implementation. PI begins with PI planning. There are also pre- and post-planning activities. In theory, safe Agile PI planning is a very good idea for people to work out the objectives to be delivered and focus on their dependencies on other teams. In practice, a lot of the planning is based on predefined features where assumptions are made, and the plans often become outdated because of new developments elsewhere. Many commitments are locked during these meetings, and there is no scope to change these, even when new information comes up.

12. Limited Retrospection

Although planning and team retrospectives is are major aspects of the SAFe framework, the effectiveness is quite low. It is impossible to expect members from the Program level to be able to attend team retrospectives consistently. Hence, the required changes cannot be actioned by the people who have the authority to do it. A lot of the retrospective time is spent on “assessment charts,” checking whether SAFe principles are being followed rather than their effectiveness. The process, therefore, becomes more important than the result.

13. Confusing Synthesis of Existing Concepts

Existing concepts like Scrum, Lean UX, and DevOps have been incorporated into the SAFe framework. The synthesis, especially concerning applying lean and Agile principles, has not been straightforward. These principles have been tried, tested, and certified as effective. However, the aggregation result within SAFe is more confusing than effective.

14. Published customer stories

On their official website, there are more than 60 success stories of SAFe implementation. However, there are no published case studies on projects that have not done so well, which shows that the presentation is highly one-sided and does not discuss the risk factors involved. It is important that organizations thoroughly research this framework’s potential downside before deciding whether it is worth implementing.

Here, we have assembled a comprehensive list of practical problems of SAFe. If not understood properly, SAFe would seem to be project-oriented rather than product-oriented. A simplified explanation looks like the goal is to map out processes, features, and output and then work towards delivering them on given deadlines without much thought given to outcomes. Of course, this would not be what an evolved organization that believes in Lean and Agile principles wants to achieve. Skilled, experienced, certified SAFe practitioners worldwide have helped overcome the initial challenges and lift their organizations to greater heights with Agile product development and lean-agile leadership.

Conclusion: 

While the Scaled Agile Framework (SAFe) offers a structured approach to scaling agile practices, it comes with significant challenges. Organizations must navigate complexities, rigid structures, and potential misalignments to implement SAFe effectively. Ensuring a suitable work environment, fostering flexibility, and prioritizing people over processes are essential for overcoming these issues. Tailoring SAFe to meet unique organizational needs and promoting a culture of continuous improvement can help mitigate the downsides. With careful consideration and adaptation, organizations can harness the benefits of SAFe and achieve successful agile transformations, driving efficiency and innovation in large-scale projects.
Simpliaxis offers a variety of SAFe-related courses for those seeking to deepen their understanding and expertise. These courses are designed to help professionals effectively implement and manage SAFe within their organizations, providing the skills and knowledge needed to navigate its complexities successfully.