If you’re familiar with the Scaled Agile Framework (SAFe), you might have heard about the recent changes.
Perhaps you’ve looked at SAFe in the past but didn’t feel like it was the right fit and are wondering if it’s worth looking at again. Or maybe you’ve already implemented aspects of SAFe in your organization and would like to know how different the new version is.
You’ll find more details about the framework and changes over at the Scaled Agile website, but I wanted to highlight a few additions that are relevant to us trying to change complex sociotechnical systems. This article is my honest viewpoint, based on experiences helping organizations improve their decision making and product design processes.
What’s new and what it means for your organization
1. The SAFe 5.0 structure
Before we dive into specific changes, I think that it’s helpful to understand how the SAFe creators organized the new version of the framework to orient ourselves. There are four configurations, seven core competencies, and ten SAFe principles.
Let’s start with the four configurations:
- Essential SAFe
- Large Solution SAFe
- Portfolio SAFe
- Full SAFe
The configurations are meant to showcase options between sets of SAFe elements that you could apply to your business and work.
For example, perhaps you’re working on a smaller technical system and only require the practices of Essential SAFe to start to see gains. Larger systems could require Large Solution SAFe, and if you want to incorporate dynamic funding decisions then you would choose the Portfolio or Full SAFe configurations.
The configuration options highlight more of the project management differences, with some references to product design vs. system design concepts. The right fit depends on your organization’s goals.
The creators also offer a “spanning palette” along the right side of the main graphic that describes some additional roles and activities that might be helpful for your organization but aren’t required by the framework.
Additionally, they recommend seven core competencies, which combined, impact business agility:
- Organizational Agility
- Lean Portfolio Management
- Enterprise Solution Delivery
- Agile Product Delivery
- Team and Technical Agility
- Continuous Learning Culture
- Lean-Agile Leadership
The recommended core competencies vary with each configuration. For example, they advise mastering Agile Product Delivery, Team and Technical Agility, and Lean-Agile Leadership at the Essential SAFe Level. Moving to Large Solution SAFe adds the Enterprise Solution Delivery competency. And once you add the Portfolio layer they suggest maturing your Organizational Agility, Lean Portfolio Management, and Continuous Learning Culture.
According to the SAFe website, the competencies are “sets of knowledge, skills, and behaviors” which support business agility. Each competency includes 3 “dimensions,” or sub-categories of skills and activities. The business agility assessment that they provide is based on your organization’s performance along those 21 dimensions.
And finally, I want to highlight the 10 SAFe principles:
- Take an economic view
- Apply systems thinking
- Assume variability; preserve options
- Build incrementally with fast, integrated learning cycles
- Base milestones on objective evaluation of working systems
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Apply cadence, synchronize with cross-domain planning
- Unlock the intrinsic motivation of knowledge workers
- Decentralize decision-making
- Organize around value
These principles are the basis for the practices, mindsets, and artifacts that SAFe recommends in the competencies and configurations. They are drawn from agile, lean, systems thinking, and the experiences of enterprises.
I want to acknowledge how difficult it is to design and communicate a framework that appeals to a wide audience yet is clear enough to be helpful. Yet I wonder if this was the clearest way to communicate the framework. They do cover both the why and the how in their content and courses, but I would prefer to see a clearer line drawn between the ultimate goals of the framework and the core principles, practices, roles and artifacts. The framework tends to blend them, which means you can lose information about why each activity is important.
Without that understanding, it’s harder to know when it’s ok to swap out an activity or role for something else that would also achieve the broader goal. As leaders tackling complex challenges with limited resources, we want to make sure that our investments count.
2. Focus shift to Business Agility at scale
The framework is now more focused on achieving business agility vs. delivering technical solutions (however it’s still applicable to technical system development). All of the competencies are aligned to support the mission of being able to quickly pivot the business, acknowledging that technology is a component of that goal.
One big change to call out is that in version 5.0 you can have business teams on a train. That means you can implement non-technical changes like marketing, training, legal, or business process changes using similar methods that product teams in SAFe use.
I’m happy to see this change because it acknowledges that business, customer experience, and technology design are intertwined. Software and hardware changes are embedded in existing business models, processes, and experiences. Making holistic changes requires skills and knowledge that go beyond the design of the product itself.
3. Organizational Agility addition
The organizational agility competency addresses your entire organization’s ability to adapt to new problems and opportunities. I appreciate the focus on providing organizational tools and training to support the shift to a more agile workplace.
I’m also happy to see more references to Lean Business Operations and Strategy Agility. Implementing APIs and AI into last decade’s business model can only take an organization so far.
4. New Continuous Learning Culture competency
The continuous learning culture competency is a good addition. While not a groundbreaking concept, I think that it’s good to highlight learning on a maturity assessment as a reminder. Blocking out time for reflection can be one of the first things to drop when schedules get full.
5. Switch from “DevOps and Release on Demand” to “Agile Product Delivery”
I appreciate the new focus on delivering and improving products, which showcases that all of these agile activities are a means to an end: to release valuable products and services to customers.
6. Tools for Customer Centricity & Design Thinking
Version 5.0 has expanded beyond Lean UX to incorporate more information about customer research and design thinking approaches. These are both worthwhile additions to call out, especially if organizations are weak in their understanding of these concepts.
The course content for Agile Product Managers provides more recommended tools and practices for identifying and defining “valuable” solutions. It also comments on how to start to blend technical, business, and customer viewpoints. Such as creating a product strategy that serves business needs, referring to personas throughout the product lifecycle, and starting to think about monetizing IT resources like APIs and data or changing your architecture to better support your business model.
However, the practices are still somewhat disjointed from other references to system design, business design, lean startup, portfolio strategy, and the previous article on Lean UX. A number of practices are recommended but the framework could better express how to combine them with other activities or which one to choose in each circumstance. Implementing business agility often requires blending cross-functional mindsets and activities, drawing reasonable boundaries around the scope of the problem to solve, and sharing insights.
I’m drawn to scaling frameworks like SAFe when they try to help larger and more complex organizations who want to tackle big changes with agility, not just implement agile activities across a larger portion of their teams.
The content is now stronger in helping individual teams uncover needs and opportunities to provide value, but doesn’t quite address cross-cutting dependencies, dynamics, and emergence in complex systems. In my experience, the most interesting challenges and conversations happen at the boundaries of control and resources when people outside of your team have knowledge or resources that you need, or when a change or new insight in one area propagates across the design and impacts other teams.
I would be interested in seeing more case studies that discuss how overarching information sharing, design and decision making processes evolve in an organization, given the move to SAFe. Especially across different industries and types of business models. SAFe has historically been stronger at communicating how the project management role changes during the shift to the framework.
7. Elevated importance of organizing around value
SAFe added a new principle in version 5.0 called “Organize Around Value.” The importance of providing business and user value and organizing around value streams is evident in their course content.
While a good target, I can see this shift potentially being a practical challenge for organizations that are currently divided by functional areas, such as the IT department vs. marketing vs. finance. When scaled agile practices were originally centered around software products and led by the IT department, it required business representation in the form of Product Owners or representatives during PI Planning. Teams and trains were formed around existing products or areas of the business model (ex. developing new solutions for a specific market segment or improving a particular front-end or backend experience).
If the entire organization will adopt agile mindsets to enable business agility, that requires much more intentional business design to create the blend of freedom and information sharing to support the agile evolution of business offerings, customer experiences, and products. Your SAFe structure needs to be as dynamic as your business. Communication and knowledge management tools likely need to change to support these goals. Calendars need to shift. Contracts may need to change.
A structure that makes sense for your current business model and set of products may no longer make sense if you decide to consolidate disparate systems into a streamlined technology stack, rapidly evolve separate business offerings, or expand into new markets. Processes, artifacts, and meetings that are helpful in one context are wasteful in others. It requires a blend of targeted design to capitalize on an opportunity and continuous listening and exploration to identify more.
Organizing around value is a worthy goal, it just involves more moving parts and constraints than when the transformation could be led by IT. The change in transformation scope is valuable but not trivial to execute.
Is SAFe 5.0 the right fit for your organization?
Overall, I think that SAFe is moving in the right direction by thinking more broadly and version 5.0 references more industry trends and practices that have proven to be effective than the prior version. Curating concepts, tools, and activities from different fields expands the problem-solving toolkit.
The graphics and educational content are good conversation starters to share practices across disciplines and align a diverse group around a common vocabulary. The expanded maturity assessment helps to prevent organizations from prematurely declaring “success” when their technical teams are more “agile” but the business as a whole is not able to adapt quickly.
If you were hesitant to look at SAFe before because it didn’t address product strategy well enough, it might be worth a second look.
However, the framework is not always clear about need to have vs. nice to have recommendations along the path to achieving the ultimate desired business outcomes. It can be overly prescriptive in some areas and too vague in others.
SAFe has been criticized in the past for being too complex and this version adds even more concepts, activities, artifacts, and meetings. I can see how organizations might struggle to visualize how to practically implement all of these recommendations in their environment in order to benefit from the investment. What to prioritize, which practices and roles you really need to reach your goals, what you can drop or defer, and how to implement all of these recommended continuous and concurrent activities when you also have a business to run and customers to serve.
Do you feel the same way?
If you could use some help designing new ways of working to achieve your organization’s goals, the Recharted Territory team can help.
We specialize in implementing complex transformations in constrained environments.
Past clients not only wanted to enable agility at scale but were also dramatically transforming their business and technology stack at the same time. They measured success by the improvement they were able to make in their customers’ lives and communities, not just time to market or profit margins.
We incorporated SAFe recommendations if they made sense for the organization, and helped eliminate the noise or identify alternatives when they didn’t.
If it sounds like it could be a good fit, the first step is to contact us to start a conversation about your organization and goals.
Have you checked out the latest version of SAFe? What do you think about the changes?