In der IT-Entwicklung haben agile Methoden wie Scrum zunehmend die als „Wasserfall-orientiert" bezeichneten Methoden wie das weitverbreitete V-Modell abgelöst. Zentrale Eigenschaften wie das Vorgehen in kleinen, nutzbringenden Schritten und eine weitreichende Selbstverwaltung der Teams führen dazu, dass der Nutzung agiler Methoden in Entwicklung und Software-Einführung im regulierten Umfeld eher mit Vorsicht oder Ablehnung begegnet wird. Ist diese Skepsis berechtigt? Eine Beschreibung der zentralen Eigenschaften der Scrum-Methodik in Bezug auf die Computervalidierung und die Untersuchung, inwieweit agile Methoden mit den Erfordernissen der Validierung vereinbar sind, bringt Licht ins Dunkel.

Teil 1 dieses Beitrags beschreibt Grundelemente und Erfolgsprinzipien von Scrum, bevor Teil 2 die Chancen und Risiken im regulierten Umfeld untersucht.

Agile Methoden
Als „Agile Methoden" werden Organisationskonzepte bezeichnet, die auf den Gedanken des „agilen Manifest" (www.agilemanifesto.org) beruhen. Es fußt auf der Erkenntnis, dass die meisten Entwicklungsprojekte zu komplex sind, um von Anfang an durchgängig und detailliert geplant zu werden. Daher werden Aspekte wie die intensive Zusammenarbeit mit den Kunden, die angemessene Berücksichtigung der guten Zusammenarbeit aller Beteiligten und die Flexibilität, auf Änderungen zu reagieren, als besonders wichtige Bausteine erfolgreicher Organisation hervorgehoben. Agile Methoden, die diese Ziele umsetzen, sind z. B. Extreme Programming, Crystal oder eben „Scrum".

Verbreitung und Stärken von Scrum
Konnte man die Mitglieder der Scrum Alliance vor ein paar Jahren an einer Hand abzählen, sind es heute bereits über 130.000 - mit steigender Tendenz.
Auch in der Praxis finden Scrum und andere agile Methoden immer mehr Aufmerksamkeit und werden inzwischen von sehr vielen Unternehmen wie z. B. SAP, Microsoft, Google, Oracle oder auch der Telekom eingesetzt.
Als wichtigste Vorteile von Scrum werden erhöhte Entwicklungsgeschwindigkeit, reduzierte Fehleranzahl, verbesserte Mitarbeiterzufriedenheit und verringerte Kosten genannt. Zudem kann bereits zu einem frühen Zeitpunkt ein sich abzeichnendes Misslingen eines Projekts erkannt werden. Dies ermöglicht das frühzeitige Gegensteuern.

Grundelemente von Scrum
Scrum fußt auf den Elementen hoher Interaktion, Eigenverantwortung, kurzen Entwicklungszyklen und kontinuierlicher Nutzengenerierung bereits im Entwicklungsprozess.
Ziel von Scrum ist es, auf Anforderungen, die sich im Laufe des Projekts ändern können, schnell und flexibel zu reagieren, ohne Qualität, Kosten, Motivation und vor allem Nutzen aus Sicht der Anwender aus den Augen zu verlieren.
Grundprinzip von Scrum ist die Unterteilung des Entwicklungsprozesses in kurze Entwicklungszyklen, sogenannte Sprints von maximal 30 Tagen, mit einem definierten Set von Aufgaben, die jeweils zu Beginn eines Sprints aus der Gesamtheit anstehender Entwicklungsanforderungen ausgewählt werden. Innerhalb des Sprints organisiert sich das Team selber. Täglich wird 15 Minuten lang der namensgebende „Daily Scrum" durchgeführt. In ihm werden die erreichten Ergebnisse, die anstehenden Aufgaben und die evtl. bestehenden Hindernisse, die die Arbeit erschweren, besprochen. Zum Abschluss des Sprints werden die Ergebnisse präsentiert, die an sich bereits potentiell auslieferbar und nutzbringend sein sollen.

