SAFe has an update - I studied the changes so you don't have to
SAFe has an update - I studied the changes so you don't have to
What's different between version 5.1 and 6.0?
Love it or hate it, the Scaled Agile Framework, or SAFe, is heavily used. The annual State of Agile reports show how SAFe is conquering more and more terrain. In 2020, 30% of the respondents said they used SAFe to scale Agile. In 2022, this rose to 53%.
This doesn’t mean that people have been happy with SAFe. Age of Product did a survey and found that the NPS score for SAFe was -56. I have my doubts about the framework too. On top of that, I have been very unhappy about the fact that SAFe misused Scrum in its framework.
But now SAFe came with a new update and I believe it deserves a fair assessment. This is why I decided to dive into version 6.0.
SAFe 6.0 has the following six themes to highlight the most relevant changes:
Strengthening the foundation for Business Agility
Empowering teams and clarifying responsibilities
Accelerating value flow
Enhancing Business Agility with SAFe across the business
Building the future with AI, Big Data, and Cloud
Delivering better outcomes with Measure and Grow and OKRs
I will discuss them individually.
Strengthening the foundation for Business Agility
SAFe 6.0 present the Business Agility Value Stream, as you can see below:
There’s a lot to unpack here. Let’s start with the good. Because there is a lot of good in the picture indeed.
For starters, for a business opportunity, the first step is to fund an MVP (Minimal Viable Product) to evaluate this opportunity. Indeed, instead of jumping on creating a feature with all kinds of bells and whistles, you should verify your assumptions. This is what an MVP is for. That is refreshing to see because there are so many false ideas about MVPs.
I also like the next step, organizing around value. You wish to consider the complete value stream and not only the core product. For example, a user can be very happy with the core functionality, but if they for some reason need to engage with customer care and their experience is bad, this will impact their view of the product as a whole negatively.
Another positive point is that value assumptions are to be verified with the users. And if they bring new insights, this should lead to adaptations. While this may appear logical, SAFe hasn’t been strong at this value learning loop.
I do have an issue with the duration of this loop. Particularly with the 2 to 6 months to MVP. For me, 2 months would classify as the maximum time to verify assumptions. 6 months is definitely too long in my book.
But I have most doubts about how this Business Agility should fit in the world of SAFe with multiple Agile teams working in Agile Release Trains. Wouldn’t you rather start small to verify your value assumptions instead of setting up multiple teams and all the other roles? If you see the below picture, what is your impression? Do you think SAFe can make full use of the Business Agility loop to verify value opportunities quickly?
Apart from Business Agility as a concept, SAFe has had more on the topic of Strengthening the foundation for Business Agility:
SAFe highlights the importance of a continuous learning culture. In my opinion, this should be the norm for Agile environments and is nothing notable.
The Lean-Agile mindset specifies the value of the product, identifies the value stream, talks about making value flow without interruptions, lets customers pull value, and pursues perfection. What I miss here is verifying the value. Because without that verification, there’s no sight of actual value. I wonder if they accidentally omitted this as it IS a step in the Business Agility loop I discussed before.
SAFe reiterates its core values of alignment, transparency, respect for people, and relentless improvement. These are quite standard for agile approaches.
Empowering teams and clarifying responsibilities
SAFe 6.0. continues to have many roles, like Epic Owners, Business Owners, Product Managers, and Product Owners. I continue to have issues with that, as it also leads to many hand-offs. I do prefer the simple concept as depicted by Scrum, with the Product Owner having the overall accountability for the value of the product. And thus being very different from the Product Owner in SAFe.
As before, Agile teams still focus on delivering (great) products. I would have liked the emphasis on creating valuable products. This may look like a trivial difference, but it’s not. SAFe teams deliver features in order to create value. Delivery is the main goal of Agile Teams. Scrum is about maximizing value by delivering items. Maximizing product value is the main goal of Scrum.
Agile Release Trains (ARTs) remain to be the group of teams that all need to plan for several iterations and work in cadence to stay aligned and deliver accordingly. This continues to be my core issue with SAFe. Instead of planning more frequently, ARTs are looking at longer periods. With that, they risk working on the wrong things for a longer period.
Customer feedback is mentioned, but how can an ART plan for multiple iterations when its iteration feedback may be disruptive to the overall planning? Shouldn’t the Agile teams of an ART plan more frequently together, like every iteration? This would greatly help them to respond to new insights.
SAFe finally acknowledged that a team can have a Scrum Master OR Team Coach. This means that a team that doesn’t do Scrum doesn’t have a Scrum Master, but a Team Coach instead. This was a minor caveat, but I’m happy they resolved it.
Note though that SAFe has SAFe Scrum which isn’t the same as Scrum by the Scrum Guide.
Accelerating value flow
Flow is put front left and center. SAFe has always been a flow-based framework. As it has been the equivalent of a factory producing goods. Now, SAFe has simply embraced all kinds of Kanban best practices to improve its flow of value narrative.
SAFe’s version of Scrum (SAFe Scrum) is still very much about delivering features instead of creating value. I will create a separate article to discuss the difference between SAFe Scrum and Scrum from the Scrum Guide.
As discussed, value stream management is put at the center of SAFe. It is all about optimizing the value stream which translates into delivering more quickly. I do miss a vital step, which is the verification of what’s been delivered to assess if it actually adds value.
Enhancing Business Agility with SAFe across the business
With version 6.0, SAFe moves beyond IT and Development. ARTs now also can have business teams. This is logical considering the Value Stream. It all makes sense as you need to look at the complete product picture.
Building the future with AI, Big Data, and Cloud
For me, this inclusion of AI, Big Data, and Cloud comes across as adding stuff that’s cool and all the rage in the market (as they have been adding everything and the kitchen sink to SAFe already).
Delivering better outcomes with measures and grow and OKRs
I’m happy to see this emphasis on measuring outcomes. I have been a huge advocate of looking at outcomes and impact. The output you deliver is a means to achieve your outcome and make an impact.
As long as you don’t establish what your desired outcome and impact are you have no clue why you build your product in the first place. If you DO define desired impact and outcome, then you should also look into assessing if what you do brings you closer to it. SAFe hasn’t been strong on this topic of outcomes. I’m happy they have it prominent in SAFe 6.0.
The below newly introduced picture reminds me a lot of the competencies as depicted in Evidence-Based Management.
Evidence-Based Management talks about the following Key Value Areas:
Unrealized Value and Current Value to assess Market Value.
Time to Market and Ability to Innovate to assess Organizational Capability.
SAFe’s Outcomes would fall in the category of Market Value. Flow and Outcomes would align with Organizational Capability. SAFe has a solid story on how they include Objectives and Key Results (OKRs) and measures and growth. Having said this, I continue to grapple with the translation to the ARTs who remain more focused on multi-team aligned feature delivery. The big question remains here: once you learn you need to move in a different direction based on the measures you did, how easily can you pivot without destroying the ART?
I like how OKRs are introduced throughout the SAFe framework, from the portfolio level to the team level. Regardless of the pitfalls it can bring to the ARTs.
My first impression of SAFe 6.0
All in all, I’m not at a point where I would recommend SAFe as an Agile approach to creating value with multiple teams. That said, I DO think that SAFe 6.0 is a step in the right direction.
I mostly like the integration of OKRs, the introduction of Business Agility, and the focus on outcomes. However, I still have my doubts about how the Agile Release Trains should function with all of this. By nature, the ARTs are more a delivery train than a discovery train where faster feedback would be key.
I can see a moment in time when I WILL recommend SAFe. Will this be SAFe 7.0? Or SAFe 11.0? Or never? Time will tell.
The 5 elements you describe as the Lean-Agile mindset are actually listed under the heading Lean Thinking, and are taken directly from the book of that name. The fifth element, pursue perfection, sets up a cycle of continuous improvement that returns to defining the value of the product. Verifying the value through user/customer feedback is part of that cyclical definition step, as Lean explicitly defines value from the perspective of the customer.