1. SAFe 4.0 Represents a Leap Forward and Much Community Input.
The SAFe “Big Picture” alone has gone through over 100 version-labeled changes, and the guidance behind it has been evolving since the launch of 3.0 in 2014.
SAFe 4.0 is the result of significant practitioner input over 2015. One major influence was SAI’s engagement with builders of large systems — for example, in aerospace and automotive — that have hundreds or thousands of engineers, requiring integrated delivery across software, hardware and non-technical capabilities. Originally this was going to be a context-specific branch, SAFe for Lean Systems Engineering, but practitioner input was to use this new learning and fold it into the SAFe mainline. SAFe 4.0 therefore is not simply a “Scaled Agile Framework” but “SAFe 4.0 for Lean Software and Systems Engineering.”
An early version of 4.0 that integrated this work was previewed at the SAFe Leadership Retreat in May, where 50 leading practitioners worked on it over the course of two days, with further input at a “paint’s still wet” pre-release during October’s SAI Partner Summit.
Live hacking on the Big Picture as leading practitioners give input to the future SAFe 4.0 at the SAFe Leadership Retreat. Six consultancies and two multinational organisations using SAFe are represented in the front row alone. (Photo: Martin Burns)
2. SAFe 4.0 is a Modular Framework.
As a result of the large systems work the Framework now scales up to a much greater size, growing to support the integration of multiple parties with very large product organizations. However, organisations at the single team of teams size are still effectively supported, as the larger-scale components are all modular; you start simple and lightweight, only adopting what you need as you need it. SAFe 4.0 principles and practises beyond simple Scrum/XP start to be usefully adoptable as soon as you hit multiple teams coordinating in a program.
In particular, concepts about Vision, Roadmap, Metrics and teamwork around DevOps, Systems and Release Management can apply at all levels.
3. SAFe 4.0 Is a Principles-based, Adaptable Framework.
This adaptability is echoed throughout the Framework: you are expected to adapt it to your context. A major area of growth has been a stronger abstraction and articulation of the core theory behind why the practices work. What has emerged is a strong body of profound knowledge about systems thinking in product development environments, backed up with practical experience across many environments to provide a starting set of answers to the CIO’s question, “How do I make it work?”
Implementors are still expected to think for themselves, however, and use the core principles and values to undertake the inevitable adaptation required to meet each context’s specific needs. Given the right theory, this is significantly de-risked from blindly copying practises without understanding.
You can download a poster of the SAFe Principles from the SAI site.
4. There’s a New (Optional) Level: Value Streams.
Implementing SAFe in the largest organisations, such as those with software-integrated hardware systems, means that software often needs to coordinate with partner organisations and other deliveries from beyond the software team of teams. The aligned effort far exceeds the number of people who can work together as a single Agile Release Train (ART), but is not treated as a portfolio.
To support this, SAFe 4.0 includes a Value Stream layer to provide support when multiple ARTs and organisations need to be coordinated. However, recognising that this is a step too far for many other organisations that only need the Portfolio > Program > Team flow, it’s optional — represented by a collapsing layer in the Big Picture. Note that smaller organisations still do have Value Streams (as this is how value flows through the organisation) but as this may only be a single ART, the Value Stream practises and roles are optional at this size.
With the introduction of Value Streams, SAFe enhances its Requirements Information Model with Capabilities, a cross-ART coordinated set of functionality that is Prioritised from a backlog, realised by Features and subject to Acceptance Tests as its Definition of Done.
The new level introduces a closely bound trio of roles (together with associated ceremonies):
Value Stream Engineer: A servant leader very similar in role to the Release Train Engineer
Solution Management - Primary Content Authority: A Product Owner for the whole Value Stream Solution
Solution Architect/Engineer: Person with lead technical responsibility for the solution’s architecture and engineering
5. Kanban Is a First Class Citizen.
Building on SAFe’s existing focus on flow, the end-to-end value flow of content from Ideation to Realisation is visualised and managed in an enterprise Kanban system.
Kanban can also be used directly at all levels (not just with the Portfolio) integrating strategic alignment with local emergent context and using economic prioritisation pervasively. At the sharp end, Delivery Teams can use Scrum, Kanban or a hybrid, depending on their needs.
6. We Learn from Lean Solution Design Approaches.
With learning from long-standing product development and engineering communities that go back to the Wright Brothers, SAFe brings their experienced understanding of managing uncertainty in solution design to a younger industry. Lean Product Design (as opposed to Lean Manufacturing) has wrestled with these problems for decades, and has long valued iterative approaches that retain and explore multiple options through learning loops over simply implementing single-point “perfect” designs and struggling to make them work as they progress through a set of stage gates.
Using approaches such as Set-based Design and Model-based System Engineering, SAFe 4.0 supports evolution from highly variable uncertainty towards an increasingly well-understood and fixed solution by exploring contextual constraints and options through modelling, simulations, integrated prototypes and other studies.
7. Finance Principles Challenge Project Cost Accounting.
SAFe 4.0’s core financial thesis is that agile software development and traditional cost accounting don’t match: where people are brought to funded scope, too often the outcome is increased cost of delay and a blame game that destroys hard-built trust and transparency.
Accepting that in contemporary software-intensive environments the “temporary organisation, temporary work endeavour” project model assumption no longer applies, SAFe 4.0 instead proposes funding sustained delivery capacity through Value Streams (which may only be a single ART, depending on the organisational context), long-lived endeavours that house the delivery work organisation.
While initial financial governance is achieved through approval of lightweight business cases in Epics, spending authority is then devolved to the delivery work organisations, empowering them to make decisions using decentralised economic principles.
SAFe 4.0 offers practical support for operating these principles, including guidance for answering the CapEx/OpEx questions when operating outside a projectised stage gate environment.
8. SAFe 4.0 Recognises and Encourages Communities of Practice.
Building cross-functional teams risks throwing the learning-and-support baby out with the silo-thinking bathwater. It’s certainly true that there’s huge value in cross-team, peer-to-peer sharing, and advancing practical knowledge on common areas of interest, whether it’s based on job roles, methods or business unit experience. In your organisation, you might call these Disciplines or Guilds, but they do the same thing. SAFe recognises the value of these communities and directly encourages them.
9. Enablers Realise Indirect, Longer-term Value.
SAFe 3.x’s understanding of and support for Architectural Epics, Features and Stories has broadened into Enablers at Epic, Capability, Feature and Story levels, which usually fall into Exploration, Architecture or Infrastructure types.
10. Classes for Change Agents, Leaders and Teams Are Changing.
The three key certification classes have been redesigned by the practitioner and trainer communities for SAFe 4.0, to be more strongly founded on principles.
The old SPC class has become “Implementing SAFe with SPC Certification,” with a strong context-based workshop component.
Leading SAFe has new content.
SAFe ScrumXP is now “SAFe for Teams.”