Once you get to the point that you know you are going to have to interface a SAFe release train(s), with a waterfall program run outside your organization, success generally turns on three very related topics.  The three topics are transparency, synchronization, and code.  The timing of when the code from all parties is available and managing when the code can be integrated and tested is critical. Even if both programs produce the right code and the code works as it is expected, each program will produce functional code at very different times.  By definition waterfall projects create code after they have done a large part of the analysis and design while teams in a SAFe release train will have functional, demonstrable code earlier. By the time the waterfall project is ready to write code the agile project will have a significant investment in a code base.   Three suggested approaches (in addition to transparency and synchronization) for addressing the risk generated by the differential in code timing are:

Design Patterns:  Adopt standards for design patterns that will be used by everyone in the organization.  For example, begin by defining a standard for how the systems will interface with the other system so there is less friction for using the information being shared between systems.  This is a type of adapter which is a common design pattern in software engineering. Defining standards for design patterns up front reduces the risk that systems will not function well as a system of systems

Continuous or Frequent Integration:  One of the most important technical practices in agile is continuous integration (or at least as continuous as makes sense).  Continuous integration requires developers to put the code into a shared repository so that it can be built and verified. This is a common agile practice even if the code is going to be released much later.  As soon as the waterfall program begins to produce code, that code should be integrated into the common build in order to generate feedback for both the agile and waterfall programs. The earlier problems can be identified the less likely the problem will cause a catastrophe.  The system of systems team will lead this effort.

Full(ish) System Tests and Demonstrations:  In a similar vein to continuous integration, institute system tests and demonstrations.  Even when an agile release train is paired with a waterfall project, the functional system will emerge incrementally, therefore, multiple demonstrates and systems tests will be required.  Once integrated, show the parts that are working to everyone possible and continue to test the system of systems. Your goal is to find problems and misunderstandings as EARLY as possible.

Kim Pries, the Software Sensei on the Software Process and Measurement Podcast, is a software engineer, tester, manager, educator, serial author, and friend.  Kim strongly suggests not to integrate an agile program (SAFe or not) with a waterfall program. His view is that the level of self-inflicted complexity is rarely worth the risk.  The problem is that “no” is not always the answer organization will arrive at. Success when the answer yes requires substantial effort to ensure the risk from synchronization, transparency and code are minimized when the work is defined and the contract signed.