SAFe 4.5 – the most important innovations at a glance

SAfe 4.5 has been released in June and brings some new features.

Some are cosmetic, but there are also important additions and clarifications.

New Delivery Pipeline

Probably the most important enhancement is the Delivery Pipeline.
It still builds on the “Develop on Cadence, Release on Demand” mantra, which is designed to ensure that the system is ready to deliver at any time.
Apparently, however, this has not been done successfully in every implementation so far, so a lot of care now goes into describing in detail what a successful pipeline must look like.
The description elements are

• Continuous Exploration, where it is ensured that new market and customer requirements are regularly considered and that new epic or features are found in cooperation with customers and other stakeholders
• Continuous Deployment, the infrastructure that ensures that new features can also be delivered reliably, in high quality, and in small increments up to a staging environment.
• Continuous Delivery describes what it takes to deliver features to the staging and production environments so you can deliver anytime. This is now more clearly separated than before from release cycles, which can be influenced by external market requirements, strategic decisions, compliance approvals and much more.

Integration of Lean Startup strategies

No less important is the integration of ideas from Lean Startup, which addresses the problem that the flow of epics through the Gdesamt system looked very linear.
Especially in the exploration phase, it becomes clear that the description is now much more iterative than before. SAFe relates to Lean Startup strategies and the Lean UX model. This means that an Epic no longer gets a business case, but a hypothesis. This is developed in a first version until it is ready for the market (as MMF, minimal marketable feature), then it is decided whether and how often further versions / extensions are developed. As a result, the final scope can deviate significantly from the original planning and an explicit learning cycle is built into the development of an Epic – some Epics are also never finished as a result, but are continuously developed further.

DevOps as a cultural, organizational and technical task

DevOps is described as primarily an organizational and cultural task: the key point is to break down traditional silos (developers, testers, etc.) into cross-functional teams that can work together to ensure frequent delivery of new functionality. Only on this basis can the tool chains (which are then also necessary) develop effectiveness.

The rollout strategy has become more concrete

In the introduction, the conditions for success and the roles in a SAFe implementation are mentioned much more clearly than before.

Many small changes

• The big picture becomes less complex. The big picture has been cleaned up and has become clearer: too many details threatened to compromise clarity. This is all the more true as more and more information has been added over time. This also includes the removal of the various optional roles into the edge bar, the spanning paleete – it becomes clearer that, for example, the system team can be located at different levels as required. Different roles are also offered per configuration, representing experience from different applications.
• New configurations. SAFe configurations have been revised to reduce customization effort and tailor them more specifically to user groups.
• Renaming. Various renamings are intended to eliminate sources of misunderstanding. The most important are
  – The Value Stream layer is now called the Solution layer, in particular there is now the Solution Train, a Train of Agile Release Trains
  – The budget process is now called Lean Budgeting
  – SAFe is getting a new name – it is now called “SAFe for Lean Enterprises” – this is also intended to formulate an extended claim for the development of complex “systems of systems”, for example from hardware and software components.