Mit agilen "Sprints“ zur passgenauen Software

Gastbeitrag von João Marques, dipl. Wirtschaftsinformatiker und Gründer der iServices AG

Die Klage "Früher war alles einfacher" haben die meisten Informatiker wohl schon häufig aus Anwenderkreisen gehört. Früher gab es noch einen klaren Ablauf, war genau festgelegt, wann welche Lieferobjekte zu erwarten waren. Insbesondere war auch der Zeitraum zwischen den einzelnen Phasen bestimmt, in dem keine weiteren Vorgaben aus der Informatikabteilung kamen.

Vor allem in der Realisierungsphase, in der eine Datenbank entsteht und die Geschäftsfunktionalität umgesetzt wird, erfuhren die Anwender kaum, wie sich die Applikation Tag für Tag entwickelte. Der Projektleiter und bestimmte Anwender waren die einzigen Ansprechpartner bei Fragen seitens der Entwickler. Ansonsten konnte die Entwicklergruppe davon ausgehen, dass sämtliche Anforderungen während der vorangegangenen Phasen vollständig ermittelt (Vorstudie, Hauptstudie, Detailstudie) und in Form eines Pflichtenhefts dokumentiert wurden. Schliesslich hatte der Auftraggeber dem zugestimmt und in Form eines Projektauftrags die Realisierung freigegeben.
Diese klassische Vorgehensweise ist für die Anwender insofern von Vorteil, als sie in der täglichen Arbeit keine oder nur sehr wenig Zeit für Projekte einräumen müssen. Andererseits gehen dadurch oft innovative Ideen und sinnvolle Änderungen an bestimmten Anforderungen verloren oder dürfen nicht umgesetzt werden, weil sie nicht geplant und budgetiert wurden.

Mögliche Konsequenz: Die Akzeptanz des Endprodukts sinkt, je näher das Ende der Realisierungsphase rückt. In einem gut aufgestellten Projektantrag werden solche Risiken zwar deklariert und eingestuft, um stets zu gewährleisten, bei Bedarf bereits definierte Anforderungen auch noch im Lauf der Realisierungsphase anpassen zu können. Dennoch ist der Nachteil dieser klassischen Entwicklungsmethode, dass sich die Anwender wenig einbringen können und die Softwareentwickler daher kaum Rückmeldungen erhalten. Die Folge ist häufig ein IT-lastiges, allzu starres Ergebnis.

Der Scrum-Ansatz

Zu Beginn eines Projekts wird das Scrum-Team, bestehend aus Product-Owner (vergleichbar mit einem Projektleiter aus der IT- oder Fachabteilung), Entwicklungsteam und Scrum-Master, gebildet. Der Product-Owner sucht sich seine Entwickler idealerweise selbst aus. Die wichtigste Aufgabe des Scrum-Masters ist es, die Scrum-Methode im Unternehmen bekannt zu machen und entsprechend zu vermarkten. Im Gegensatz zum klassischen Entwicklungsmodell bestehen im Scrum kurze Lieferzeiten, sogenannte Sprints oder Iterationen. Sie dürfen höchstens vier Wochen dauern und beinhalten stets sämtliche Tätigkeiten, die in der klassischen Vorgehensweise durch die Phasen Detailstudie, Realisierung, Test, Schulung, Einführung und Abschluss definiert sind. Am Ende eines jeden Sprints muss die fertiggestellte Software „potenziell“ nutzbar sein, d.h., die Anwender haben innerhalb der Sprintdauer die Software mit den Entwicklern geformt, getestet und die umgesetzte Funktionalität abgenommen.

Das Product Backlog ist eine priorisierte Liste, in der alles aufgeführt wird, was das Endprodukt enthalten soll. Im Idealfall ist der Produktrückstand (Product Backlog), wie bei der Sprintplanung zu Beginn des Sprints mit dem Management (Auftraggeber) und den Anwendern als Ziel vereinbart, vollständig erledigt und das Produkt lauffähig. Die Produktrückstandselemente werden dann als Produkt-Artefakte „ad acta“ gelegt. Der nächste Sprint (die nächste Iteration) kann nun geplant und durchgeführt werden.

Mit Scrum wird der Anwender der zu realisierenden Applikation sehr stark in den Entwicklungsprozess eingebunden. Während der gesamten Entwicklungszeit benötigt er daher für das Projekt freigestellte Zeit. Die geforderte Qualität des Endprodukts kann kostengünstig erzielt werden, weil die Anpassungswünsche umgesetzt und Schwachstellen frühzeitig erkannt werden können.

Trotz eines moderierenden und delegierenden Scrum-Masters fällt es Projektbegleitern, die zum ersten Mal mit der Scrum-Methode in Berührung kommen, mitunter schwer, die einzelnen Tätigkeiten innerhalb eines Sprints klar zu umreissen. Kein Wunder, muss man sich doch erst an die Vorstellung gewöhnen, dass ein Software-Produkt innerhalb von max. vier Wochen entworfen, entwickelt, getestet und abgenommen werden soll.

Brücken bauen

Häufig taucht während der Planungssitzung des ersten Sprints seitens der Anwendervertreter die Frage auf, ob ihre Unterstützung benötigt werde. Die Antwort darauf lautet eindeutig „Ja“! Auch hier ist es Aufgabe des Scrum-Masters, die Scrum-Idee im Unternehmen zu verbreiten und zu erläutern. Insbesondere „Neulingen“ muss er möglichst früh Informationen zur Vorgehensweise während der gesamten Entwicklungsphase vermitteln.

Der Übergang von herkömmlichen Entwicklungsmethoden zu Scrum findet am besten über eine gesunde, dem Unternehmen qualitativ wie quantitativ angemessene Informationspolitik statt. Auf den einzelnen Organisationsebenen eröffnen sich dabei verschiedene Wege, das gesetzte Ziel der Einführung und erfolgreichen Etablierung agiler Entwicklungsmethoden zu erreichen: Ganz oben im Organigramm steht die Geschäftsführung. Sie muss hinter dem neuen Modell stehen, die nötigen internen Ressourcen freistellen und auf der strategischen Ebene kommunizieren. Die Vorsteher der Organisationseinheiten müssen die Abteilungen über die Entscheidungen des Managements informieren und adressatengerecht dolmetschen. Auf Projektebene schliesslich nehmen der Projektleiter, innerhalb des Projekts der Scrum-Master den Informationsauftrag wahr. Zur Vermittlung zwischen Informatikern und Nicht-Informatikern kann ein Wirtschaftsinformatiker hilfreich sein, der gleichsam als Brücke zwischen den beiden Welten fungiert.

Fazit

Keine Frage, der Mehrwert von Scrum ist bestechend. Damit Scrum-Projekte allerdings erfolgreich realisiert werden können, müssen sich die Auftraggeber bewusst darüber sein, dass die Vorteile nur durch eigene zeitliche Investitionen zu haben sind. Die Mitwirkungspflichten steigen gegenüber herkömmlichen Entwicklungsmethoden, was von der Geschäftsleitung erkannt und mitgetragen werden muss. Nicht zuletzt ist es die Aufgabe des Managements, die benötigten internen Ressourcen dafür freizustellen und die Idee, die der Scrum-Methode innewohnt, bei allen Beteiligten nachhaltig zu verankern.