Mit Scrum zum Turn-around

„Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte“, so steht es im offiziellen Scrum Guide 2013 von Scrum.org. Ein Beitrag über den Nutzen des Prozessrahmenwerks.

Etwas ausführlicher heißt es dort, Scrum sei ein Rahmenwerk, „innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern“. Von Software steht hier nichts. Dabei wurde Scrum vor rund 20 Jahren ursprünglich eingeführt, um in Software-Entwicklungsprojekten die Komplexität zu managen.

Heute geht es weniger darum, die „Technik“ von Scrum zu erläutern; eher sollte der Nutzen im Vordergrund stehen. Warum bedient man sich dieses Vorgehensmodells? Was bringt es? Die Heidelberger zetVisions AG kann darauf eine klare Antwort geben: Für das Unternehmen hat Scrum letztlich einen großen Beitrag für den Turn-around geleistet. Dass die Softwareschmiede heute profitabel arbeitet, liegt daran, dass es erst mit Scrum möglich wurde, sowohl Standard- als auch kundenspezifische Entwicklungen parallel anzugehen – und damit eine zusätzliche Umsatzquelle durch das Angebot kundenspezifischer Lösungen zu erschließen.

Die „alte Welt“

Um zu verstehen, wie das möglich war, muss zunächst ein Blick auf die frühere Arbeitsweise geworfen werden. Am Anfang eines Release trafen sich Produktmanagement und Entwicklungsleiter, stimmten den Releaseumfang ab und nahmen eine grobe Kapazitätsplanung und Aufwandsschätzung vor. Die Planung war oftmals sehr ambitioniert, da zum einen der Releasetermin durch die geplanten Kundenprojekte vorgegeben war und zum anderen den Kunden bestimmte Features zugesagt wurden. 

Der Entwicklungsleiter verteilte anschließend zentral die Aufgaben. Eine Abstimmung zwischen den einzelnen Entwicklern erschien nicht besonders wichtig. Die Anforderungen wurden im Laufe des Entwicklungsprozesses mit dem zuständigen Produktmanager diskutiert. Als wesentliches Werkzeug diente dabei ein Ticketsystem, in dem Verbesserungen und Fehler aufgeführt wurden. Diese wurden vom Entwickler abgearbeitet, während regelmäßig neue Punkte aufgenommen wurden.

Nachdem ein Thema weitgehend fertiggestellt war, folgte für den Entwickler das nächste. Dabei kamen immer wieder Rückläufer der vorherigen Themen dazwischen. Somit hatte sich im Laufe der Releaseentwicklung eine steigende Anzahl von noch nicht zu 100 Prozent abgeschlossenen Themen angesammelt. Zudem waren die letzten 20 Prozent der umzusetzenden Features nicht nur die zeitaufwendigsten, sondern auch die anspruchsvollsten.

Gegen Ende des Release standen mehrere Testwochen an. Dabei wurden zahlreiche Tickets zu allen Themen aufgemacht. In der heißen Phase der Fertigstellung wurde regelmäßig entweder der Releaseumfang reduziert und/oder der Entwicklungsschluss verschoben. 

Probleme durch dieses Vorgehen:

• Die Entwickler standen häufig unter großem Arbeitsdruck, da die Excel-Listen teilweise schneller wuchsen, als sie abgearbeitet werden konnten.
• Die Abstimmung zwischen den Entwicklern war unzureichend; Abhängigkeiten wurden häufig zu spät erkannt. 
• Durch die Spezialisierung der Entwickler hat sich ein längerer Urlaub oder Krankheit bis in den Support negativ ausgewirkt. 
• Die Anforderungen wurden erst im Laufe des Entwicklungsprozesses angepasst und präzisiert. 
• Eine klare Aussage über den Fertigstellungsgrad des Release war nicht möglich, da viele Themen nur zu 90 Prozent erledigt waren. Die Crux dabei ist, die letzten 10 Prozent benötigen in etwa die Hälfte der Zeit.
• Erst zu einem sehr späten Zeitpunkt wurde klar, welche Features tatsächlich fertiggestellt werden können. 
• Die Qualität des Produktes hat gelitten. 

Veränderungen durch Scrum

Im Herbst 2009 wuchs daher die Bereitschaft, sich mittels einer neuen Entwicklungsmethode anders aufzustellen. Wir haben uns für Scrum entschieden. Dabei war von an Anfang an klar: Scrum sollte nicht als Selbstzweck oder interne „Spielerei“ eingeführt werden, sondern sich an der Leistung für das Unternehmen messen lassen.

Was hat Scrum im einzelnen gebracht?

Die Scrum-Bestandteile (etwa Sprints, Task Board, Sprint-Backlog) helfen schon nach kurzer Zeit zuverlässig, Engpässe und Probleme im Entwicklungsprozess früh zu erkennen, so dass rechtzeitiges Gegensteuern möglich ist. Änderungswünsche von Kundenseite werden jeweils in eine „User Story“ umgemünzt. Jede dieser Stories nimmt den üblichen Scrum-Verlauf. Das Ergebnis: Es etabliert sich nicht nur ein strukturell besserer Prozess in der kundenspezifischen Entwicklung, sondern die Entwickler werden auch vor dauernden, unkontrollierten Eingriffen in ihre Arbeitsabläufe geschützt.

