Vorgehen nach Scrum: Die beste Wahl für den Kunden, die Agentur – und das Produkt

In klassischen Software-Projekten zum Festpreis gibt es immer zwei Seiten der Medaille: Einer gewinnt, einer verliert. Die Frage ist nur, ob am Ende der Kunde oder die ausführende Agentur im Regen steht. Und diese Konstellation, die von gegenseitigem Misstrauen geprägt ist, geht nicht selten zulasten der Produktqualität. Eine agile Vorgehensweise nach dem Scrum-Framework dagegen kennt nur Gewinner. In diesem Artikel stellen wir dar, warum Scrum für alle Beteiligten und im Hinblick auf die Qualität des Produkts die bessere Wahl ist.

Das klassische Festpreisprojekt

Bei klassischen Vorgehensmodellen wie einem Festpreisprojekt kommen Auftraggeber und Auftragnehmer schon in der Angebotsphase in eine vertrackte Situation. Der Kunde möchte Sicherheit über die anfallenden Kosten und betreibt deshalb hohen Aufwand bei der Erstellung eines Pflichtenhefts, um möglichst alle Anforderungen an die Software zu beschreiben. Dabei sind alle Details zu bedenken. Die Erfahrung zeigt jedoch, dass die meisten Pflichtenhefte nicht annähernd an einen Punkt kommen, an dem hinreichende Qualität erreicht wird.

Der Auftragnehmer, der die Software entwickeln soll, steht vor dem Problem, die oft vagen Vorstellungen beschätzen und in einen Umsetzungsaufwand übersetzen zu müssen. Dazu kommen noch die Unsicherheiten, die im Rahmen der Software-Entwicklung immer auch eine Rolle spielen: Der Einsatz einer neuen Technologie, eine Teamzusammensetzung, die bisher noch nicht in dieser Form bestanden hat, unerwartete technische Probleme z.B. beim Anbinden von Fremd-Software oder Web-Services usw. usf.

Für all diese Unwägbarkeiten soll die Agentur die Hand ins Feuer legen, indem sie einen Festpreis garantiert. Wie löst der Auftragnehmer wohl dieses Dilemma? Er wird hohe Puffer einrechnen, um das Risiko möglichst gering zu halten, dass er am Ende mit Verlusten aus dem Projekt geht.

Festpreisprojekte enden immer auf zwei Arten: Entweder ist die Software-Entwicklung so reibungslos verlaufen, dass die Agentur die Anwendung weit unter Budget entwickeln konnte. In diesem Fall hat der Kunde zu viel für die Software bezahlt. Oder der Entwicklungsprozess war gespickt mit Problemen und die Agentur legt kräftig drauf. Dann kommen noch weitere, nicht zu unterschätzende Probleme zum Tragen: Wird das Budget knapp, muss der Auftragnehmer natürlich die Kosten senken. Das wird sich garantiert auf die Qualität der Software und ihre spätere Wartbarkeit auswirken.

Wenn man diese Situation gründlich durchdenkt, wird schnell klar, dass der Gedanke, ein wirklich cooles Produkt für den Kunden entwickeln zu wollen, dabei in den Hintergrund gerät. Wie das Projekt schließlich auch ausgeht: Immer wieder reiben sich die Parteien in kleinteiligen Diskussionen auf, in denen es darum geht, ob eine bestimmte Funktionalität nun Zusatzaufwand ist oder nicht, statt sich auf das Wesentliche konzentrieren zu können.

Richtig dramatisch wird die Situation, wenn die Agentur eine Software liefert, die zwar die Anforderungen aus dem Pflichtenheft erfüllt, aber nicht dem entspricht, was sich der Kunde vorgestellt hat. Gründe kann es verschiedene geben: Oft sind Probleme funktionaler Natur, womöglich ist die Software ein Offenbarungseid in Sachen Usability usw. In diesem Fall muss der Kunde für einen Trümmerhaufen bezahlen, mit dem er nichts anfangen kann.

Fazit dieser Überlegungen: In aller Regel gibt es in solchen Projekten einen Gewinner und einen Verlierer – nur weiß man vorher nicht, wer auf welcher Seite stehen wird. Beide Seiten verschwenden wertvolle Energie, die an anderer Stelle wesentlich besser eingesetzt werden könnte. Und das größte Problem besteht darin, dass nicht das bestmögliche Produkt geschaffen wird.

Was sollte sich gedanklich verändern?

Das gerade charakterisierte Vorgehensmodell ist davon geprägt, dass beide Seiten versuchen, Absicherungen und Sicherheitsnetze einzuziehen – jeweils zum eigenen Vorteil. Es liegt in der Natur dieses Ansatzes, Vertrauen grundsätzlich auszuschließen.

Genau hier muss jedoch ein Umdenken erfolgen. Die Kernaussage eines Vorgehensmodells in der Software-Entwicklung sollte lauten: "Wir wollen zusammen ein cooles Produkt schaffen, das den maximalen Business Value für den Kunden erzielt."

