SAFe is a very practical approach to applying Agile in mid- to large-scale organizations. This is in large part because SAFe implements a number of practices derived from Lean, and that have proven effective in these larger organizations. This article describes how SAFe implements several of these practices. 

Main points

• How SAFe maps to several aspects of Lean
• Which practices SAFe implements, and how

SAFe is popular because it fills a need

SAFe has erupted on the software development scene not due to fabulous marketing as its detractors have claimed, but rather due to the fact that it addresses a need most practitioners in large organizations have intuitively felt and most in the Agile community has denied. The patience of those wanting to become more Agile has well worn thin.  Being told they are “butters,” “shallow,” or “just not doing it right” has just added insult to injury.

SAFe is a manifestation of the Lean-Agile Framework.  Understanding the relationship between these two helps understand why SAFe works and how to adapt it to your needs.

One framework, many practices

One challenge many organizations have with implementing SAFe is that while it is a framework, it has many practices embedded in it.  It is often not easy to tell when the framework ends and the practices begin. The reason this is important to do is so you can make changes to the practices of SAFe as needed while not undermining the framework inadvertently.

Be clear that in reality, the Scaled Agile Framework and the Net Objectives Lean-Agile Framework were developed independently of each other. SAFe did not build itself on the LAF.  One of the reasons that Net Objectives has become a gold partner with SAI regarding SAFe and has SPCs and SPCT’s is that we recognized how SAFe was consistent with the LAF and was therefore following the laws of Lean Thinking and the practices of Lean-Management and Lean-Culture.  This meant that SAFe was not an arbitrary collection of practices that its inventor found useful, but was based on the reality of the laws of software development.

Common traits of Agile at Scale as found in SAFe

Note: As you are reading the following, you should also be looking at the Scaled Agile Framework big picture.

Let’s take each item in the set of principles discussed in the article What traits are common in Agile at mid-scale and above? and see how it is implemented in SAFe.

• Work must be driven from business need and organized in a hierarchy of portfolio, program and team. This one is pretty obvious as it is the distinguishing characteristic of SAFe and readily identified by the SAFe diagram with three horizontal rows – one for portfolio, one for program and the other for team.
  
• Architectural and technical issues must have a representative equal to the business stakeholders of the organization. At the top of the SAF diagram one can see Epic owners and the Enterprise architect as the originators of work to be done.
• Work must be decomposed starting with business capabilities until it is broken down into features. This is perhaps our one point of disagreement. SAFe uses a decomposition of themes > epics > features > stories. We start with business capabilities > minimum business increments > features > stories.  Our advanced approaches on prioritizing work at the portfolio end can easily be fitted onto SAFe without conflict.
• The Product Owner role must be expanded into a Product Manager and Product Owner role. This expanded role is necessary to manage the requirements at the portfolio, program and team level.
• There needs to be an enterprise and system architect roles to manage technical issues. Architecture cannot be satisfied as a peer-to-peer discussion among teams. SAFe specifically calls out these roles.
• Someone needs to be responsible for managing the development value stream. The Release Train Engineer (RTE) is an essential role in SAFe.
• Teams must coordinate via shared backlogs and synchronize on a regular basis. The program and team level structures implement this in one of many possible ways for this to be implemented.  However, at the scale for which SAFe is prescribed, this is almost always the best way to do it.
• It is important to try to achieve cross-functional teams when it is economically viable. SAFe calls for cross-functional teams to the extent possible.  This is a good thing.  However, SAFe allows for any team organization at the team level that enables teams to work off of their shared backlogs while being in cadence to allow for synchronization.
• Planning must deal with expected releases, risk management, dependency management and how to coordinate work. This is exactly the intent of the release planning event in SAFe.
• The proper work flow order, typically including some form of acceptance test-driven development, must be considered. SAFe does exactly this.  The suggested team practice in SAFe is called Scrum/XP to reflect the test-first nature of the workflow in the Scrum teams.

Take a realistic approach and recognize where you are. This includes addressing your ability to accept change, current state of technical debt, degree automated testing and degree of continuous integration. The fact that you should not need to take time to just run tests during the development cycle does not mean that one should preclude doing so if one can’t get everything integrated at the end of a sprint. SAFe is pragmatic here. Recognize that a transition is required from poor testing and/or integration practices to good ones. But the fact that one is making the transition does not mean it happens instantly.

Summary

A number of traits are common between organizations that have become successful at applying Agile to the mid- and larger-scales. SAFe follows these traits, as will any successful adoption of SAFe.