This blog is the final part of the series of articles I am writing about the SAFe 5.0 preview that launched in early October this year.
In this part, I am writing a more in-depth analysis of why SAFe 5.0 looks the way it does, and what this means going forward for the framework SAFe, the company Scaled Agile and people like you and me that reference the framework.

The framework calls out business agility as a critical concept
The ability to handle and convert variability to value, which has been central within Agile system development. Has now been stretched to contain the even broader term business development in the SAFe framework. This change comes from observations of what successful teams are doing across the world today; They merge business with technology to build exceptional solutions for their customers. And the framework now oversees how to manage that broader transition.

Hopefully, this will lead to more people discovering how clumsy a separation between technology and business is today. Hopefully, it helps people dare to merge these two elements of their organizations. Most likely, the framework will continue to expand the guidance in this direction, moving forward.

Scaled Agile puts a strong focus on the importance of organizing around value, with a strong customer focus.
Here, Scaled Agile is choosing to emphasize, that a Lean and Agile approach to development fundamentally builds on tackling long feedback loops between those who create value, and those who receive the benefit. The framework is now with 5.0, much more clear on that the key is to organize the work around identified value streams and customers. Rather than internal proxies (“department,” “competence,” “budget”) as this approach drastically decreases the number of handoffs and moves focus to “value for the customer” instead.

The reason for this is that there have been many cases in the field, where Lean/Agile methods or framework has been applied and where ARTs/Tribes/Team have been formed around existing projects/programs/departments instead of identifying value streams. As a result, it has meant that new meetings, teams, and methods are introduced (agile!), but no real systemic change is taking place in how they work or how value is created and delivered. Hopefully, this clarification in SAFe means that there will be less risk of misunderstandings regarding what a Lean and Agile approach is founded on (value/customer) and that it becomes easier to comprehend how to apply this thoroughly, as an organization.

When the framework now emphasizes, even more, the critical component of including the customer in the value creation. Then it becomes essential to have the skills and tools that are needed to do it. Scaled Agile has now created a three-day course in Agile Product leadership (APSM) that focuses on learning how to apply design thinking, mapping out customer journeys, and implement a structured market approach to build amazing future products and services.

In We Are Movement, we offer this advanced course during 2019 and 2020. It is focused on CPOs (Chief Product Owners), Product Managers, and Senior Product owners, who wish to expand their skill set and certify in using advanced tools within their field, to lead teams and ARTs towards potential future markets and products/services.

You will find our available courses in APSM here: Agile Product and Solution Management

The continuous value flow replaces the levels “program” and “team” in the framework.
Another significant change is that the framework now finally lets go of the concept “team level” and “program level” and instead refers to the value flow, which is considered as “essential” instead, the long-lived agile teams who collaborate dynamically to create value continuously. This is a powerful story, as well as a solid description of what Scaled Agile sees in today’s market. It even removes part of the legacy that lies within the word “program,” a term that previously has been used in SAFe to reference multiple teams working together.

Now, we see the beginning of a more defined narrative within the framework, about what, in my opinion, is to be considered one of the absolute most significant innovations within the last ten years of agile development. The concept of continuous delivery and a heavily automatic CI/CD pipeline, around which small cross-functional teams collaborate.

What we can expect for the future is probably a still more significant focus on the concept of CI/CD, even outside of pure software, as well as methods, techniques, and ideas for how to build a pipeline and a plan for working with it.

SAFe moves towards the “soft” world
Historically, the team at Scaled Agile has chosen to focus on the more concrete and operative details that make up the framework’s ability to support multiple teams in delivering value collaboratively. It has been heavily centering around events, pipelines, and teams that collaborate, but perhaps not so much about the bigger context (company/ organization) that these elements exist within.

However, as a practitioner in the field, it is quite clear to me that if you start to implementing “agile methods” without simultaneously developing flexibility in the organization, you have and, on top of that, also fail to encourage the overall organizational learning ability. Then the first agile teams and the skills they acquired will often fade out over time as it does not grow into the overall organizational agility.

The reason is that new value streams need to be formed over time as the business changes, and even terms like innovation and exploration of customer value mean that part of the development work will produce unexpected results (learning!). And this is something that will be rejected if the organization doesn’t view learning as a value on its own.

Now, with the additions of the skills “organizational agility” and “continuous learning organization,” we see the beginning of how SAFe as a framework views how others have adapted these softer/broader organizational questions and begin to make them defined in the framework. My guess is that we in the future will see more SAFe-things related to HR, finance, line organization, and culture-building elements that are needed to create the appealing “Business Agility,” which is the goal today.

Conclusion
It was really about time that the framework SAFe approached the softer sides of agile work methods, that in the end are needed just as much as the more “technical” (smaller batches, lower WIP, CI/CD, etc.) parts. I am also pleased to see that they have made the leap and now changed what was before implicit and maybe even partially unclear about, organizing around value/customer, into much more explicit recommendations. As, after all, a Lean and Agile approach rests entirely on this principle,