Scrum

Der Erfolg von Projekten im Bereich der E-Vergabe und damit auch der für die Kunden erzielbare Nutzen hängt neben vielen weiteren Erfolgsfaktoren auch von der Qualität der eingesetzten Software ab. Dabei sind in der Entwicklung komplexer Softwarelösungen unterschiedlichste Vorgehensmodelle im Einsatz. Einige Methoden setzen darauf, alle Anforderungen an Funktionsweise und Architektur schon vor Beginn der Entwicklung abschließend festzulegen. Andere wiederum stellen einen flexiblen Prozess in den Mittelpunkt, in dem die Anforderungen laufend „agil“ angepasst werden können. Überzeugt von der Notwendigkeit einer hohen Flexibilität bei gleichzeitig höchsten Qualitätsanforderungen setzt cosinex seit nunmehr über zwei Jahren auf das Erfolgsmodell von Scrum.

Keinen Beitrag mehr verpassen? Jetzt für unseren Newsletter anmelden und Themen auswählen

Ihre Anmeldung konnte nicht gespeichert werden. Bitte versuchen Sie es erneut.
Ihre Anmeldung war erfolgreich.

Scrum (engl. „Gedränge“) wird eine Standard Situation im Rugby genannt, bei der sich beide Teams gegenüberstehen und koordiniert sowie diszipliniert einen Spielzug durchführen, um den Ball zu erobern. Die agile Entwicklungsmethode Scrum hat sich ihren Namen aus dem Sport entliehen, um genau dies zu betonen: Der Erfolg einer Entwicklung bzw. eines Projekts steht und fällt mit dem Team. Das Entwicklerteam hat deshalb gleichzeitig mehr Freiheiten als bei anderen Methoden, muss jedoch dafür auch Eigeninitiative entfalten und trägt mehr Verantwortung.

Scrum nach Lehrbuch

Viele „Scrum-Evangelisten“ empfehlen gerade am Anfang Scrum nach Lehrbuch umzusetzen und zu praktizieren. Dies wollten wir uns auch zu Herzen nehmen, haben jedoch neben der einschlägigen Literatur auch Erfahrungen Dritter eingeholt.

Bereits die ersten Erfahrungen haben gezeigt, dass dieses Management-Framework für uns genau das richtige ist. Konsequent haben wir daher Mitarbeiter zum ScrumAlliance® Certified ScrumMaster und Certified ProductOwner ausbilden lassen, um unsere Arbeit und unsere innerbetrieblichen Vorgehensmodelle in diesem Bereich noch weiter zu professionalisieren.

Scrum in der Praxis

Die Release-Zyklen unserer Produkte werden in kleinere, überschaubare Einheiten aufgeteilt (sog. „Sprints“), die in den jeweiligen Produkt-Teams geplant werden. Während der meist dreiwöchigen Sprints synchronisiert sich das Team jeden Tag im Daily-Scrum,  einem kurzen Meeting, das im Stehen abgehalten und daher auch „Daily-Standup“ genannt wird (keine Sorge, unsere Mitarbeiter stehen auch sonst öfter vom Arbeitsplatz auf). Am Ende eines Sprints wird in einer „Review“ rekapituliert, was in den vergangenen drei Wochen geschafft wurde. Das Team holt sich zu die umgesetzten Funktionen und Verbesserungen gleichzeitig gezieltes Feedback von weiteren Stakeholdern (wie z.B. Mitarbeitern aus dem Support oder dem Projektbereich).
Um die Entwicklungsarbeit laufend zu verbessern, findet anschließend eine sogenannte „Retrospektive“ statt, in der das Team reflektiert, was gut und was schlecht gelaufen ist. Die Planung für den nachfolgenden Sprint kann jetzt sowohl Erfahrungen aus den vorherigen Sprints berücksichtigen als auch eine für die Releaseplanung relevante geänderte Sachlage.

Ein Vorteil der Aufteilung in Sprints besteht darin, Probleme frühzeitig zu erkennen und so mehr Handlungsspielraum für eine Lösung zu haben. Deshalb haben alle Beteiligten eine Stimme, die sie bei jedem Sprint neu einbringen können: Der „ProductOwner“ achtet darauf, dass die Anforderungen der Kunden umgesetzt werden. Der „ScrumMaster“ sorgt dafür, dass das Team effektiv arbeiten kann. Das „Team“ löst die verschiedenen Aufgaben in eigener Verantwortung.

Scrum und unsere Kunden

Im nächsten Schritt soll auch die Abstimmung mit unseren Kunden und Nutzern weiter verbessert werden. So haben wir bereits im letzten Jahr erste Kundenanforderungen mit Hilfe sogenannter User Storys abgestimmt. Nach dieser Methode gelangt die Anforderungsbeschreibung direkt vom Kunden in die Entwicklungsabteilung oder vice versa an den Kunden.  Hierbei wird versucht, mit einem Satz den Kern der Anforderung aus Sicht eines Nutzers der Software zu beschreiben und diesen mit Akzeptanzkriterien näher zu spezifizieren (welche Bedingungen erfüllt werden müssen, damit der Benutzer die neue Funktion „akzeptiert“). Die ersten Erfahrungen sind sehr positiv verlaufen und wir wollen diesen Weg weiter gehen, damit Kunden und Softwareentwicklung im Hinblick auf die Anforderung die „gleiche Sprache“ sprechen.

Retrospektive

Die Einführung von Scrum bei cosinex hat dazu geführt, dass wir die internen Arbeitsabläufe noch weiter verbessern konnten. Durch die inzwischen auch innerbetrieblich gelebten Prinzipien des Agilen Manifests, auf denen Scrum basiert, konnten bis heute eine Reihe der langfristig angestrebten Ziele erreicht werden: Verbesserte Transparenz über die laufenden Umsetzungsstände, gezieltere Einbindung des Know-hows und der Anforderungen der „Stakeholder“ sowie eine höhere Qualität der Produkte und mehr Effizienz in der Entwicklung. Kurz gesagt, noch bessere Software in motivierteren Entwicklungsteams zu entwickeln, bei denen die Lösung der Anforderungen und Probleme der Kunden im Mittelpunkt stehen.