As SAFe has matured it has also become more complicated. More levels, roles, artifacts, practices, etc. From one perspective, this is a good thing – SAFe is providing practitioners more information. But from another perspective it’s making it harder to understand and use SAFe. We have found that looking at SAFe from the perspective of the value streams in an organization it is both easier to understand and facilitates taking a systems-thinking approach.
SAFe has the following components (the following is taken from the Scale Agile Framework site and is shown in the order they are worked on):
Strategic Themes are differentiating business objectives that connect a portfolio to the strategy of the Enterprise. They provide business context for decision-making and serve as inputs to the Vision, budget, and backlogs for the Portfolio, Large Solution, and Program Levels. The primary purpose of strategic themes is to drive portfolio innovation and differentiation.
An Epic is a container for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval prior to implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup ‘build-measure-learn’ cycle.
Each Value Stream produces one or more Solutions, which are products, services, or systems delivered to the Customer, whether internal or external to the Enterprise. All the words, pages, roles, activities, and artifacts in SAFe exist for only one purpose: to help development teams continuously deliver solutions that provide value to their customer. That, in turn, enables customers to achieve their goals, which is the ultimate purpose of every solution development enterprise. I
A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.
Build an MVP – Based on the hypothesis of the epic, the next step is to implement a Minimum Viable Product (MVP)—the minimum effort necessary to sufficiently validate or invalidate the hypothesis. In SAFe, this translates to the minimum Feature set required to deliver some holistic, but minimal, solution.
The Vision is a description of the future state of the Solution under development. It reflects Customer and stakeholder needs, as well as the Feature and Capabilities, proposed to meet those needs.
A Feature (within context of the MSI) is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.
Stories are short descriptions of a small piece of desired functionality, written in the user’s language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration.
Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.
These are shown in Figure 1:
What is the smallest increment of business value we can realize?
This is an important question that is not answered directly in SAFe. SAFe does emphasize the need for smaller chunks of value. WSJF encourages smaller increments to be built. And there is documentation throughout the site that emphasizes the need for smaller pieces. This is a core tenet of Lean Thinking and is captured by Eli Goldratt’s (creator of Theory of Constraints which can be thought of a parallel of Lean Thinking) observation – “Often reducing batch size is all it takes to bring a system back into control.”
The challenge with not having an artifact that is specifically about capturing the smallest chunk of value that is realizable is that there is no easy descoping mechanism during planning to see if you must build something. Note that the MVP does not satisfy this need. MVPs as defined by SAFe are about “the minimum effort necessary to sufficiently validate or invalidate the hypothesis of the epic.” But his has two challenges:
The challenge is inherent in starting out our portfolio management with epics. They are big and although we have a vision and strategic themes to which they are aligned to, ordering epics is difficult if not impossible. Trying to do weighted shortest job first on epics can only be done as a broad stroke. This is because epics, by definition are big and not all of one epic will be more important than all of another epic.
A reflection on the challenges this model presents
There are a few significant challenges this model represents. The intentions behind “solutions”, “capabilities” and even “epics” are needed at even Essential SAFe but aren’t present. Terms on the business side are also being tied to how they are implemented on the technology side. This is not necessarily a good thing. If an improvement is made in organizing the talent something may change from a capability to a feature or vice versa.
In many ways a term depends upon the context in which it is used and is often overloaded in meaning. For example, Epics may contain something that runs across multiple trains when at “Full SAFe” or “Portfolio SAFe” but are not even present at the “Large Solution” level which is in between the too. And, although not present in “Essential SAFe” they are typically used before features are defined.
While these challenges can be overcome, a simpler way of looking at the artifacts has value.
Focusing on the intention of the artifacts
STRATEGIC THEMES. Businesses need to have long term goals and strategic themes provide a long lasting view for what is being created.
EPICS serve as containers for these views. Potential solutions as well as how MVPs will be used to validate the hypothesis that there is value must be part of an epic.
SOLUTIONS represent the offerings to be made to the customer, whether internal or external. Solutions must have a VISION that describes the solution we are building in terms of both customer and stakeholder needs.
WHEN SOLUTIONS MUST SPAN PROGRAM INCREMENTS we use capabilities to capture the solution behavior.
WHEN SOLUTIONS CAN BE DONE WITHIN A PROGRAM INCREMENT we use features to capture the solution behavior.
VALIDATE A SOLUTION based on the hypothesis of the epic with an MVP.
Two concepts that can simplify the SAFe model
While there is no question that when adopting SAFe everyone involved should be thinking about how do we manifest business agility – the quick realization of value predictably, sustainably and with high quality. The challenge is that SAFe itself does not provide an artifact that represents this. Terms are also overloaded which adds to the confusion. What is needed is the notion of a “minimum solution increment.” That is, the smallest chunk that can be worked on that will result in realization of value. A key tenet of Agile is to descope early. Doing so enables us to focus on the work that is most valuable. See Release Planning in Seven Minutes: Pareto vs Parkinsons to see a case study of why this is so valuable.
Another useful distinction would be to have a ” discovery and definition of value” aspect that’s defined independently of how what parts of technology will be used to implement it. While that is a consideration that must be attended to, it has little relevanace to the business value being defined.