Besser programmieren mit Scrum

Durch agile Software-Entwicklung lassen sich Performance und Prozesse optimieren.

Viele IT-Unternehmen arbeiten bereits seit Jahren erfolgreich mit den modernen Methoden. Die Entwicklerbranche diskutiert seit langem über Scrum und andere Ansätze der agilen Software-Entwicklung.
Bis vor kurzem setzte die ADACOR bei der Entwicklung von Software auf klassische Methoden – wie das Wasserfallmodell, bei dem der Entwicklungsprozess aus einzelnen Phasen besteht.

Jetzt hat auch die ADACOR das Scrum-Framework erfolgreich im Entwicklungsbereich eingeführt. Ich berichte im folgenden Beitrag von unseren Erfahrungen bei der Einführung und den Vorteilen, die sich durch die neue Arbeitsweise ergeben.

5-Phasen-Wasserfallmodell

Der bisherige ADACOR-Entwicklungsprozess wurde vom 5-Phasen-Wasserfallmodell dominiert:

1. Festlegen der Spezifikationen
2. Aufwandsschätzung
3. Übergabe des Arbeitspakets an den verantwortlichen Entwickler
4. Software-Test nach Fertigstellung
5. Übergabe der Applikation an den Kunden

Den Rahmen für jede Phase bilden definierte Start- und Endpunkte, außerdem unterliegt die Ergebnisdokumentation am Abschnittsende strikten inhaltlichen Vorgaben. Dabei gilt das Ergebnis einer Phase als Pflichtvorgabe für die nächste Stufe. Eine neue Phase kann erst gestartet werden, wenn die alte abgeschlossen ist. Das starre Vorgehen stellt das Wasserfallmodell in einen starken Kontrast zu den agilen Methoden. Hiermit lassen sich nur dann optimale Ergebnisse erzielen, wenn zu Projektbeginn bereits alle Anforderungen feststehen und diesbezüglich keine oder nur minimale Änderungen zu erwarten sind.

Grenzen klassischer Entwicklungsmethoden

Das Wasserfallmodell stößt an seine Grenzen, wenn flexible Reaktionen gefragt sind oder sich die Umgebungsbedingungen rasch ändern. Im ADACOR-Entwicklungsbereich stellte sich die Frage nach mehr Flexibilität zu dem Zeitpunkt, an dem die Teamgröße wuchs und Auszubildende in das Team integriert wurden. Parallel dazu stieg generell der Anspruch an ein modernes Projektmanagement und eine optimierte Wissensverteilung im Unternehmen. Schwierigkeiten entstanden bei der alten Methode auch bei der Ernennung von nur einem Entwickler zum Projektverantwortlichen. Dieser betreute das Projekt von Anfang bis Ende allein, mit der Folge, dass dem Vorgesetzten die Übersicht über den Fortschritt fehlte. Darüber hinaus erforderte die Ein-Mann-Verantwortlichkeit große Anstrengungen bei der Priorisierung der Projekte untereinander, denn es kannten sich immer nur wenige Entwickler in einem Projekt aus. Erschwerend kam hinzu, dass diese häufig mit langlaufenden Tasks arbeitstechnisch schon voll ausgelastet waren.

Im Laufe des Projekts konnte außerdem beobachtet werden, dass die Motivation des Programmierers regelmäßig sank. Die Gründe dafür sind nachvollziehbar: So entstand durch die immer gleiche eintönige Arbeit über lange Zeiträume hinweg eine gewisse Monotonie. Zusätzlich fühlten sich die Projektverantwortlichen teilweise allein gelassen oder überfordert. Unter diesen Voraussetzungen war Führung nur schwer möglich. Denn einerseits nahm die Motivation der Entwickler im Projektverlauf ab, andererseits war es für mich als Vorgesetzten kaum noch möglich, sinnvoll in das Geschehen einzugreifen oder den Projektfortschritt realistisch zu kontrollieren.
Entwicklungsprojekte nehmen normalerweise immer eine Komplexität an, die es für nicht tiefgreifend beteiligte Personen nahezu unmöglich macht, sinnvolle Entscheidungen für die weitere Vorgehensweise bei der Programmierung zu treffen. Weiterhin fördert eine solche Arbeitsweise die Entstehung von Inselwissen, was in der Vergangenheit bei Krankheit oder der Urlaubsplanung regelmäßig zu Planungsschwierigkeiten führte.

Zuletzt hatten die Entwickler der ADACOR aber auch dieselben Probleme, die für die meisten Prozessreformer in Richtung Scrum die Hauptgründe für einen Umstieg sein dürften:
Wir verschätzten uns oft bei den Entwicklungsbudgets und wir entwickelten nach einer Spezifikation, die meist nur durch einen einzelnen Architekten in einem Zuge erstellt und an die Entwickler übergeben wurde. Aufgrund der natürlichen Komplexität von Entwicklungsprojekten ist es jedoch kaum möglich, ein perfektes Konzept initial komplett aus dem Boden zu stampfen. Die Folge waren Tools, die sich nicht immer vollständig an den Bedürfnissen Nutzer orientieren.

