I was recently asked how an agile program could interface with a project developed by an outside firm.  The outside firm was using a waterfall process with a single planned delivery of code. The answer I wanted to give was “don’t do it”, but that isn’t a useful answer. Further context: The person asking the question works for an organization that leverages the Scaled Agile Framework Enterprise (SAFe); using the Essential SAFe instantiation for most of the work in the organization. While several release trains exist inside the organization, they are not closely interrelated. Therefore the organization does not need to leverage Enterprise SAFe. Assuming you cannot avoid having two separate but interrelated and dependent projects with one run by a separate organization and using a different approach than your organization, there are several major issues involved in answering the question. Three of these are:

  • Lack of transparency:  The lack of transparency between the two programs may lead to misunderstandings and conflict. Two reasons a lack of transparency is problematic (unless specifically addressed) include the contract vehicle (which typically defines what can and can’t be shared between parties) and differences in organizational goals. On the surface, each organization will have the same project goal (working functionality). Yet, from a business perspective, both organizations may have very different strategic goals.  One may be to make the most money possible and the other one may be to get the best value for the money spent. Any difference in goals can generate very different behaviors that will require a lot of empathy to understand.
  • Synchronization: Different methods have different synchronization points. All varieties of SAFe have several layers of synchronization, each at a different cadence (daily team-based, iteration-based and program increment to name the most common). Waterfall projects use stages (or phases) as synchronization points. If the two programs don’t stay synchronized, there is an exponentially increased risk that one party or the other will build the wrong solution or that the two components will not work together well. All parties need to decide up front how synchronization will happen to ensure the right work happens both correctly and at the right time WITHOUT a killer dose of overhead.
  • Code timing: Each program will produce code at a different time.  Waterfall projects create code later in the flow of work than agile efforts. Because the agile portion of the work will have functional, demonstrable code earlier, they will have a significant investment in a code base before the other program begins to develop code. The teams will need to recognize the agile code base as a source of knowledge and truth that the waterfall project will leverage as it begins the build process, all other things being equal. Finding a path between a BUFD (big upfront design) and emergent designs needs to be an early decision. Failure to use the code base and architecture as the source of truth will likely result in rework and problems in integration.

We will review strategies to deal with these issues in the next few installments of the blog.

Programming Note: After this question, I will tackle another discussion I recently had, generated by the statement, “We messed up Scrum so we are going to try Kanban next.  Is that a good idea?”