Bridging Waterfall and Agile teams

In large businesses, it isn’t unusual to have different approaches to software delivery. The finance organization may choose to outsource development and prefer a detailed statement of work at the beginning of the project. They would choose the waterfall methodology leading to a higher confidence in delivery timelines. Their projects may last months, but the cost and scope is more likely to stay fixed.

The product org may want a tighter feedback loop with customers and lean toward in-house development and expertise. They would choose the agile methodology, with a higher confidence in delivering what the customer needs.

Inevitably these two clash. In a previous role, the finance org had a requirement to institute a compliance measure across all of product. This resulted in confusion and frustration in both orgs. The product teams were pressured to understand the compliance measures and provide a detailed scope up front even though development wouldn’t start for a few sprints out. The finance org was pressured to deliver fixed cost & schedule projections and utilize in-house expertise instead of the more familiar contractor route.

waterfall and agile

The need for a bridge

Within both orgs, there were purists… ferociously begging the other org to change.

  • “Everyone should be agile or our customers will leave!”
  • “<Name-drop> needs everyone to move to waterfall so we can meet our deadline!”

This kind of banter was non-productive and if not stopped would’ve caused all objectives of software delivery to be missed.

bridge watefall &amp; agile (1)

So, what did we do?

The finance org needed detailed requirements to continue to the next step in their methodology. These technical requirements often required a discovery phase (or spike) by the product teams. To meet the timeline for that stage-gate review, the project had to be made a high priority in each of the product teams’ backlogs to stage the spikes appropriately.

Note: Without an executive sponsor and acceptance of the product trade-offs for such an effort, this project would not have gotten any further. 

The acceptance criteria in each of the spikes prompted the product teams to detail out the system changes needed to meet a compliance requirement. For example, to meet the PCI requirement that services utilize TLS 1.1 or higher, the acceptance criteria of the spike may look like this:

AC1: Documented list of internal and external endpoints and what TLS version they are running.

AC2: For high SLA services: provide detailed stories on how to upgrade (without customer downtime) each endpoint captured in AC1 with a TLS version below 1.1 to at least version 1.1

AC3: For low SLA services: provide detailed stories on how to upgrade (with <1 hour downtime) each endpoint captured in AC1 with a TLS version below 1.1 to at least version 1.1.

At the end of a sprint containing spikes, a release may not happen. Instead, a more refined backlog is created. After the following story grooming, you would have a strong-enough scope & estimates to execute off of.

In practice, we did this across 8 product teams. And of course, all 8 teams operated slightly differently. Some staggered spikes across 2 sprints while others were ready for development within one week. After a month though, the product teams were able to provide back to the finance team enough detail to meet the requirement, analysis, and design stage gates.

After negotiating some key trade-offs the product teams were able to prioritize the development work in-line with each other as well.


Leave a Reply

Powered by

Up ↑

%d bloggers like this: