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

How does SAFe work?

A large project is mapped into smaller tasks, which are 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 wait for the entire project to be delivered.  It 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 of the matter 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 problems of SAFe that one must know about.
 

◦ 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, which is 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.

◦ Rigidity
 

SAFe grants very little room for flexibility that may be needed for the way different organization functions. 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.

◦ 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 the different ways that teams can function and make decisions.

◦ Autocratic decision-making

Another problem with SAFe is that teams are viewed as groups having a delivery function and not a strategic group. 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 funding is authorized by the “Lean Portfolio Management,” which also decides which Epics (large initiatives for a significant solution development) move into which value stream. It means that many decisions are made at the top-level, not by the most familiar people with the work. 
 

◦ Overly complex

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

◦ Lack of Role Flexibility

Team members in SAFe are given roles that are rigorously defined. 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 but encourages dependence outside the team. Hence team members do not develop a sense of complete ownership of their tasks.

◦ Always the ‘Big Picture’
 

SAFe endeavors to focus on the big picture and not just 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 the idea of what a Sprint is supposed to do: which is to deliver new products to the market in the shortest period.

◦ Definition of terms
 

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

The term “Epic” has been in use 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.
 

◦ Identifying and prioritizing Epics
 

Since Epics need to have a detailed analysis before moving along, projects in the pipeline should be tackled according to priority. Stakeholders have to come to the discussion table and agree upon the definition and the purpose of the epic. Reaching an agreement on which projects should go ahead can lead to tough outcomes. 

◦ Estimating the duration of an Epic
 

Because SAFe involves large teams with several 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.

◦ 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, 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 of the commitments made are locked during these meetings, and there is no scope to change these even when new information comes up.

◦ Retrospection is limited
 

Although planning and team retrospective is a major aspect 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.

◦ Synthesis of existing concepts is confusing
 

Existing concepts like Scrum, Lean UX, 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 result of the aggregation within SAFe is more confusing than effective.

◦ Published customer stories
 

There are more than 60 success stories of SAFe implementation on their official website.  However, there are no published case studies done on projects that have not done so well, which shows that the presentation is highly one-sided and does not talk about 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 tried to put together a comprehensive list of practical problems of SAFe. If not understood properly, SAFe would seem to be a project-oriented rather than product-oriented framework. 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 the world over have helped overcome the initial challenges and lift their organizations to greater heights with Agile product development and lean-agile leadership.

Simpliaxis is one of the leading professional certification training providers in the world offering multiple courses related to Agile methodologies. We offer numerous Agile related courses such as Certified ScrumMaster (CSM)® Certification Training, Certified Scrum Product Owner (CSPO)® Certification Training, Certified Scrum Developer (CSD) Certification Training, Agile and Scrum Training, PMI-ACP® Certification Training, Professional Scrum with Kanban™ (PSK) Training, Certified Scrum Professional® - Product Owner (CSP®-PO) Certification Training, Agile Sales Management Training, Behaviour Driven Development (BDD) Training and much more. Simpliaxis delivers training to both individuals and corporate groups through instructor-led classroom and online virtual sessions.