Major SAFe LSE Update with Big Implications

Hello Folks,

We readily admit that this hyper Agile-innovation-do-your development-work-in-the-public-domain business model of ours can make for an interesting journey of discovery for all involved. Working closely with our community of practice, we’ve devoted the last several months to the development and conceptualization of the next generation Framework(s). There have been some amazingly informative and thought-provoking ah-ha! moments that have brought to us to where we are today, and we’d like to share the high points, and bring you up to speed on what we know about the next version of SAFe and SAFe LSE.

As you know, in response to the the needs of the large-scale complex systems builders, we’ve been developing a specialized framework, SAFe for Lean Systems Engineering (SAFe LSE, 77 versions of the big picture to date!). This work is representative of a diverse group of contributors, including Harry Koehnemann, systems engineering consultant from 321 Gang, as well as some deep engagement client work, and feedback from our SPC community in various forums. SAFe LSE went live as Preview One in early March.

As part of this effort, we went back to the fundamental principles of Lean-Agile development, and conceived the SAFe Lean-Agile Principles. We took care to make sure they were consistent and usable in both SAFe and SAFe LSE, because, well… they are the universal principles of Agile and Lean. The fact that they are the same was a small awakening (hmm…maybe the implementations aren’t all that different either). And so on we went to elaborate LSE.

On April 14, we (Dean, Harry, Alex, Inbar and Tim) delivered the inaugural course of the 3+1 day Applied SAFe for Lean Systems Engineering to a full house of about 40 Lean-Agile change agents from some of the world’s largest companies engaged in building some really big systems. Interestingly, about half of the attendees were SPCs already, and many of them had significant SAFe 3.0 rollouts in process.

The class was based on a new and improved structure and pedagogy we defined for the upcoming release of the next version of Leading SAFe (more on that in a future post). The class flowed really well and the response was very positive. The focus on the coordination necessary at the new System level, pre- and post-PI Planning, Lean-Agile Principles, Fixed and Variable System Intent, Enablers, Adaptive Requirements and Design, MBSE, Set-Based Design, etc. are all relevant in that world (as should be the case, since it was designed for that purpose). But there was some enlightening and critical feedback as well. Comments went something like this:

• “Don’t worry about making the role titles suit our context. For example, we’ve already been retraining people to the more outward-facing, and more agile responsibilities of the Product Manager, so don’t change that back to ‘Lead Engineer’ just to make us more comfortable.”
• “Yes, we have big challenges, but don’t make the new framework any less Lean-Agile. We need a strong vector, like SAFe, to keep us moving forward on our Lean-Agile path. Don’t water anything down for us.”
• “We need a portfolio treatment for our system, but linking to another framework (SAFe 3.0), with a different big picture and different terms, etc. is well, pretty hokey.”
• “We need this new extended content, but we are already rolling out SAFe, so two frameworks is not going to be helpful (in the least).”
• “Most of our programs need that full system integration layer, but we have smaller programs too, and LSE looks a little too complex for those cases. Could you make it more modular?”

Well, you can imagine the interesting weekend we had digesting that feedback.

The very next week, Alex and I taught an SPC class in Boulder, based on SAFe 3.0. On Friday, as is our custom, we gave the new SPCs a preview of the future and walked them through SAFe LSE and the then-current plans for SAFe 4.0. Wow, what a lesson learned that was! Here are some relevant comments:

• “Wait, we are building a big solution too, even though it is pure software, and we need that LSE ‘System’ level. Some of us may not think of it as a single system per se, but we routinely have to coordinate these activities. The current coordination article in SAFe 3.0 is helpful, but it doesn’t describe, for example, pre-and post- PI planning at the Value Stream level, System Intent, Adaptive Requirements, etc. And by the way, we think the treatment of Enablers is a much richer surface to discuss various types of enabling activities, like infrastructure—not just spikes and architectural features.”
• But also “Not everything we build is that big; can the framework be more modular so that we can have it both ways?”

And so it was that we came to a new plan, based on a clearer vision of how to best support both communities. Fast forward to the images below (click to enlarge). Imagine an Expand/Collapse tab on the right of a future Big Picture. You shouldn’t have to imagine too long, as we’ll be implementing this for the LSE community for this summer.

The odds are awfully high that you are looking at the new prototype for SAFe 4.0. You can look forward to a public preview website late summer.

One framework. One certification path. One set of partners. More modular. More scalable.

Stay tuned!

—Dean, Alex, Harry, Inbar, Richard, and the Scaled Agile team