Scrum… oder: Das Gedränge bei cosinex geht weiter!

ScrumDie neuesten Trends analysieren, hierbei erfolgreiche Wege auswählen und diese nachhaltig umzusetzen gehört sicher zu den bedeutenden Erfolgsfaktoren für Softwareanbieter, die ihren Kunden langfristig überdurchschnittliche Lösungen anbieten wollen. Diesem Anspruch folgend gehörte die Auswahl des Vorgehensmodells „Scrum“ bei cosinex zu einer der wichtigen Entscheidungen für unsere Software-Entwicklung.

Scrum (engl. „Gedränge“) wird eine Standardsituation im Rugby genannt, bei der sich beide Teams gegenüberstehen und koordiniert einen Spielzug durchführen, um den Ball zu erobern. Die agile Entwicklungsmethode Scrum hat sich ihren Namen aus dem Rugby-Sport entliehen, um genau dies zu betonen: Der Erfolg einer Entwicklung bzw. eines Projekts steht und fällt mit dem Team.

Nachdem wir bereits vor rund zwei Jahren in einem Blog-Beitrag die Anwendung dieser Methode bei cosinex vorgestellt haben, gibt nun Stephan Vielhaber, „Scrum Master“ bei cosinex für unsere Kernlösungen VMS und VMP im Bereich der E-Vergabe, mit diesem Beitrag einen Einblick in die Software-Entwicklung und langjährigen Erfahrungen mit Scrum.

Unsere „Produktphilosophie“

Nicht nur die Entwicklung moderner Software stellt eine Herausforderung dar, sondern vor allem auch ihre Planung und Spezifikation. Dies gilt insbesondere dann, wenn die Umsetzung über einen längeren Zeitraum – oder wie bei „Standardprodukten“ grundsätzlich unbegrenzt – erfolgt. In der Softwareentwicklung eignen sich dazu klassische Vorgehensmodelle des Projektmanagements häufig nicht, die unter der Annahme erfolgen, man könne ein Produkt zunächst vollständig spezifizieren, bevor es dann über einen langen Zeitraum nach formulierten Zielen entwickelt wird. Das Ergebnis wird erst am Ende sichtbar und erfüllt dann im Regelfall nicht mehr die aktuellen Wünsche und Vorstellungen des Kunden.

Mit der steigenden Anzahl an Installationen und Nutzern unserer Lösungen wächst auch die Menge der Kundenwünsche und individuellen Anforderungen sowie der Schnittstellen zu Drittsystemen. Hinzu kommen bundesweite Gesetzesänderungen und zunehmend landesspezifische rechtliche Vorgaben bei der Vergabe Öffentlicher Aufträge, die Anpassungen an unserer Software sowie Ergänzungen erforderlich machen. Aber auch technologisch gibt es laufend den Bedarf, verwendete Bibliotheken und Frameworks auf neueste Versionen zu aktualisieren und Technologie-Standards in die Produkte zu übernehmen. Und schlussendlich sind auch die Betriebsumgebungen unserer Lösungen in einem ständigen Prozess der Veränderung und Aktualisierung.

Alle 3-Wochen ein neues „Release“!?

