SAFe® and agile values

Av Magnus Ahlgren
If you implement SAFE in your organization, will your organization become agile? This article tries to unfold this topic by exploring SAFE from the perspective of the agile principles.


The Scaled Agile Framework® (SAFe®) for implementing Agile, Lean, and DevOps practices at scale has been widely adopted by organizations and companies desiring to apply an agile approach in order to reach business objectives. It cannot be argued that SAFe® has had a large impact primarily on software intensive companies. An attractive package supported by comprehensive training programmes along with different certification options has laid a strong foundation for its success. 

Now, SAFe® has been around for quite some time and its wide-spread application has turned SAFe® to more or less a standard for scaling agile software development. This means that organizations are gathering experiences and the software industry is on a steep learning curve. In essence there are lessons to be gathered for the software business in general as well as for individual organizations. One thing we know for sure is that implementing SAFe® does not come for free and it does not come easy. Furthermore, as any paradigm, framework or model, SAFe® is not a silver bullet.

Implementing SAFe® will have a large impact on busines and software development. In order to stay competitive, it is crucial to challenge the applicability of SAFe® as well as the way it is being implemented in the organization.

In a series of articles, we will, based on our experiences, investigate different aspects of implementing and applying SAFe®.

Values in the agile manifesto

This first article is related to the items to be valued according to the agile manifesto (listed below):

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Will an implementation of the SAFe® framework make an organization adhere to these values? In short, the answer will be “It depends”, but we can ascertain that it cannot be guaranteed. 

Individuals and interactions over processes and tools

In the agile manifesto, the first item to be valued is individuals and interactions over processes and tools. You could argue that the four items to be valued are not in any particular order of priority, but I would beg to differ. I think that this item is the very core in the agile culture and the actual starting point, when requesting something different than traditional waterfall development.

Sadly to say, this item is in my opinion the one with the largest number of pitfalls. SAFe® is an extensive and comprehensive framework. This leads to that it is not easy to understand in all its complexity, which in turn lead to that it is not easy to effectively implement in an organization.

If it is difficult to grasp the framework, how all the bits and pieces should fit together and what is the real essence of the framework you tend to do what you comprehend. What is well described and fairly straightforward are the events at train level. The easy thing to hold on to is to focus on implementing train events (there are quite a number). 

Furthermore SAFe® outlines a vast number of roles at various levels in the framework. Even with all nice graphs and elegant descriptions it is not a piece of cake to figure out the responsibility of everyone in their different roles and how they should interact in the most effective way. It is easy to get stuck in role descriptions and delineation of each role in favor of realizing the potential of interacting individuals.

The risk you face is that introducing all events and new roles is done with such rigor that you miss out on the actual intent of having individuals working effectively together.

The risk you face is that introducing all events and new roles is done with such rigor that you miss out on the actual intent of having individuals working effectively together. You may actually get an organization obsessed with executing a role conducting meetings and executing events and not getting the job done. This is sometimes referred to as the “checklist syndrome”, i.e. focus on ticking off a certain step in a model. Instead of individuals over processes and tools you could end up in ceremonies and meetings over individuals, i.e. just the opposite of what is intended.

Working software over comprehensive documentation

Focusing on working software sounds like heaven to any software developing organization and it has also been the centre of attention in the agile movement. This has also led to the evolution of widely accepted delivery concepts such as Scrum and DevOps. Conceptually this is also very well integrated in SAFe® including both Scrum and DevOps as cornerstones in the Continuous Delivery Pipeline.

Whereas SAFe® is quite elaborate on roles and ceremonies for individual teams and trains from idea through PI-planning to daily work in the teams, it provides little support and insights into how an organization should master releases at scale. As we all know, to get working software in production, mastering releases is key. 

In order for releases to work at scale, I would argue that the first value should be shifted around, i.e. processes and tools over individuals and interactions. The rationale for this is that this is much about automation. Firstly, the release process is about understanding and managing all the steps from function testing through to release in production. Secondly managing releases effectively heavily relies on the appropriate sets of tooling for managing builds etc. Combining a lean process together with tools that are fit for purpose will make you well equipped to provide your customers with updated software on a regular basis. Mastering this for stand-alone team, with a clear architectural scope and full control of the technical environment could be quite straightforward. As stated above there are concepts to support release of working software. However, in a large organization with many dependencies, integration points and different technologies this is a totally different ballgame.

