Edwards Demings's derde aanbeveling is hier van toepassing: Cease dependence on mass inspection to achieve quality. Instead, improve the process and build quality into the product in the first place. Onder 'mass inspection' kunnen we bij software-ontwikkeling de testfase na de ontwikkeling verstaan. Bij de toepassing van iteratief ontwikkelen wordt het project verdeeld in een aantal perioden. Bijvoorbeeld 10 perioden van 3 weken. Globaal wordt vooraf vastgesteld welke functionaliteit in iedere periode wordt gerealiseerd. In de eerste perioden wordt het framework geimplementeerd en getest. Iedere periode wordt afgesloten met een demo en discussie met de klant. Hoewel er bij de eerste iteraties nog weinig functionaliteit is gerealiseerd kan wel aangetoond worden dat de gekozen opzet aan de eisen van gebruiksgemak en performance voldoet. Pas dan volgen de functionele toevoegingen.
Belangrijk is de toepassing van 'continuous integration tools' zodat iedere morgen weer een up-to-date toepassing klaar staat om te worden getest. Het is niet de bedoeling dat perioden uitlopen. Wordt een doelstelling niet gehaald dan wordt deze toegevoegd aan de volgende periode. Het is aan de projectmanager te beoordelen of hij verwacht of aan het eind van het project nog perioden moeten worden toegevoegd. In een bekend artikel (Engelstalig) van Martin Fowler wordt de toepassing van iteratieve, 'lichte' ontwikkelmethoden beschreven. Ook RUP (Rational Unified Process) , dat welliswaar geen lichte methode genoemd kan worden passeert hier de revue omdat het eveneens iteratief van opzet is.
De toepassing van bijvoorbeeld Prince2 staat hier los van. Deze procesmethode kan opgevat worden als een schil rondom activiteiten analyse, design, realisatie, testen en implementatie.
De huidige praktijk is veelal "code and fix". De prijs wordt betaald als tijdens de functionele tests nog vele fouten naar voren komen die niet zozeer met de functionaliteit als wel met programmeerfouten en performanceproblemen te maken hebben.