How should I handle an agile-waterfall hybrid project?

A question which I’m frequently asked by learners attending my agile foundations courses is “I’m quite comfortable with what’s required for a waterfall project and what’s required for an agile project, but how do I plan and manage one where some of the scope is going to be delivered in a waterfall manner and some will be delivered using an agile approach?”

I could plead the project management equivalent of the Fifth Amendment by answering “It depends!” which is a perfectly valid response given that the context of such hybrid projects varies widely.

In some projects, there is a very clear delineation between the type of deliverables being produced with each approach and there is limited direct integration between these deliverables. For example, technology deliverables might be completed in an agile manner whereas change management deliverables such as training collateral get produced in a traditional manner. In others, deliverables themselves are produced in a hybrid manner. For example, the web portion of a technology solution might be produced using agile methods, but the back end integration with a legacy system needs to be done in a traditional manner.

Another attribute which influences this is an understanding of who is delivering which work streams. Are they all being produced internally, or is a vendor responsible for either the agile or the traditional deliverables?

We also need to be conscious of the relative effort, complexity or scale of each work stream. A project where 95% of the deliverables are produced in a traditional manner will need to be planned and managed in a different fashion than one where the bulk of the scope will follow an agile delivery approach.

Things to consider when faced with such a hybrid project are:

1. Orchestrating delivery cadence from each work stream to ensure that consuming work streams are not incurring prolonged delays in receiving components from providing ones. This can be a challenge when an agile work stream has dependencies on a waterfall work stream. On the other hand, if an agile work stream is delivering components to a waterfall one, there is an increased potential of component inventory buildup which is wasteful and could increase the likelihood of rework.
2. Defining a common set of ground rules is important to avoid creating “us and them” rifts between the work stream teams. For example, if the agile work streams are able to use information radiators or other barely sufficient methods of communicating with stakeholders, figure out how the traditional work stream teams can do the same.
3. Make the life of your approvers and control partners easier by coming up with a common method of capturing key information which they will need in order to bless your project. Requirements capture can be challenging in a hybrid situation as agile teams might prefer to use collaborative tooling such as Jira whereas traditional teams might want to use a business requirements document. Managing reviews and signoffs will be difficult, especially when the outcomes of each work stream are tightly integrated, if you don’t settle on a common approach.
4. Finally, agile mindset and behavior need to prevail across the entire team and not just the agile work streams.

Purists will be shuddering while reading this while pragmatic realists are likely nodding their heads in recognition of how often a hybrid scenario occurs, especially in large organizations where the large variety of contexts eliminates our ability to apply a single methodology to all projects. When it comes to managing such projects a key lesson (plagiarizing Malcom X) is not to preach integration while practicing segregation!