Kunden profitieren auf vielfältige Weise

Intern haben wir lange Zeit den Schritt zur Einführung von Scrum gescheut. Der Grund für den langfristigen Einsatz der klassischen Entwicklungsmethoden waren Kundenanforderungen, die im Gegensatz zu der Vorgehensweise bei Scrum stehen. Viele Kunden fragen nämlich bereits vor einer Beauftragung nach einem möglichst genauen Maximalpreis sowie nach einer detaillierten, verlässlichen Spezifikation für die jeweilige Anpassung oder Neuentwicklung.

Eine Software nach dem Scrum-Prinzip zu entwickeln, bedeutet für den Kunden zu Beginn weder ein Gesamtbudget noch ein finales Konzept präsentiert zu bekommen. Diese Tatsache mag sich für einige Manager ungewohnt anfühlen, allerdings führt die intensive Zusammenarbeit des Scrum Teams während des Entwicklungsprozesses dazu, dass alle Beteiligten stets eng mit dem Projekt verbunden bleiben. Am Ende erhält der Kunde die Software, die er braucht und nicht eine, die nur anhand von Spezifikationen entwickelt wurde. Darüber hinaus führt das schrittweise Vorgehen bei Scrum dazu, dass die Entwicklung einer Anwendung für den Kunden im Schnitt nicht nur günstiger ist, sondern sie ist optimal an seine Anforderungen angepasst. Ein weiterer Vorteil zeigt sich im frühzeitigen Ausprobieren der Software. Hierbei hat der Kunde die Möglichkeit, den Entwicklungsprozess nach jedem Sprint zu beenden, wenn die Software seiner Meinung nach genug Features enthält.

Projekte auf Basis von Scrum scheitern in der Praxis generell selten. Da die Budgetverantwortlichen in großen Unternehmen trotzdem verstärkt den Fokus auf Planungs- und Budgetsicherheit legen, werden langjährige Softwarekunden der ADACOR zunächst nicht auf Scrum umgestellt.

Der Scrum-Prozess bei der ADACOR

Im Vorfeld der Scrum-Einführung wurde in der Theorie geprüft, ob Scrum die Schwierigkeiten in der ADACOR-Softwareentwicklung potenziell lösen kann und wie eine Implementierung aussehen könnte. Als feststand, dass sich das Framework gut in den Entwicklungsprozess integrieren lässt, startete die praktische Umsetzung. Dafür wurde das Framework zunächst in einem unkritischen Umfeld bei internen Software-Projekten erprobt.

Scrum unterscheidet drei Rollen: Product Owner (Software-Verantwortlicher auf Kundenseite), Entwicklungsteam (ADACOR) und Scrum Master. Der Scrum Master unterstützt den Workflow in erster Linie als Moderator. Außerdem führt er die Scrum-Regeln ein und überprüft deren Einhaltung.
Der Scrum Master gibt den Teammitgliedern keine Anweisungen. Obwohl der Scrum-Prozess einem festen Regelwerk sowie Priorisierungsvorgaben des Management beziehungsweise des Product Owner unterliegt, entscheiden die Entwickler unter Berücksichtigung dieser Vorgaben relativ eigenständig, was sie in den nächsten Sprint aufnehmen. In der praktischen Umsetzung zeigt sich, dass die Selbstorganisation zu einer enormen Motivationssteigerung bei den Entwicklern führt. Häufig nehmen diese sich eher zu viel vor als zu wenig. Es kommt sogar vor, dass sie früher als geplant ein selbst gestecktes Ziel erreichen, sofern der Vorgesetzte den Sprint nicht unterbricht und damit das Commitment (die Verpflichtung) hinfällig wird.

Eine besondere Herausforderung ergab sich bei der ADACOR mangels sinnvoller Alternativen bei der Ernennung eines Teamleiters zum Scrum Masters. Bei dieser Konstellation vermischen sich die Rollen des Moderators und des weisungsbefugten Vorgesetzten. Erfahrungsgemäß funktioniert eine solche Doppelrolle in der Praxis meistens nicht, weil der Teamleiter per se nicht nur moderierend, sondern auch steuernd und vorgebend in das Geschehen eingreift. Nur mit viel Disziplin auf beiden Seiten war es machbar, die Rollen „Teamleiter“ und „Scrum Master“ in einer Person abzubilden. Vermutlich wird das nicht in allen Teams gelingen, da es hier sehr auf die einzelne Persönlichkeit ankommt.

Sprint: fester Zeitraum zur Umsetzung von Anforderungen

