SAFe 4.5 – the most important innovations at a glance

SAfe 4.5 was 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 addition is the Delivery Pipeline.
It is still built on the mantra of “Develop on Cadence, Release on Demand”, 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 to date, so a lot of care now goes into detailing what a successful pipeline needs to look like.
The description elements are

  • Continuous Exploration, where it is ensured that new market and customer requirements are regularly considered and that new epics or features are found in cooperation with customers and other stakeholders.
  • Continuous Deployment, the infrastructure that ensures that new features can be delivered reliably, in high quality, and in small increments 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 if and how often further versions / extensions are developed. This means that the final scope can deviate significantly from the original plan, and an explicit learning cycle is built into the development of an Epic – some Epics are never finished as a result, but are continually 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 their effectiveness.

The implementation 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 endanger the 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 to 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 gets 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

The VSM Quick Guide: the model

The introduction to the series on Jon Walker’s VSM quick guide. It describes the simplified VSM vocabulary as used in the rest of the steps.