Im Verlauf des Release lassen sich klare Aussagen über Fortschritt und Fertigstellung treffen, was die Planbarkeit der laufenden Entwicklung erheblich verbessert. Hier spielt Scrum seine Stärke aus: Wir erhielten eine Idee der Geschwindigkeit der laufenden Entwicklung und somit ein effektives Steuerungsinstrument. Die vorher übliche turbulente letzte Phase vor Entwicklungsschluss blieb aus. Durch die stabile Entwicklungsgeschwindigkeit können wir in Zukunft schon früh Prognosen über den Entwicklungsverlauf eines Release treffen.

Scrum führt über Instrumente wie „Daily Scrum“ beinah automatisch dazu, den Informationsfluss innerhalb des Entwicklungsteams zu verbessern. Jeder Entwickler ist über die wesentlichen Vorgänge, Fortschritte und Hindernisse tagesaktuell informiert. Missverständnisse werden so reduziert, der häufige Austausch, den Scrum einfordert, erweist sich als hilfreich für das Zusammenwachsen der Teams.

Die Mechanismen von Scrum haben zu höherer Bindung der Entwickler an das Produkt und den Entwicklungsprozess an sich geführt. Scrum hat uns angesichts der verbreiteten Spezialisierung geholfen, den Tunnelblick zu reduzieren, undurchsichtige, oft beklagte Einzelbaustellen aufzuräumen, durch die Mitwirkung jedes Entwicklers am Gesamtprozess die Identifikation mit dem Produkt zu erhöhen und das Know-how zu streuen.

Scrum entzieht dem Top-Management die Möglichkeit, durch Micro-Management in den laufenden Entwicklungsprozess einzugreifen. An diese Stelle tritt der strukturierte Prozess, Stories einzubringen, deren Priorisierung, Abarbeitung und Fortschritt transparent sind. Neben dem gewünschten Effekt des Schutzes des Entwicklungsprozesses ist seine Transparenz für das Management höchst willkommen. An die Stelle von Auswertungen, die immer rückwärts blicken, und Projektplänen, die schon nach wenigen Wochen Makulatur sind, tritt der Blick auf das Heute und in die Zukunft: Die Scrum-Instrumente ermöglichen es, jederzeit den Status Quo zu begutachten und eine Prognose über den Grad der Zielerreichung zu treffen.

Die Qualität der Neuentwicklungen ist erheblich gestiegen. Im Laufe der Zeit wurden von den Teams immer mehr Qualitätssicherungsmechanismen beschlossen, damit die Entwicklungen nach dem Review wirklich „potentiell auslieferungsfähig“ sind. De facto gab es vor Scrum keinen formalisierten Prozess zur Abnahme von Produktfeatures. Die Formalisierung der Abnahme war hier ein wesentlicher Fortschritt. Das Release enthält nichts, was der „Product Owner“ nicht gesehen und für gut befunden hätte und unsere „Definition of Done“ sichert den gewünschten Qualitätsstandard. Dass sich dies wertsteigernd auf das Produkt und entlastend auf den Support auswirkt, versteht sich von selbst.

Fazit

Versucht man, die beschriebenen Veränderungen auf den Punkt zu bringen und zu sagen, was der „Knackpunkt“ an Scrum ist, dann ist es in erster Linie Transparenz. In der alten, von der Wasserfallmethode geprägten Welt waren die erforderlichen Ressourcen nicht transparent genug. Für einen Kundenauftrag wurden die benötigten Tage geschätzt, aber der Zeitpunkt der Fertigstellung war nicht bekannt, weil die Kapazität in der Entwicklung unklar war. Hier gab es mit Scrum eine grundlegende Änderung: Die Kapazität jedes Entwicklers wird auf Stundenbasis – abzüglich „Overhead“ (bspw. für Meetings) – für zwei Wochen geplant. Nach einer Weile hat man Erfahrungswerte, wie viel man in zwei Wochen in die Tat umsetzen kann. Erst diese gesicherte Erkenntnis gab uns die Möglichkeit, sowohl Standard- als auch kundenspezifische Entwicklungen parallel anzugehen. Und das innerhalb des gleichen Entwicklungsteams, des gleichen Entwicklungsprozesses. Ergebnis: zusätzlicher Umsatz durch kundenspezifische Lösungen, an die in der „alten Welt“ gar nicht zu denken war. Ob „Standard“ oder „kundenspezifisch“ – wir können zu jeder Zeit zuverlässige Aussagen darüber treffen, was bis wann fertig ist. Um es klar zu sagen: Wenn man bei Standard- und kundenspezifischer Entwicklung keine Transparenz hat, kann man damit eigentlich nur an die Wand fahren. Scrum – das verdeutlichen die dargestellten Veränderungen – gibt die Möglichkeit, die Kundenzufriedenheit zu verbessern durch gesicherte Qualität, verlässliche Planung und zeitgerechte Lieferung. Wenn sich das am Ende auch in der „Bottom Line“ positiv auswirkt, dann ist das alles andere als ein „kleiner Nebeneffekt“. 

Monika Pürsing, CEO zetVisions AG