Ein Sprint ist ein Arbeitsschritt mit einer im Vorfeld festgelegten Zeitdauer. In unserer Entwicklungsabteilung sind das zwei Wochen. Vor jedem Sprint plant das Scrum Team die Inhalte für den nächsten Sprint. Dabei folgen die Sprints immer direkt aufeinander. Dieses Vorgehen bietet verschiedene Vorteile: Die Zwei-Wochen-Schritte ermöglichen flexibles Handeln, sodass im Vorfeld kein fertiges Konzept erforderlich ist. Das Sprint Team benötigt vom Kunden nur eine Vision und eine User Story (Anforderungen im Product Backlog). Diese Anforderungen aus Kundensicht werden immer mit dem Kunden zusammen erarbeitet. Das Sprint Team erarbeitet im Sprint-Kick-off aus den User Storys anschließend die konkreten Tasks für das Sprint Backlog.

Unterstützt wird ein Sprint durch Daily-Scrum-Meetings. Dabei treffen sich das Entwicklerteam – sowie bei Bedarf der Scrum Master und/oder der Product Owner – täglich zu Arbeitsbeginn zu einem etwa 15-minütigen Informationsaustausch. Hier werden keine Probleme gelöst, sondern es geht für die Teilnehmer darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen.

Der Sprint endet nach zwei Wochen mit einem Review (Prüfung aller Anforderungen, die bisher im Rahmen der Sprints fertiggestellt wurden), um das Product Backlog bei Bedarf anpassen zu können beziehungsweise einer Retrospektive (kritische Überprüfung der bisherigen Arbeitsweise) innerhalb des Teams sowie einem Ergebnisreport an die Stakeholder (Kunde, Anwender, Management).
Damit bietet der Prozess für alle Beteiligten eine hohe Transparenz und die Gelegenheit, sich laufend über den Realisationsfortschritt zu informieren. Bei gleichzeitiger Anwendung des Konzepts der kontinuierlichen Integration (im Englischen bekannt als „continuous integration“) werden alle funktionierenden und abgenommenen Teile der entwickelten Software sogar sofort nach dem Sprint Review in das Produktivsystem eingespielt und damit direkt unter Produktivbedingungen getestet und eingesetzt. Hierdurch kann die Software noch besser und genauer auf die Nutzeranforderungen abgestimmt werden. EInschränkend muss ich sagen, dass sich das Konzept jedoch nicht für sehr betriebskritische Applikationen eignet.

Als sehr positiv erweist sich beim Einsatz von Scrum die Wissensverteilung innerhalb des Sprint Teams. Gab es vor dem Umstieg oft die Situation, dass sich zu wenige Mitarbeiter mit einem Projekt auskannten und das Wissen schlecht verteilt war, führt die Selbstorganisation – besonders bei schwierigen Aufgaben – zu einer automatischen Wissensverteilung im Sprint Team – ohne dass dies der Vorgesetzte forcieren muss. Bei der ADACOR wurde dieser Effekt durch den zusätzlichen Einsatz von Pair Programming als erwünschtes Konzept im Sprint noch verstärkt.

Fazit und Ausblick

Summa summarum hat sich die Performance im Entwicklungsbereich der ADACOR durch Scrum insgesamt verbessert und die Arbeitsprozesse verlaufen generell reibungsloser. Bisher sind noch keine Kundenprojekte in den Scrum Workflow aufgenommen worden, dies kann sich jedoch in Zukunft ändern. Aber selbst wenn Scrum bei langjährigen Kunden nicht vollständig implementiert werden kann und der Entwicklungsprozess weiterhin auf geschätzten Preisen und Spezifikation basieren wird, sollen diese Unternehmen von der Scrum-Implementierung profitieren: Ich möchte herausstreichen, dass wir die Vorteile für den Entwicklungsprozess und die daraus resultierende Steigerung in der Softwarequalität auf jeden Fall an alle unsere Kunden weitergeben – auch an die, die Budgetsicherheit für unabdingbar halten.

Nachteilig ist bei Scrum auf den ersten Blick, dass zu Beginn weder die Gesamtkosten noch ein konkreter Umsetzungszeitraum genannt werden können. Dieser Nachteil verkehrt sich jedoch zu einem Vorteil, denn Schätzungen großer Projekte sind grundsätzlich aufwendig und ungenau. Darüber hinaus verlangen Entwickler stets hohe Sicherheitsaufschläge, um die Unsicherheit bei der Schätzung zu kompensieren. Bei Anwendung des Scrum-Prinzips und einer Bezahlung nach Aufwand, entfällt der Sicherheitsaufschlag für den Kunden.

Ebenso gilt es in nächster Zeit noch ein paar Hürden zu nehmen: Zurzeit besteht die Schwierigkeit, dass sich weder allgemeine Service- und Supportanfragen noch die High Prio Tasks in den Scrum-Prozess integrieren lassen. Beides sind Aufgaben, die schneller erledigt werden müssen, als innerhalb der im Scrum-Prozess vorgegebenen Bearbeitungszeit im Zwei-Wochen-Rhythmus. Erste Lösungsansätze für das Problem wurden bereits entwickelt: Gerade in der Umsetzung befindet sich zum Beispiel die Einrichtung eines Service Desks, der sich außerhalb eines Sprints um entsprechende Tasks kümmern soll.