Introduced in 2011, the Scaled Agile Framework is a knowledge base to help organizations be more impactful. Organizations can overcome problems associated with large teams working on complex projects so they can meet customer requirements in a better way. Agile has proven methods like Scrum and Kanban. SAFe uses these methods with larger teams comprising diverse people to scale Agile to enterprise level.

Scrum and Kanban have traditionally worked well for small groups. But large companies wanted to take advantage of these methods for large groups and cross-functional teams. SAFe came to rescue them.

What does SAFe do?

Large groups sometimes lack motivation and are too habitual of taking instructions from their superiors to take any initiative on their own or work independently. Due to this, there may be unnecessary delays, or innovation may suffer. So, SAFe provides a way to change all this. It is a good sign that companies now allow small sets of people to set their own goals and independently build products. And they want to implement the same freedom at a larger scale to an extensive set of people. But scaling Agile is a challenging task. It can be a tricky business. Implementing SAFe comes with its own set of challenges. We will discuss these challenges in detail in this article. Let us look at some of these challenges companies face while implementing SAFe.

Problems with Scaled Agile Framework

Changing the mindset of the people and the way work is difficult. Problems would exist in an organization even before SAFe is implemented. So, even the most experienced Agile people may need help scaling Agile. Some of the challenges organizations face are as follows.

1. SAFe needs to be more flexible:

Lack of flexibility is one of the significant issues in the Scaled Agile Framework. It only allows a little flexibility required in how different organizations work. It is so rigid that it is not conducive to making any modifications or changes, so you can adapt it according to your organization’s specific requirements. Generally, the team members in SAFe limit themselves to the specific roles assigned to them. So, they need to be more motivated and get the freedom to experiment.

On the other hand, team members grow in other Agile methods because they are given ownership of their tasks and have to take responsibility for achieving their goals. They can use their knowledge, skills, and efforts for the organization’s benefit. SAFe does not allow that. It confines team members to their roles without giving them much freedom or room for experimentation. Further, SAFe puts a lot of emphasis on planning, hierarchy, and standards. So, when SAFe is implemented, it impacts the entire organization at the same time.

2. Decision-making is majorly from top to bottom:

Compared with other Agile frameworks, which are more democratic, the decision-making in SAFe is primarily in the hands of the top management or leadership. So, it becomes quite centralized. This means too much decision-making is left to the project managers, who may feel unnecessarily burdened. This also results in the rest of the team members needing to be more engaged. And not having a part to play in decision-making gives rise to the feeling that SAFe is not much different from the traditional frameworks they have been using thus far.

In SAFe, essential things are handled at the portfolio level and the incorporation of features takes place at the program level. The team is not engaged at this level and once this has been done, the team is expected to create and test according to this. This approach can entice large organizations to believe that the top management knows better about what needs to be done and how to do it than the people who have to do the actual work. This approach could be more conducive to keeping the team members inspired. Moreover, this kind of mindset is totally contradictory to Agile ideas and modern management principles. And this leads to a lack of initiative in the team as they are reduced to mere takers of the orders of the top management or leadership.

3. Identification and prioritization of epics:

There often needs to be more clarity in understanding the meaning of the word epic in the context of SAFe. For other Agile frameworks, epic means large long-term projects. But in SAFe, it is different. In SAFe, epics are significant initiatives of the organization that should be assessed for the possible Return on Investment (ROI) they would bring before they can be started. Such difference in the definition of epic leads to confusion among the team members. According to SAFe, an enterprise needs to “evaluate before initiation.” After carrying out the evaluation, it is time to prioritize the projects based on the returns they are expected to bring. And since a detailed analysis has already been carried out, every project in the pipeline has to be handled as per the priority. This is yet another challenge. Because all the stakeholders need to sit together and decide the priority of the projects, achieving unanimity on which projects have the greatest potential and should be taken up first is a big challenge. This can lead to difficult decisions and tough outcomes.

4. There are layers of processes:

Another challenge with SAFe is that actual problems don’t surface. SAFe asks to implement heavy processes and prescriptions, due to which actual issues get buried. A lot of layers of processes for product development are added in SAFe that only hide the real problems and can be done without. As SAFe emphasizes planning, the coordination work between different teams gets increased. In organizations where the co-dependencies of teams can not be done away with, they have to work with it, but if these co-dependencies can be removed, then the coordination work would get reduced drastically. But SAFe covers it all up by stressing conducting scheduled meetings at set times. This reduces the team’s agility and looks burdensome. This emphasis on meetings and processes also means that continuous learning should be more important. And more meetings and more coordination only add to the project’s complexity and the team’s structure.

5. Issues of autonomy:

A team that has autonomy does not perform as well as the one that has been given autonomy. So, organizations strive to give more autonomy to their teams. Bur in SAFe, it is the other way around. Instead of providing autonomy to the teams, it takes away their autonomy. The features are provided to the team and they have to work around those features, which means they are tied to those features and cannot think or act beyond them. Their focus is on those features rather than on achieving actual results. Sometimes, the features of the next three months are determined as a part of the Program Increment (PI). This binds the team to these features rather than outcomes. SAFe also ties the teams to Release Trains. So, rather than working and releasing them independently, which would encourage experimenting and learning, they become dependent on each other. Work gets distributed among different teams, and once again, that gives rise to the need for large-scale coordination. This, in turn, means that the decisions that could have been taken independently and rapidly have to wait until collective decisions are arrived.

6. Agility and the lack of it:

Agility means being Agile and Agile aims to achieve just that. This implies that the teams should be free to build the product, test it, learn from it, and iterate. The main focus has to be on achieving results. The result may or may not be achieved by specific features. When teams are Agile, they can reset the priorities or change the features so better results can be achieved. This kind of flexibility lets the teams try new things and learn from them as they go. They can then use what they have learned to make changes or adjustments as they build the product. But the processes and planning imposed on the teams by SAFe go contrary to that. Theoretically, the SAFe teams are called design, build, and test teams, but practically, the Product Owner carries out the defining part. The teams have only developers and testers as their members, which can’t be called cross-functional teams.

So, we have listed some significant challenges organizations face with the SAFe framework. The probability of a successful project depends significantly on clear communication within the organization. But instead of encouraging more communication, SAFe only adds more levels of hierarchy which makes things more complicated instead of simplifying them. SAFe puts more emphasis on output than outcomes. The measure of success in SAFe is the teams’ commitment to features and ability to deliver all through the quarter. Organizations need to understand SAFe well. Otherwise, it may look like a project-oriented rather than a product-oriented framework. The answer to these challenges is provided by skilled and experienced SAFe practitioners who can help your organization overcome these initial challenges and take them to new heights through the proper use of the Scaled Agile Framework.