Scrum ist Mist – oder?

In meinen SCRUM-Master-Kursen spüre ich oft die Frustration. Die Teilnehmer erzählen mir von den Schwierigkeiten, die sie bei der Einführung von SCRUM haben.

Ich habe ihre Erzählungen in einer Geschichte zusammengefasst. Anschließend zeige ich eine Alternative auf. Was sind die Rahmenbedigungen, damit SCRUM doch funktioniert?

Eine traurige Geschichte

Das Management hat eine Idee für ein Projekt. Es dauert Monate, bis der Projektumfang festgelegt ist. Auf Basis des Umfangs wird das Budget genehmigt. Und die Boni der Manager sind an den Umfang gebunden.

Ein ehemaliger Projektleiter wird Product Owner. Ein Entwickler wird SCRUM Master. Das Projekt beginnt.

Der Product Owner spricht mit den Stakeholdern. Jeder hat eine Meinung. Es ist schwer für den Product Owner, Konsens zu finden. Und er fürchtet die Konsequenzen, wenn er die Stakeholder enttäuscht. Er versucht, allen zu geben, was sie verlangen. Zusätzlich zum ursprünglichen Umfang. Das erwartet das höhere Management.

Die Entwickler müssen die unrealistischen Fristen des Product Owners einhalten. Also verzichten sie auf Qualität. Die gelieferte Software ist oft fehlerhaft.

Der Product Owner denkt, die Entwickler seien nicht in der Lage, ordentliche Software zu liefern. Also verwandelt er das Daily SCRUM in ein Status-Meeting. Es folgen gegenseitige Beschuldigungen in der Retrospektive. Und der Druck steigt.

Mehr denn je ist der Product Owner froh, dass es eine separate QA-Abteilung gibt. Sie testet die Software, nachdem das SCRUM-Team sie übergeben hat. Es dauert Wochen, bis die manuellen Abnahmetests abgeschlossen sind. Dann beginnt der Freigabeprozess.

Die Time-to-Market wird nicht besser. Der CEO ist unzufrieden. Mit der Zeit denkt jeder, dass SCRUM Mist ist. Und immer mehr Projekte kehren zu einem phasenorientierten Prozess zurück.

Die Alternative

Vielleicht fühlen Sie sich von der Geschichte nicht angesprochen. Sie liefern häufig funktionierende Software. Und Entwickler, Stakeholder und Kunden sind glücklich. Dann ist das toll.
Vielleicht haben Sie nicht so viel Glück. Sie haben das erlebt, was ich beschrieben habe. Zumindest zum Teil. Dann möchte ich Ihnen eine Alternative aufzeigen.

In SCRUM legt man den Projektumfang nicht vor Beginn der Entwicklung fest. Man kann nicht beides haben: perfekte Vorhersagbarkeit und unbegrenzte Reaktionsfähigkeit auf Änderungen.
Die notwendige Investition ist klar. Es sind die Kosten pro Sprint. Also im Wesentlichen die Löhne der Menschen, die an dem Produkt arbeiten. Hinzu kommen Kosten für Hardware, Material und ähnliches.

Für SCRUM brauchen Sie daher kein vorab festgelegtes Budget. Stattdessen entscheidet das Management, wann ein Release erfolgt. Die Anzahl der Sprints bis zum Release-Datum bestimmt die Kosten. Der gelieferte Umfang ist der, der bis zum Release fertig gestellt wird.

Der Product Owner

Es ist Aufgabe des Product Owners, immer das potenziell wertvollste Feature als nächstes anzufordern. Ein Product Owner muss keinen Konsens mit den Stakeholdern erzielen. Er muss nein zu Anforderungen sagen, die wenig Wert für den Kunden und das Unternehmen bieten.
Damit das funktioniert, muss das Unternehmen den Product Owner dazu befähigen. Er muss die Befugnis haben, zu entscheiden, was Teil des Produkts ist und was nicht.
Ehemalige Projektmanager sind oft keine guten Kandidaten für die Rolle des Product Owners. Product Owner zu sein verlangt einen anderen Führungsstil.
Ein guter Product Owner sagt, was er erreichen will und warum. Aber nicht wie. Er weist niemandem Aufgaben zu. Er setzt keine willkürlichen Fristen, um die Entwickler zu motivieren.

Die Entwickler

Es ist Aufgabe der Entwickler, qualitativ hochwertige Software zu erstellen. Statt einer QA-Abteilung benötigen Sie automatisierte Regressionstests. Ohne sie ist es nicht möglich, die Anwendung in jedem Sprint zuverlässig zu testen. Denn jede neue Funktion kann alten Code brechen.

Continuous Integration

Wenn Sie Integrationsprobleme haben, beginnen Sie mit Continuous Integration. Jeder Entwickler überträgt seinen Code mindestens einmal am Tag in die Mainline.
Wenn Sie ein CI-System verwenden, kann es automatisierte Tests auslösen, und Sie werden sofort wissen, ob die Integration funktioniert. Es wird kaum mehr böse Überraschungen vor dem Release geben. Mittels Continuous Delivery können Sie sogar Ihren Release-Prozess automatisieren.

Wenn sich alle so verhalten, wird niemand überfordert. Sie können ein konstantes Tempo halten. Und Sie werden agil arbeiten.