Für die Entwicklungsabteilung der cosinex ist es längst Normalität, in kurzen Zeitabständen flexibel und schnell auf die sich ständig ändernden Rahmenbedingungen zu reagieren. Wie bereits vor einiger Zeit in diesem Blog berichtet, arbeiten wir bei cosinex nach dem von Ken Schwaber und Jeff Sutherland entwickelten agilen Framework Scrum, welches einen iterativen und inkrementellen Ansatz für die Softwareentwicklung verfolgt. Hierbei werden große Themen zunächst nicht bis ins Detail spezifiziert, sondern nur grob formuliert und als sogenannte “Epics” erfasst, die manchmal nur aus einem Titel bestehen (praktisches Beispiel: „Vergaberechtsreform, Abschaffung der VOL/A oberhalb der EU-Schwellenwerte“) . Einzelne Anforderungen daraus werden in “User Stories” zusammengefasst, die unabhängig von anderen Anforderungen sind und für sich stehend umgesetzt werden können (im vorgenannten Beispiel: „Als Nutzer möchte ich bei der Auswahl der Verfahrensarten nach Maßgabe der neuen Vergabevorschriften unterstützt werden.“). Iterativ bedeutet, dass in kurzen Zyklen, sogenannten Sprints, User Stories spezifiziert, geplant, umgesetzt und getestet werden, sodass sich hiernach jedes Mal ein neues, fertiges Produktinkrement (Release) ergibt. Jeder Sprint umfasst bei uns eine Dauer von drei Wochen und die darin umgesetzten Änderungen als Teil des Epics werden in diesem Zeitraum vollständig abgeschlossen und auslieferbar qualitätsgesichert. Erst danach werden die umzusetzenden User Stories für den nächsten Sprint auf Basis des dann aktuellen Kenntnisstands neu geplant. Teilanforderungen der Epics, die noch nicht umgesetzt sind, können so im Laufe der Zeit noch verändert oder in ihrer Priorität anders bewertet werden. Eine genaue Spezifikation erfolgt erst mit Beginn des Sprints, in dem sie umgesetzt werden. Der genaue Inhalt eines Epics kann sich auf diese Weise noch während der Entwicklungszeit ändern.

Die Vorteile dieses Vorgehens sind vielfältig:

  • Auch wenn nicht alle für ein „EPIC“ erforderlichen Anforderungen umgesetzt sind, steht alle drei Wochen eine neue qualitätsgesicherte und auslieferbare Version unserer Lösungen zur Verfügung.
  • Änderungen, aber auch neue Erkenntnisse, können kurzfristig berücksichtigt werden.
  • Im Gegensatz zu den klassischen „Wasserfall-Methoden“ berücksichtigt unser Vorgehensmodell, dass wir im Hinblick auf die Details am Anfang nicht unbedingt wissen müssen, wo wir funktional in allen Einzelheiten „landen“.
  • Höhere Motivation des Teams durch hohe Eigenverantwortung und Fokus auf die Erreichung des Sprint-Ziels.

Death by Meeting? Nicht mit Scrum!

Ein unverzichtbarer Bestandteil des agilen Vorgehens sind für uns die regelmäßigen Meetings, die im Kontext von Scrum auch als „Scrum-Zeremonien“ bezeichnet werden und das gesamte Entwicklungs-Team bei der iterativen Vorgehensweise unterstützen.

Nicht erst durch den Bestseller „Death by Meeting“ von Patrick M. Lencioni ist klar, dass Besprechungen Strukturen, klare Vorgaben und Ziele benötigen, um dabei helfen zu können, die Effizienz einer Organisation und ihres Vorgehens zu verbessern und nicht durch zu viele und unstrukturierte Meetings und Abstimmungen eher negative Effekte auf die Effizienz aber auch die Motivation zu haben.

Scrum antizipiert diese Risiken und den zum Teil unnötigen Mehraufwand bei unstrukturierten und nicht zeitlich geplanten Abstimmungen zwischen den Beteiligten im Rahmen des Vorgehensmodells und sieht daher von der inhaltlichen Struktur vorgegebene Meetings vor, die durch die Vorgaben den Abstimmungsaufwand zwischen den Team-Mitgliedern und damit den Abstimmungsaufwand deutlich reduzieren.

Beim “Backlog-Grooming” stellt der Product-Owner dem Entwickler-Team die neuesten Themen aus dem “Product-Backlog” vor, einem Pool von zukünftig umzusetzenden Epics und User Stories. Gemeinsam werden hieraus detailierte Anforderungen ermittelt und, wenn diese bereits vollständig bekannt sind, mögliche Lösungen erarbeitet. Fertig spezifizierte User Stories werden vom Entwickler-Team während dieses Meetings oder in dafür gesondert abgehaltenen Schätzklausuren in ihrer Komplexität umrissen und jeweils mit entsprechender Anzahl an “Story Points” gekennzeichnet. Dies hilft später dem Product Owner bei der Priorisierung der Inhalte im Backlog und dient dem Team bei der Sprint-Befüllung .

