Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Diese Prinzip besagt, das man Änderungswünschen des Kunden grundsätzlich positiv gegenüber stehen sollte, selbst wenn die Produktentwicklung bereits weit voran geschritten ist. Hinter diesem Prinzip steht die Kernidee, dass es sinnvoller ist, eine Realität zu akzeptieren und sich darauf einzustellen, als sich ihr zu verweigern. Wenn man akzeptiert, dass Anforderungen nicht bis ins letzte Detail beschrieben und vorhergesehen werden können, dann sollten sich auch die Prozesse an dieser Realität ausrichten.
Dieses Prinzip darf allerdings nicht als Einladung zum Chaosmanagement missverstanden werden. Für die Anforderungsänderungen muss es auf jeden Fall gewisse Leitplanken geben, damit das Projekt insgesamt in der Spur bleibt. Und genau solche Leitplanken sieht das agile Projektmanagement auch vor. In der Praxis bedeutet dies, dass die Anforderungsbeschreibungen auf einem gewissen Detailgrad verbindlich sein müssen. Der Kunde muss zwar noch nicht in allen Details wissen, was er braucht, aber die Richtung muss klar sein. Eine der wesentlichen agilen Techniken, die sich aus diesem Prinzip ableiten, sind die User Stories.
Was dieses Prinzip darüber hinaus implizit voraussetzt, ist die Möglichkeit, Produktveränderungen auch in späten Entwicklungsphasen zu akzeptablen Kosten vornehmen zu können. Und genau diese Maßgabe hat es in sich, denn nicht bei jeder Produktform ist es kostenneutral möglich, Veränderungen an den Anforderungen auch in späten Entwicklungsphasen vorzunehmen. Software ist da gewissermaßen einmalig. Vorausgesetzt man arbeitet „State of the Art“ mit modernen Methoden der Softwareentwicklung, so kann man viele Änderungen an der Software tatsächlich zu nahezu konstanten Kosten realisieren. Das lässt sich vor allem gewährleisten mit
Diese Faktoren sind jedoch noch immer nicht in allen Softwareprojekten gegeben. Es gibt auch noch Projekte, bei denen die Entwickler mit jeder neuen Funktion eher „Beulen“ an die vorhandene Software programmieren und bei jeder Änderung die Gefahr besteht, dass an irgendeiner Stelle des Programms plötzlich etwas nicht mehr richtig funktioniert. Solche Projekte sind für eine agile Vorgehensweise wenig geeignet, da Änderungen ja mit potentiell hohen Kosten einhergehen.
Je nachdem, in welchem Projekt man sich befindet, wird man ein gewisses Bauchgefühl haben, wenn Änderungen in späten Entwicklungsphasen gefragt sind. Im ersten Fall ein gutes, im zweiten Fall ein schlechtes.