Scrum failures - Qualitätssicherung in der Softwareentwicklung und im Softwaretest

Der Wechsel von klassischen Entwicklungsprozessen hin zu Scrum beinhaltet einige Stolpersteine für Organisationen. Einige fehlentwickelte Formen haben es schon zu kleiner Berühmtheit gebracht.

Hier biete ich eine kleine Übersicht über ein paar gängige, modische Schlagwörter.

• Der Begriff Scrummerfall beschreibt einen verwässerten agilen Prozess, der die Nachteile von Scrum und Wasserfall vereinigt. Klassische Methoden, Rollen und Prozesse versteifen den agilen Prozess, während agile Methoden jeden Ansatz von klassischer Projektstruktur und Entwicklungsformen unterlaufen. Scrummerfall ist unplanbar, undefiniert, unkoordiniert und endet im Chaos.
  
  Die agile Entwicklung wird als Desaster abgeschrieben.

• WaterScrum hingegen beschreibt ein im Anschluss an einen Wasserfallprozess folgendes Scrum. Die betreffende Organisation arbeitet unverändert in festen Phasen eines Produktlebenszyklus, während die Entwicklung agile Methoden anwendet. Konflikte entstehen, wenn die Organisation an der Schnittstelle feste Anforderungen, ein festes Design und fixe Meilensteine vorgibt. Die agile Produktentwicklung wird teilweise dazu gezwungen gegen die Vorsätze des agilen Manifests zu arbeiten. Das Ergebnis weicht von den Vorgaben ab, da die Rückmeldung zum Wasserfall fehlt. Dies mag für Mitarbeiter und Kunden zufriedenstellend sein, die Organisation tut sich damit aber meist schwer, da sich das Ergebnis meist nicht in gebräuchliche Muster pressen und nicht in gewohnte Kennzahlen ausdrücken lässt.
  
  So müssen auf beiden Seiten Kompromisse eingegangen werden, um eine Zusammenarbeit zu ermöglichen.

• Water-Scrum-Fall geht noch einen Schritt weiter, indem Scrum komplett in den Wasserfallprozess eingebettet wird. Das Produkt des agilen Entwicklungsprozesses wird an eine folgende Phase des Wasserfallprozesses übergeben. Dies kann im schlechtesten Fall ein nach hinten verlagerter automatischer Regressionstest vor dem Softwarerelease sein oder auch  "nur" eine verzögerte Auslieferungsphase an den Kunden. Die agilen Prinzipien "Reagieren auf Veränderungen" und der "Funktionierenden Software" fallen in diesem Fall im Releasesprint dem fixen Abgabetermin zum Opfer. 
  
  Typische Beobachtungen sind ein reduzierter Test der Software gegen Sprintende, nur "großteils" implementierte Funktionen und viele, zahlreiche, kleinere Bugs in der Software.

Das hohe Ziel, den bestmöglichsten unternehmerischen Wert für die Organisation und ein brauchbares und qualitatives Produkt für den Kunden zu liefern, wird in diesen Formen jeweils nur teilweise und unbefriedigend erreicht.