Zu Beginn eines jeden Sprints findet innerhalb einer Timebox von maximal 4 Stunden die Planungssitzung statt. Gemeinsam mit dem Product Owner wird darin ein Sprint-Ziel vereinbart und das Entwickler-Team legt sich auf die User Stories fest, die es in diesem Sprint umsetzen wird und die damit das “Sprint-Backlog” füllen. Hierbei kommt es darauf an, die richtige Menge an Themen für die kommenden drei Wochen zu treffen. Anders als in den Scrum-Lehrbüchern findet dabei aber keine zusätzliche Zeitschätzung der einzelnen User Stories mehr statt, um damit eine exakte „Zeitfüllung“ des Sprints zu ermöglichen. Unsere Software-Entwickler haben stattdessen im Laufe der fünf Scrum-Jahre bei cosinex ein gutes Gefühl dafür bekommen, den Umfang eines Sprints allein auf Basis der geschätzten Komplexität und Erfahrungen durch vergleichbare Themen aus der Vergangenheit zu bestimmen. Natürlich spielt sportlicher Ehrgeiz der Mitarbeiter und der daraus resultierende Wunsch der Entwickler nach einer Steigerung bei der Sprintzielfestlegung eine Rolle. Auf der anderen Seite kommt es aber eben auch darauf an, das Team nicht durch unrealistische Ziele zu überfordern und ein Scheitern des Sprints bereits in der Planungssitzung vorzuprogrammieren, denn was zu Sprint-Beginn vereinbart wird, ist keine Vision, sondern eine feste Zusage der Entwickler, ein sogenanntes „Commitment“ auf das, was im laufenden Sprint vollständig abgeschlossen werden soll.

In den kommenden drei Wochen nach der Planungssitzung – also im Sprint – wird an der Umsetzung aller für die Erreichung des Sprint-Ziels erforderlichen Aufgaben gearbeitet. Täglich zu derselben Uhrzeit trifft sich das gesamte Scrum-Team zum „Daily Meeting“, einem max. 15-minütigen “Stand Up” (tatsächlich im Stehen), bei dem jeder Entwickler kurz schildert, woran er seit dem letzten Daily Meeting gearbeitet hat, was er bis zum nächsten Daily Meeting für sich plant und was ihn ggf. zur Zeit bei seiner Arbeit behindert. Neben diesem Standardvorgehen aus dem Lehrbuch gehört bei cosinex aufgrund der langjährigen Erfahrung zudem auch eine kurze Selbsteinschätzung des Entwickler-Teams über den bisherigen Sprintverlauf dazu, bei der täglich das bisherige Vorgehen hinterfragt wird und bei Bedarf gemeinsam eine neue Strategie zur Erreichung des Sprintziels vereinbart wird.

Am Ende des Sprints stellt das Team in einem maximal zweistündigen Meeting, dem Sprint-Review, das fertige Produkt-Inkrement und die darin enthaltenen neuen Features der Lösungen vor. An diesem Meeting kann jeder Mitarbeiter des Unternehmens teilnehmen, um sich über den Produktfortschritt zu informieren und dem Team ein Feedback zu geben. Der Product Owner nimmt das Ergebnis ab. Im direkten Anschluss an dieses Treffen findet das letzte Meeting des Sprints statt, die Sprint Retrospective, in der das Team methodisch die guten und schlechten Vorkommnisse des stattgefundenen Sprints sammelt, daraus Ursachen identifiziert und gemeinsam messbare Möglichkeiten zum Ausbau positiver Ergebnisse und Maßnahmen zur Beseitigung von Problemen vereinbart.

