On January 5, 2016, an entirely new version of the Scaled Agile Framework (SAFe) was released to the general public. This was no minor incremental release but actually a large batch with some fundamental changes and improvements.
In past releases of SAFe there was always a combination of minor role refinement, terminology change, and/or revised guidance. Sometimes there were minor look and feel changes on the public website. However, this time a major evolution has occurred. The framework is now more easily scalable to thousands or tens of thousands of Agile practitioners working towards a common set of solutions that require a different level of thinking, coordination, and adoption patterns.
The Journey to V4
To understand the magnitude of this release, the words “thousands” and “tens of thousands” are significant. In SAFe v3 and prior versions, scaling was more aimed toward a smaller scale, offering guidance for only hundreds of practitioners. The previous iteration of the SAFe Big Picture organized the program as well the key roles executing various aspects of it like this:
It was more common to see one Value-Stream (VS) with a single Agile Release Train (ART). As the VS expanded in size due to Agile adoption, you could see additional ARTs form. Because each ART was around 50-125 practitioners, the math worked out. It got a little tricky coordinating multiple ARTs within a large VS, but it wasn’t unreasonable. For small and medium enterprises doing work largely based upon Scrum and eXtreme Programing (XP) concepts, it was a good start for the most part.
However, larger and larger enterprises were starting to realize the value of this framework – while still recognizing that traditional development techniques like Waterfall weren’t going to immediately stop. In addition, many existing enterprises embraced Kanban at many levels in addition to Scrum. The problems were that these weren’t really explicitly called out in v3. Sure, it was implied – and if you dig hard enough you may find an abstract or blog describing an approach or two or some ideas but they weren’t really codified within the framework. So what did enterprise transformation consultants like myself do? Well, many of us experimented with different adoption patterns to fit our client needs. If you are or have been an Enterprise Agile Transformation Coach, you may recognize some of these design patterns used:
- Developing a Portfolio of Portfolios to aggregate strategy, budgets, and forecasting
- Inventing new roles to assist in multi-ART coordination built on existing Program level roles
- Defining new ceremonial cadences to synchronize between Value Streams, ARTs, or traditional Waterfall
- Identifying new artifacts to align all of these new efforts together
- Adding flexibility in the planning or execution of work through flow-based pull models such as Kanban
If any of these sound familiar, then you’re not alone. In the end, the SAFe framework authors recognized the same needs. Finding the common best patterns for this evolution required leveraging the experiences, feedback, and enhancement requests from a diverse set of Agile ecosystems such as:
- Existing SAFe Program Consultants (SPCs) in the field
- Larger and larger private and public enterprises as well as government institutions
- Social communities and existing Business Partners
- Embedded software/hardware customers
With all of this input and the merging of experimental framework derivatives such as SAFe LSE, the next version of the Scaled Agile Framework was born. To clearly indicate the transformation of the transformation program, even the name was changed to SAFe 4.0 for Lean Software and Systems Engineering . The SAFe Big Picture, naturally required an overhaul:
What are the Major Changes in SAFe 4.0?
Now that we’ve covered the biggest superficial difference, I’d like to briefly describe the major differences between SAFe 4.0 and the previous version(s). In my opinion, there are five major differences:
1. New Value Stream Layer
Perhaps the most significant change in the SAFe update is the addition of a Value Stream layer. This optional layer provides additional cadence, synchronization, and guidance, along with new roles and the codified ability to scale to tens of thousands of Agile practitioners working towards a common set of solutions.
The concepts of Solution Intent and Solution Context are called out in this layer. Why? The initial Solution Intent may require multiple solution contexts to consider and deploy as part of the original intent. Platforms or sets of solution providers are simplified examples of this.
Systems Engineering concepts such as set-based design (as highlighted in SAFe Principle #3 “Assume variability; preserve options”) are called out as important things to consider when envisioning the Solution Intent.
Model-Based Systems Engineering – the paradigm that emphasizes visual models for simulation, design, and communication – and the principles that guide this practice are now called out. We used to know this by a different name – Agile Modelling – but it doesn’t exactly have to be Agile per say. It does have to be Lean and just enough to work with external solution providers that may require a minimal level of formalized specification.
Finally, we have the concept of Supplier(s) and Customer(s). This is huge. Suppliers could be internal within a large enterprise – such as business or technical organizational units – or it could be external in terms of parts suppliers or large software/hardware/firmware 3rd parties. The role of Customer is a new called-out addition as well. Agile purists may balk at this with statements like “That’s what a Product Manager/Product Owner represents.” However, that is a misconception. Customers can be indirect (internal facing or proxied by a Product Manager/Product Owner) or they can be truly external to the Enterprise – such as the receiver of the system(s) (e.g. A government institution, or a hardware manufacturer like Apple, Samsung, or Microsoft).
(Stay tuned for a much deeper dive into the SAFe Value Stream level more specific to large organizations.)
2. Kanban Upgraded to First-Class Citizen
Kanban as a flow-based pull mechanism now exists at all levels of the Framework. Kanban systems can be connected together based upon trigger points in the state transition models.
3. New Foundation Layer
SAFe rests upon a foundation of Leadership, Core Values, and a Lean|Agile mindset. The Foundation layer incorporates guidance around Communities of Practice, the SAFe House of Lean, SAFe Principles, and consistent implementation patterns.
Gone are the separated “Architectural Epics, Features, Stories” as planning work items. They have evolved into what they truly are: technology enablers of business capabilities. Enablers can be subset into Architecture, Infrastructure, or Exploration items. As a result separate Kanban systems are not required between Enablers and Business.
SAFe 4.0 calls out fact that a SAFe Portfolio is but a slice of or part of a larger enterprise organization all guided or constrained with a common governance, strategy, and funding mechanisms. In other words, each SAFe implementation program (mapped out in the Big Picture) could be just one portfolio in an Enterprise, which may have several portfolios each with its own SAFe program in place. This is potentially where larger enterprises will get the most value out of SAFe 4.0.
This is just a brief summary of how I myself, as a SAFe Program Consultant Trainer see the big changes in the newest version of the Scaled Agile Framework. Stay tuned for future blogs where I dive into these changes in more detail and why or why not you should adopt them for your organization as part of your Agile transformation journey.
For more information about the Scaled Agile Framework and SAFe 4.0, check out the website.
Implementing SAFe 4.0 with SPC Certification | Upcoming Opportunities
If your organization is using SAFe and you are interested in becoming SPC4 certified, we invite you to attend one of our upcoming public SAFe classes. These highly experiential classes provide the perfect place for you to learn what it takes to train others in SAFe practices and principles, while also giving you an opportunity to share ideas with other Agile and SAFe practitioners and to learn from some of our most seasoned Consultants. The class is designed for middle management, directors, executives, especially at the Program and Project level.