The risk you face is that you don’t realize up front that SAFe® provides little concrete support related to the actual release process. As previously mentioned, SAFe® contains a set of dedicated roles. Many of them are related to managing individual trains. Some of them are having a broad responsibility, e.g. enterprise architecture.  However, there are no clear roles in SAFE for managing releases at scale. To me it is also somewhat confusing that e.g. the Release Train Engineer (RTE) does not have a clear responsibility related to release management. In short, the recommendation is to start working on improving and aligning release practices and tooling as soon as implementation of SAFe® is initiated. 

More could be said about documentation and SAFe®, but I consider management of releases is the main risk herein.

Customer collaboration over contract negotiation

Having been in software business for many years, tedious contract negotiation has always been a dear companion. Based on these experiences, I would sincerely support any measure to increase collaboration between customer and supplier. In reality there are often however many constraints e.g. different corporate cultures, competition between suppliers and procurement regimes. 

SAFe® recognizes the need for customer centricity and distinguishes between general solutions for a market and custom-built solutions, the latter being the one primarily referred to in this value item. 

Having said that, apart from mentioning the need to focus on customers, SAFe® provides little guidance on how take customer collaboration into account when implementing the SAFe® framework. There are no descriptions of explicit practices and there are no roles taking the customer view clearly into account. One example is that the focus on the role Business Owner is on the internal process, and little is mentioned on how customer collaboration should be taken into account.

The risk you face has less to do with SAFe® itself than on the very fact that customer collaboration often does not come that easy. As stated above there are many constraints that SAFe® do not and in my opinion should not cover. This is something you need to work with throughout your organization regardless of SAFe®. In short SAFe® does not provide you with much guidance.

The built-in cadence is however one characteristic of a SAFe® implementation where every organization need to pay special attention. If you and or your customer are working according to SAFe®, expectations management will be key. Since priorities are set for a period of perhaps 10 weeks at a time in so called product increments without strong commitments beyond this point, it is not an easy task to ensure that involved parties will get satisfied with progress. In such a context, how do you ensure that long term objectives will be reached?

Responding to change over following a plan

Most persons with a few years in software industry can share painful stories related to responding to changes in software intensive projects. No matter if it has to do with cumbersome change board meetings, a vast number of documents to update or fierce customer negotiations, frustration has been part of the game. 

SAFe® provides you with a set of concrete set of practices to support the possibility to respond to changing busines needs and priorities. PI-plannings gives an organization the possibility to adjust its priorities for every product increment (e.g. 10 weeks). WSJF (Weighted Shortest Job First) and other tools are in place to support decision making. Furthermore, SAFe® contain practices related to breaking down features into stories and allow for the teams to adjust priority of work on a regular basis, e.g. at the start of every new sprint.

SAFe® also contains a set of concepts, such as Epics to support changes in initiatives at a more strategic level. However, as the framework move into more strategic topics, less tangible gets the descriptions. In short this means that at these levels each organization must find their own way to maneuver. 

Even if SAFe® offers some good support as described above, you should be aware that during a product increment change does not come easy. Each train and each team have set their respective PI-objectives with committed deliveries. Making changes that involves several teams or even worse several trains can be as painful as ever before.

The main risk you face is however rather related to more complex, longer-term investments with target deadlines. These are circumstances where it is necessary to look ahead, make principal considerations and set target plans. With detailed guidelines to plan for the forthcoming product increment as offered by SAFe® it Is easy to get stuck in the method and get lost in the nitty gritties. In the worst scenario you don’t achieve the intended value of responding to change over following a plan, but rather responding to change without any plan to follow. 

Closing words

SAFe® has, as described in the beginning, grown into a de-facto standard for scaling software. It obviously has many merits, and the framework has been successfully rolled out across the globe. Since usage is so widespread it is important to reflect about what you get when selecting SAFe® as a strategy. 

This article argues through some examples that implementing SAFe® does not necessarily provide you with the agile capabilities you may be striving for. Furthermore, If you when implement SAFe® consider its potential drawbacks, you may avoid some of the pitfalls others have stepped into, thus becoming a more successful software organization.

If you find this article interesting you may also look forward to the next article in this series that will explore to which degree SAFe® support large initiatives. 

Magnus Ahlgren
Magnus Ahlgren