Der Vorteil der Scrum-Meetings liegt vor allem in der Ritualisierung: Jedes Meeting findet regelmäßig und innerhalb einer immer gleichen Timebox statt. Alle Teilnehmer kennen das Ziel des Meetings und die dafür zur Verfügung stehende Zeit. Sie konzentrieren sich auf das Wesentliche, um das Meeting mit erfolgreichem Ergebnis abzuschließen.

„Refactoring“ als Chance

Da durch den inkrementellen Ansatz immer wieder neue, fertige Zwischenversionen unserer Software entstehen, sind technische Veränderungen und Korrekturen, sogenannte “Refactorings”, in Scrum nicht nur erlaubt, sondern von vorneherein einkalkuliert. Dabei werden einst fertig implementierte Module wieder und wieder verändert, um bei jedem Sprint neue Anforderungen zu berücksichtigen und zusätzliche Features bereitzustellen. Für unsere hochgradig agilen Entwickler-Teams gehört es deshalb zum Tagesgeschäft, den dabei über viele Jahre entstandenen Programmier-Code regelmäßig “aufzuräumen” und so die Software technisch immer wieder zu verjüngen. Hierbei helfen unter anderem die hausinternen Continues Integration-Systeme, auf denen in jeder Nacht zeitgesteuert eine neue Zwischenversion des Produkts mit den aktuellen Änderungen installiert und durch automatisch ablaufende Tests qualitätsgesichert wird. Zu Beginn eines jeden Arbeitstages kann der Entwickler auf Basis der Testergebnisse frühzeitig etwaige Fehler identifizieren und beheben. Dies geschieht ebenso Sprint für Sprint und parallel zur Umsetzung der User Stories. Nur so kann die Qualität unserer Lösungen auch vor dem Hintergrund der immer größer werdenden Komplexität der Anwendungsfälle sowie immer mehr zu berücksichtigender Schnittstellen und Drittsysteme im Rahmen der ständigen Weiterentwicklung aufrecht erhalten werden.

Fertige Produktinkremente entstehen bei der cosinex also im 3-Wochen-Rythmus und können dem Product Owner als Vertreter unserer Kunden so regelmäßig präsentiert werden. Auf Änderungen der Kundenanforderungen kann immer schnell und ohne hohen Kostenaufwand reagiert werden. Anders als in klassischen Vorgehensmodellen wächst also die exakte Produktspezifikation parallel zur Umsetzung und wird dadurch stets auf einem aktuellen Stand gehalten, der die Wünsche unserer Kunden zeitnah und präzise erfüllt. Die zunehmende Zahl der Vergabestellen, die unsere Software nutzen, und eine nach unserer Einschätzung hohe Kundenzufriedenheit zeigen zudem, dass vor allem unsere Kunden und Nutzer von diesem Vorgehen seit inzwischen über fünf Jahren direkt profitieren.

Zum Autor

Foto Stephan VielhaberStephan Vielhaber (Dipl.-Inf. (FH)) arbeitet seit vielen Jahren im Bereich Produktmanagement und Softwareentwicklung bei cosinex. Seit 2010 betreut er als zertifzierter Scrum-Master bei der cosinex die beiden Kernteams in der Entwicklung.

Beitrag empfehlen

Verwandte Beiträge

  • Das „Gedränge“ bei cosinexDas „Gedränge“ bei cosinexDer 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 […]
  • Niedersachsen entscheidet sich für cosinex und DTVPNiedersachsen entscheidet sich für cosinex und DTVPDas Land Niedersachsen, vertreten durch den Landesbetrieb IT.Niedersachsen, hat sich im Rahmen einer Ausschreibung für die Vergabetechnologie der cosinex entschieden. Hierbei wird unter […]
  • E-Vergabe in deutscher CloudE-Vergabe in deutscher CloudIn den vergangenen Monaten haben wir die Betriebskonzepte und -umgebungen für unsere „Software as a Service“-Angebote (also die Möglichkeit unsere Lösungen im Bereich der E-Vergabe nicht […]
Besuchen Sie uns auch auf

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Formularschutz