Ich bin fest davon überzeugt: Nur wenn beide Vertragsparteien dass Gefühl haben, vertrauensvoll und fair zusammenzuarbeiten, und ein gemeinsames Ziel teilen, kann das Produkt ein Erfolg werden.

Wie lassen sich Vertrauen und die Arbeit an einem gemeinsamen Ziel erreichen?

Wer sich etwas intensiver mit Software-Entwicklung beschäftigt, dem wird schnell klar, dass das Vorgehen von Scrum genau die Anforderungen abdeckt, die in jedem Software-Projekt immer wieder auftreten.

Änderungen der Anforderungen müssen einfließen können
Ein Sprint hat in vielen Teams einen Entwicklungszyklus von zwei Wochen. Für diese 14 Tage ist festgelegt, was entwickelt wird – das lässt sich nicht mehr ändern. Diese Festlegung ist auch sinnvoll, denn das Team soll sich in dieser Zeit auf die Entwicklung konzentrieren können – ohne Ablenkung durch von außen eingekippte Änderungen.

Das Zeitfenster eines Sprints ist jedoch so klein, dass keine grundlegenden Eigenschaften der Software unwiderruflich festgelegt werden. Der Product Owner hat die Möglichkeit, seine Priorisierung des Backlogs zu ändern oder auch neue Funktionen in Form von User-Stories einzubringen. Direkt im nächsten Sprint wird das Entwicklungsteam auf die Änderungen reagieren und die geänderten Prioritäten berücksichtigen.

Stetige sichtbare Kontrolle der Ergebnisse für kontinuierliche Verbesserungen
Zu jedem Sprint gehört ein Sprint-Review-Meeting, in dem das Arbeitsergebnis vorgestellt wird. Der Product Owner hat direkt die Möglichkeit, Änderungen einzubringen und Fehlentwicklungen entgegenzuwirken.

Transparente Kontrolle des Projektfortschritts und der zu erwartenden Kosten
Durch die Beschätzung aller Funktionen im Produkt Backlog und durch die Leistung des Entwicklungsteams ermöglicht Scrum nach jedem Sprint immer genauer werdende Prognosen im Hinblick auf Dauer und Kosten des Projekts. Das ermöglicht ein sehr frühes Erkennen und Gegensteuern bei Problemen.

Go-live zum frühestmöglichen Zeitpunkt
Das Scrum-Framework sieht vor, das nach jedem Sprint ein funktionierendes Produkt vorliegt. Prinzipiell ist also nach jedem Sprint ein Go-live möglich. Sobald alle wirklich wichtigen Funktionen implementiert sind, kann die Software direkt eingesetzt werden.

In diesem Zusammenhang hat Scrum einen weiteren Vorteil: Oft kristallisiert sich erst während der Entwicklung der Software heraus, welche Funktion wirklich wichtig ist und von welcher man nur glaubte, sie wäre es. Durch die kontinuierliche Neubetrachtung und Neubewertung der Features ergeben sich die tatsächlichen Prioritäten. Somit ermöglicht das Vorgehen nach Scrum, dass das erste verwendbare Produktinkrement frühzeitig Nutzen stiften kann.

Budget wird immer auf die To-dos mit dem höchsten Business Value verwendet
Aus der bereits beschriebenen ständigen Neubewertung bzw. Präzisierung der Prioritäten folgt, dass das Team immer an den wichtigsten Dingen arbeitet. Die Vorteile liegen auf der Hand: Die Entwicklung kann jederzeit in die richtige Richtung gelenkt werden und es besteht immer die Möglichkeit, das Budget unter Kontrolle zu halten, indem die Entwicklung nach der Auslieferung der wichtigsten Funktionen pausiert wird.

Fazit

Viele Software-Projekte bei //SEIBERT/MEDIA haben gezeigt und bestätigen es immer wieder: Das Scrum-Modell schafft beste Voraussetzungen für die Bildung der oben angesprochenen Vertrauensbasis und für die Zusammenarbeit zwischen Agentur und Kunde auf ein gemeinsames Ziel hin.

Der Erfolg wiederum bewirkt, dass die Arbeit dem Entwicklungsteam Spaß macht. Für //SEIBERT/MEDIA ist Scrum eindeutig ein Erfolgskonzept – und für die Kunden, die bereits Scrum-Projekte mit uns durchgeführt haben, ist das nicht anders.

Weiterführende Informationen

Haben Sie Fragen zu agilen Vorgehensweisen in der Software-Entwicklung? Möchten Sie Agilität in Ihrem Unternehmen einführen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren in Ihrem Unternehmen – sprechen Sie uns einfach unverbindlich an. Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.

Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Agile vs. Wasserfall-Modell: Was die Forschung sagt
Praxistipps für Entwickler beim Einsatz von Scrum
Agile Projekte und Scrum in der Praxis: Elemente, Nutzen, Tools, Hürden
Scrum in der Praxis: Ein Team startet durch


Mehr über die Creative-Commons-Lizenz erfahren