Erfolgsprinzipien und Stärken von Scrum
Worin bestehen nun die konkreten Erfolgsprinzipien und Stärken von Scrum?
Anforderungen an ein Produkt werden in Scrum nach ihrer Priorität realisiert. Somit ist gewährleistet, dass am höchsten priorisierte Anforderungen zu einem frühen Zeitpunkt umgesetzt werden, Erfahrungen damit gesammelt werden können und so eine hohe Qualität garantiert ist. Nicht unbedingt benötigte Funktionen werden erst zu einer späteren Projektphase realisiert.
Am Ende eines gemeinsam festgelegten, überschaubaren Zeitraums wird immer ein aktueller, lauffähiger Stand des Produkts bereitgestellt. Damit wird sichergestellt, dass die Anforderungen, die innerhalb dieses Zeitraums umgesetzt wurden, problemlos miteinander funktionieren und ineinandergreifen. Erste Erfahrungen mit dem Endprodukt können so gesammelt und notwendige Änderungen frühzeitig berücksichtigt werden. Aufwendige abstrakte Modelle, die mit großem Aufwand erstellt werden, teilweise nicht der Realität entsprechen und oft nicht oder falsch verstanden werden, können auf diese Weise vermieden werden oder kommen nur in vereinfachter Form zum Einsatz.

Schwächen des Wasserfallmodells
Vielfach wird die Notwendigkeit einer agilen Vorgehensweise auch mit den schlechten Praxiserfahrungen bei sogenannten Wasserfall-Vorgehensweisen begründet. Als Wasserfall-orientierte Methoden werden dabei recht allgemein Vorgehensmodelle bezeichnet, die vom Grundprinzip auf nicht-iterativen, phasengestützten Vorgehensweisen, wie beispielsweise dem weitverbreiteten V-Modell, beruhen. Typische weitere Kennzeichen der Wasserfall-Methodiken sind die zugrunde liegende Annahme, dass Probleme und Aufgabenstellungen schon von Beginn an sehr weitreichend rational und analytisch durchdrungen werden und durch entsprechend detaillierte und schriftlich fixierte Planungen angemessen gelöst werden können. Scrum adressiert viele typische Probleme, die mit Wasserfall-orientierten Vorgehensweisen in der Praxis einhergehen:

• Priorisierung
  Während bei Scrum mit jedem Sprint die Aufgaben neu priorisiert werden, findet eine Priorisierung in klassischen Projekten nicht oder nur in geringem Maße statt. Dies führt dazu, dass unbedingt notwendige Funktionalitäten oft erst spät im Projektverlauf implementiert werden. Stellt sich heraus, dass Zeit- und Finanzressourcen zum Projekt­ende knapp werden, führt dies dann zu schlechter Qualität oder übertriebenem Zeitdruck bei wichtigen Funktionalitäten, während weniger wichtige Themen, die vorher bearbeitet wurden, mit ausreichender Ruhe und Ressourcen entwickelt wurden.
• Scheingenauigkeit
  Schon zu Beginn des Projektes müssen alle Anforderungen bekannt sein und mit dem Ziel einer möglichst präzisen Aufwandsschätzung spezifiziert und geplant werden. Dies führt dann oft zu detaillierten und aufwendigen Spezifikationen, die auf unrealistischen Annahmen oder fehlendem Erfahrungswissen beruhen und eine nicht vorhandene Genauigkeit suggerieren. Gleiches gilt für Tests, deren Design nicht dem am Ende des Projekts aktuellen Risikoverständnis entspricht oder identifizierte Risiken aus Zeitgründen vernachlässigen. Dies ist im regulierten Umfeld als besonders kritisch zu werten.
• Fehlende Flexibilität
  Die Abfolge der Projektphasen ist sequenziell und damit unflexibel gegenüber Veränderungen. Dies führt unter Umständen dazu, dass sinnvolle Änderungen aufgrund neuer Anforderungen, die erst während einer späteren Projektphase ersichtlich werden, nicht umgesetzt werden und damit das Produkt bereits bei Fertigstellung nicht aktuell bzw. veraltet ist. Zudem können bei einer strikt sequenziellen Abfolge Lerneffekte nicht berücksichtigt werden.

Ein neuer Validierungsansatz?
Bei vielen großen Projekten, in denen es um die Entwicklung eines Produktes oder die Einführung eines IT-Systems geht, werden agile Methoden heute als Alternative zu den Wasserfall-orientierten Modellen eingesetzt. Somit kann auch die Validierung nicht umhin, sich damit zu beschäftigen.
Auch stellt sich die Frage, ob die Wasserfall-orientierten, kostenintensiven Validierungsansätze, die im regulierten Umfeld bisher verwendet werden, wirklich zu einer signifikant gesteigerten Qualität im Projekt beigetragen haben und ob die erzeugte Dokumentenflut in der weiteren Nutzung noch aktuell gehalten werden kann.