Calling something out as ‘waterfall’ or holding agile up as the silver bullet of problem-solving isn’t particularly helpful. The truth is more nuanced, and both approaches are fine under the right conditions.
Some projects lend themselves to a greater number of requirements being defined up-front and with less chance of rework occurring (eg. integration of 3rd party interfaces) or require a greater degree of specification because the cost of change is higher later on (eg. selecting the model of embedded MCU or choosing a vendor package to procure).
Other projects lend themselves more readily to just-in-time or emergent 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 benefit from both types of requirement gathering approaches, used in different measures at different times, dependent on the project stage. For example, some up-front requirements to help bottom out the architecture before iterating user features in a more agile, just-in-time approach.
Projects may also do an entire “first pass” of the requirements catalogue up-front to provide a high-level delivery scope. This should not be confused with ‘Big Design Up Front’ (BDUF), as successive refinement of the less clear requirements can be performed while other requirements are being built. You can even support this further by adopting a ‘lean architecture’ approach, eg. deferring the most challenging architectural decisions until the last possible moment.
The only problem I see with any of this is the consequence of using the wrong requirements approach at the wrong time for the wrong purpose.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |