Waterfall and agile, the best of friends

I’m tired of the whole “that’s waterfall” and I’m also tired of agile being held up as a magic silver bullet. The truth is something more nuanced and both approaches are fine given the right conditions.

Some projects lend themselves to a greater number of requirements being defined up-front and with less chance of rework occuring (eg. integration of 3rd party interfaces) or require a greater degree of specification because the cost of change later on is greater (eg. selecting the model of embedded MCU or choosing a vendor package to procure).

Other projects lend themselves more readily to just-in-time requirements because the software can be easily iterated and changed (eg. web pages) or is more exploratory in nature (eg. AB testing new features).

Some projects may actually benefit both types of requirement gathering approaches being used in different measures at different times, dependent on the project stage. eg. some fixed, up-front requirements to help bottom out the architecture before iterating user features in an agile, just-in-time approach.

Projects may also decide to do an entire “first pass” of the requirements catalogue, up-front and to provide a high-level scope for the delivery. This should not be confused with ‘Big Design Up Front’ (BDUF) as successive passes of the less clear requirements can be performed whilst others are actually being built. You can even support this further by adopting a ‘lean architecture’ approach, eg. deferring the heaviest architectural decisions until the last possible moment.

The only real problem I see here with any of this is the consequence of using the wrong requirements approach, at the wrong time, for the wrong purpose. And of course, the arguments that happen on LinkedIn over ill defined terminology and near-religious beliefs.