Development Methodologies: Waterfall, Agile and the Auditor

Development methodologies: waterfall, agile, and the auditor. This lesson is about the control implications of how a team builds software, and the exam’s point is that the method changes the evidence, never the objective.

Two projects. The first runs waterfall: a thick requirements document signed off, then design, then build, then a formal test phase, each gate with a signature you can put your finger on. The second runs agile: two-week sprints, a backlog, working software every fortnight, and not a phase-gate document in sight. The agile team tells you there is nothing to audit. Both statements are wrong in the same way.

Start with the two shapes. Waterfall is sequential: each phase completes and is signed off before the next begins. Its strength for an auditor is clear checkpoints and heavy documentation; its weakness is rigidity, change late in the project is expensive. Agile delivers in small increments, working software early and often, adapting to feedback each cycle. Its strength is responsiveness; its cost, for control, is that the neat phase documents give way to many smaller, faster artefacts, and the checkpoints are continuous rather than fixed.

Here is the key. The control objectives are identical across both: requirements are understood, controls are built in, changes are authorised, testing proves the system, and someone accepts it. What changes between the methods is not whether those things happen, but where the evidence that they happened lives.

So the mistake is to read the difference as waterfall is controlled and agile is not. Agile is not uncontrolled; its evidence is distributed rather than absent. Think of it as a different filing cabinet, not an empty one.

Where does agile keep it. First, the product backlog and its acceptance criteria: these are the requirements, written incrementally.

Second, the definition of done: a control gate applied to every increment, often including testing and review before anything is called finished.

Third, the sprint reviews, where the business sees and accepts working software, the continuous form of user acceptance. And fourth, the automated test suites and the version history, which produce control evidence on every single change.

So when a team says we are agile, there is nothing to audit, the auditor’s answer is not to accept it, not to declare the project uncontrolled, and certainly not to order the team back to waterfall. It is to find the evidence where an agile project keeps it. Dictating the methodology is beyond the auditor’s role; assessing whether the control objectives are met, in whatever artefacts the method produces, is exactly the role.

There is a second trap in this area: prototyping. Building a quick, working model to clarify what users actually want is a legitimate, useful technique, and it is built for speed, not to production standard, so it is light on design rigour, controls and testing. The danger is that the prototype works well enough that someone decides to ship it, promoting straight to production a thing that never went through proper design, control specification or testing.

Used well, a prototype informs the build. Used badly, it becomes the build, carrying its missing controls and unproven quality into production. The same caution applies to rapid development generally: speed is the benefit and the risk, and the control objectives cannot be traded away for it.

So carry this away. Do not accept nothing to audit, and do not write the project up as uncontrolled just because it does not produce waterfall’s documents. Judge a methodology by whether the control objectives are met and evidenced, in whatever form the method keeps them.