This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
4.5 Things to Like about the Latest Release of the Scaled Agile Framework – SAFe 4.5
Do we really need a new version of the Scaled Agile Framework® (SAFe®)? When I first heard that SAFe 4.5 was in the works, I didn’t think so. But as I watched SAFe 4.5 develop over the last several months, I found a lot to like about it. Here are 4.5 things to like about the latest release of the Scaled Agile Framework – SAFe 4.5:
SAFe 4.5 for Lean Enteprises
1. More “configurability”
SAFe 4.0 introduced “3/level” and “4/level” SAFe. A challenge with that approach is that a “two sizes fit all” model didn’t necessarily fit all. SAFe 4.5 has expanded to four different “configurations”:
- Essential SAFe
- Large Solution SAFe
- Portfolio SAFe
- Full SAFe
It also includes guidance regarding which configuration would be best suited for different scenarios. For instance, Essential SAFe provides a starting place for organizations to cultivate discipline around cadenced and synchronized feature delivery. It also provides a way for organizations that are struggling with their SAFe implementations to regroup and shore up the fundamentals, rather than just abandoning SAFe out of frustration. Will these four sizes fit all? Probably not, but these four will fit most. The way I see it, the guidance around these configurations provides an example as to what variables an organization would want to consider when making its own tweaks to the framework.
2. An obvious Lean Startup flavor
From its inception, SAFe has been built on a foundation of lean/agile principles. One of those principles is “Build incrementally, with fast, integrated learning cycles.” That being said, Epics, Capabilities, Features, and Stories flowing through connected kanbans from Portfolio to Team has always had a top/down, linear feel. In other words, the structure of the framework tended, in places, to obscure its intent. One big step forward with SAFe 4.5 is the introduction of the Lean Startup philosophy, with an emphasis on hypothesis/driven development. You can see it, for instance, in the renaming of the Epic Value Statement to Hypothesis Statement. The Lean Startup philosophy is also infused into the guidance around Continuous Delivery and Lean UX. Being more up front about this helps reinforce the reality that feature or solution delivery isn’t about making good on “requirements.” It’s a reminder that building complex software involves a lot of educated guessing, empowered experimentation, and rapid learning.
3. No more Value Stream level
The Lean concept of the value stream has always been a central construct of SAFe. Then in SAFe 4.0, the Value Stream level was introduced. This additional level made sense with large systems that are collections of programs. Breaking the value stream out into its own level also reflected what even smaller organizations had already started doing, just so that they could visually maintain the relationship between a value stream and its release trains. Calling this level the “Value Stream,” however, did create an issue or two. First, “value stream” is a Lean term that predates SAFe. For this reason, conversations could get confusing: “Excuse me, but you just said ‘value stream.’ Do you mean the SAFe value stream level, or the Lean value stream concept?” Secondly, value streams, in the Lean sense, did exist in three/level SAFe. So even when the value stream level wasn’t part of the framework configuration in use, value streams were still in play. SAFe 4.5 has removed this confusion by renaming the “Value Stream” level the “Large Solution” level. Not only will this make value stream conversations easier, it will allow the value stream concept to be applied more clearly and comprehensively across the framework, regardless of configuration.
4. Better context for DevOps
SAFe 4.0 included DevOps as a necessary discipline for keeping lead times short, and there was guidance around the concept of “release any time.” SAFe 4.5 does a much better job of integrating DevOps into the framework by placing it in the context of the Continuous Delivery Pipeline. That pipeline is a new addition to SAFe. It isn’t just concerned with automating the building, testing, packaging, and deployment of whatever has been coded by development teams. The pipeline encompasses the entire value stream, from vision to delivery. I’m glad to see this whole/value/stream philosophy being made more explicit in SAFe 4.5. Doing so helps diminish a handoff mentality and paves the way for continuous monitoring and improvement of the entire value creation and delivery process.
4.5. A cleaner Big Picture
As SAFe has evolved, the Big Picture has evolved with it. So the fact that SAFe 4.5’s Big Picture is different than the one for SAFe 4.0 is no surprise. Hence, there is only half a point here. But there are a couple of things worth noting about this version of the Big Picture. First, there’s been a conscious effort to make the image easier to read by creating more white space. This has resulted in a less/cluttered image than previous versions, making it less intimidating to those new to SAFe. Second, elements that were less universal and less/frequently searched have been moved out of the Big Picture and into the underlying articles. This, too, has helped to clean up the image. More importantly, this should allow the details of framework to continue to evolve without requiring frequent overhauls to the Big Picture.
Now that it’s here, I think the timing of this release of SAFe is just right and provides some valuable refinements. If nothing else, SAFe 4.5 is a reflection of the fact that the folks at Scaled Agile are adept at continually improving their product based on what they learn from the market. That’s something that I truly appreciate. Learn more about what's new in this SAFe 4.5 webinar featuring Inbar Oren of Scaled Agile Inc. Visit our website to learn more about how VersionOne supports SAFe 4.5. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.