Alle agilen und iterativen Entwicklungsmethoden wie z.B. Scrum, eXtreme Programming oder auch die agile Projektdurchführungsstrategie des V-Modells erfordern einen inkrementellen Entwurf, denn sie gehen davon aus, dass beim Projektstart noch nicht alle Anforderungen bekannt sind und sich erst im Projektverlauf klären. Folglich müssen sich Architektur und Entwurf schrittweise mit den Anforderungen entwickeln. Dabei stellen sich natürlich wichtige Fragen, wie z.B.

• Wie legt man inkrementellen Entwurf so an, dass der Code stets leicht änderbar ist?
• Welche Anteile muss man von vornherein richtig hinbekommen, weil sie sich später nur mit erheblichem Aufwand ändern lassen?
• Wie viel explizite Modellierung betreibt man wann?
• Wann muss man Code umstrukturieren (Refactoring)? Wann hört man mit Refactoring auf?
• Wie verhindert man, dass man in Sackgassen läuft und sehr hohe Refactoring-Aufwände entstehen?
• Welche Qualifikationen benötigen die Entwickler?
• Wer ist für welche Architektur-, Entwurfs- und Modellierungsaufgaben zuständig?
• Welche Rolle spielen Softwarearchitekten beim inkrementellen Entwurf?

Ein Schlüsselelement für inkrementellen Entwurf ist Entkopplung. Schwach gekoppelte Systemteile lassen sich leicht unabhängig voneinander ändern, so dass sich die vielen kleinen Änderungen beim inkrementellen Entwurf jeweils auf einen kleinen Teil des System beschränken. Eine prominente Entwicklungstechnik, um entkoppelte Entwürfe zu produzieren, ist die testgetriebene Entwicklung. Die Kernaussage lautet nämlich: Was sich leicht testen lässt, lässt sich auch einfach ändern.

Die vielen kleinen Änderungen am Entwurf werden mit Refactorings durchgeführt, d.h. durch Verbesserungen des existierenden Codes, die das Verhalten des Systems nicht ändern. Während kleine Refactorings in aktuellen Entwicklungsumgebungen automatisiert durchgeführt werden können, müssen große Refactorings umsichtig geplant werden.