millaa millaa falls

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall?, we identified three major areas that had to be addressed so that a multiple inter-related programs with different management approaches didn’t turn into a train wreck.  Keeping related programs moving in the same direction is important, and synchronization is critical. In a recent interview for a future SPaMCAST Alan Shalloway, CEO of NetDynamics, reminded me that the more complicated we make work, the more we reduce flow and increase the probability of making mistakes. Staking the organization’s success to integrating two programs moving at different speeds is complicated. Synchronizing successfully requires spending time and money to keep the programs synchronized. Three effective techniques used to implement synchronization are:

  1. System of Systems Team (SoST) – The system of systems team (similar to the systems team in SAFe, just scaled) provides support for the development and maintenance of an integrated environment that supports the interaction and evaluation of the code from both programs. The most important and timely proof of synchronization is that the code from both programs RUN correctly. A SoST is a prerequisite for making that happen. Developing and supporting this type of environment is complicated in the best of circumstances where both programs are working on the same method and cadence. When we are dealing with scenarios outside the best of circumstances, such as integrating waterfall or black box vendor programs, we increase the level of complication which requires a significant amount of effort to maintain and monitor all of the moving parts.
  2. Continuous or Frequent Integration – Integrating and building software, and having the software work as expected, is the ultimate proof that the two programs are synchronized. While the SoST builds the environment for integration, both programs must have the proper mindset toward the need to see the code in action or continuous or frequent integration will translate to status reports and functional code demonstrations on a occasional basis. Finding potential misunderstanding or variances in approach needs to happen as early (and frequently) as possible or the programs will find it difficult to change the direction WHEN problems occur.  Early in my career, I had to help rescue two large banking programs that had misunderstood who “owned” the approach for sharing data between the systems. Both programs were firmly convinced that they had described their approach (in the middle of a large design document) that everyone had signed off on — BOOM. Fixing the problem required bringing the architects and technical leaders to a week-long offsite near Toledo on the shores of Lake Eire in February (it was cold – we Ohioans are a hardy lot). The cold focused the group on the problem at hand. Six months of rework was required. 

    **SoST and Continous or Frequent Integration highly related, consider them as a linked pair of techniques.

  3. Program Management – Someone(s) needs to be responsible for actively managing the two related programs.  Concepts such as scrum-of-scrums or agile release train syncs (ART sync) defined in SAFe and Scrum need to be leveraged to ensure that assumptions, risks, and expectations of each program are identified, rationalized and validated. I once watched a large freighter on Lake Erie queue up to enter the Cuyahoga River while another freighter tried to leave.  Both ships employed pilots to guide them through the process, coordinating two programs, whether they are using different approaches requires at least that level of coordination. Program management will add a significant level of overhead (reports and meetings); that is the penalty for large programs.

NOTE:  Returning to the premise of integrating a vendor lead, waterfall program with an internal program run using SAFe, all of the synchronization techniques and overhead needs to be included in the contract.

Returning to Al Shalloway’s comment, we can draw out the implication that the need to synchronize between waterfall and agile programs is self-inflicted. Organizations chose to make wide, sweeping changes to the systems and architectures. If you don’t need to make things complicated DON’T do it.  However, firms make the decision to integrate SAFe and waterfall programs because they deeply feel the necessity for abrupt, dramatic change. Regardless of why the choice was made, synchronization will not happen without the appropriate structure and expenditure of time and money.