Die Organisation muss Änderungen, die während oder nach der Entwicklung von Produkten und Dienstleistungen vorgenommen werden, in dem Umfang ermitteln, überprüfen und steuern, der sicherstellt, dass daraus keine nachteilige Auswirkung auf die Konformität mit den Anforderungen entsteht.
ISO 9001, Kapitel 8.3

Die Qualitätsmanagementnorm ISO 9001 (2015) geht im gesamten Abschnitt 8.3 davon aus, dass ein Produkt phasenorientiert entwickelt wird. In Kapitel 8.3.2 geht es um Planung, in Kapitel 8.3.3 um Entwicklungseingaben, in Kapitel 8.3.4 um die Steuerung des Entwicklungsprozesses, in Kapitel 8.3.5 um Entwicklungsergebnisse und in Kapitel 8.3.6 um Änderungen am Produkt.

Diese Gliederung erinnert ganz stark an phasenorientierte Entwicklungsprozesse wie das V-Modell. Entwicklungseingaben, z.B. Fachfeinkonzepte, werden von Domänenexperten zusammen mit dem Auftraggeber in der Analysephase erarbeitet. Im Entwicklungsprozess geht es darum, dass Entwickler das im Fachfeinkonzept beschriebene Ziel so schnell wie möglich erreichen. Die fertigen Entwicklungsergebnisse werden schließlich vom Auftraggeber in einer Abnahmephase überprüft und freigegeben. Das Ende der Abnahmephase ist die kundenwirksame Einführung durch die Betriebsorganisation. Änderungen am Produkt erfordern einen speziellen Prozess, in dem Domänenexperten zusammen mit dem Auftraggeber Änderungskonzepte erstellen. Jedes Änderungskonzept beschreibt eine Veränderung gegenüber dem Produkt, wie es im ursprünglichen Fachfeinkonzept beschrieben wurde. Nach Abschluss der Implementierung für das Änderungskonzept wird die Veränderung in das Fachfeinkonzept integriert. Jede Phase stellt im Sinn der ISO 9001 einen Teilprozess dar. Jeder Teilprozess produziert dokumentierte Information. In der Analysephase handelt es sich um das Fachfeinkonzept oder um Änderungskonzepte, in der Entwicklungsphase sind es technische Konzepte und das programmierte und getestete Produkt, und in der Abnahmephase sind es Abnahmeprotokolle und die Freigabe für die kundenwirksame Einführung.

Ein agiler Entwicklungsprozesse mit Scrum ist anders. Phasen werden aufgebrochen, Analyse, Entwicklung, Test und Abnahme verlaufen in festen Zyklen, den Sprints. Entwicklungseingaben werden vom Product-Owner in einem Backlog erfasst und schrittweise und nach Bedarf analysiert. Das selbstorganisierte Scrum-Team unterstützt bereits an dieser Stelle. Der Entwicklungsprozess wird flexibel am Anfang eines Sprints gemeinsam von Product-Owner und Scrum-Team geplant und ein gemeinsames Ziel nur für diesen Spring formuliert. Dieser Plan wird dann für die Dauer eines Sprints nicht mehr geändert. Die Entwicklungsergebnisse werden nach dem Sprint vom Product-Owner anhand von Akzeptanzkriterien überprüft. Das Produktinkrement wird bewertet, ob es bereits reif genug für den kundenwirksamen Einsatz ist. Der Plan für den nächsten Sprint ist nicht nur abhängig vom Ergebnis des letzten Sprints, sondern auch von anderen Einflüssen. Der Auftraggeber kann jederzeit Änderungswünsche am Produkt formulieren, die der Product-Owner in das Backlog aufnimmt und priorisiert. Direktes Feedback der Nutzer oder anderer Stakeholder im Review an das Scrum-Team sorgt dafür, dass sie das Produkt bekommen, dass sie wirklich brauchen.

Dokumentierte Information in agilen Entwicklungsprozessen ist grundsätzlich anders strukturiert als in den phasenorientierten. Das Backlog ist das zentrale Werkzeug für die Steuerung des Entwicklungsprozesses und gleichzeitig eine wichtige Information über Vision und Ziele für das Produkt. Das Produkt ist eine Einheit aus Dokumentation und ausführbaren Code. Beides wird inkrementell entwickelt.

Mit dem Einsatz von CARDS+ wird nicht nur der programmierte Code vom Scrum-Team Sprint für Spring geändert, sondern auch die Produktdokumentation passend zum Fortschritt fortgeschrieben. Die Tätigkeiten des Programmierens und Dokumentierens sind dadurch sehr ähnlich. In beiden Bereichen wendet das Scrum-Team Prinzipien wie KISS, DRY oder SLA an und sorgt durch Feedback und kontinuierliche Verbesserung für eine angemessene Qualität. Die Vermeidung von unnötiger Duplizierung ist eine wichtige Strategie sowohl im Code als auch in der Dokumentation. Mit CARDS+ gilt jeder abnahmerelevante Testfall als Dokumentation, wird jede Art von code-naher Spezifikation (z.B. eine Schemadefinition) oder sogar Teile vom Code selbst (z.B. eine Konfigurationsklasse) direkt als Dokumentation verwendet, statt sie durch Prosa in menschliche Sprache zu übersetzen. Es gilt der Leitsatz: Programmieren ist dokumentieren.

Agile Entwicklungsprozesse erfüllen die Anforderung der ISO 9001 auch bei der Bewältigung von Änderungen im Produkt. Anders als bei phasenorientierter Entwicklung ist dafür aber kein spezieller Äderungsprozess notwendig.