Suche
Ein Erfahrungsbericht

Skalieren mit Scrum und Microservices: Big Bang oder langsame Transformation?

René Schröder, Thomas Kerschis

© Shutterstock / Rawpixel.com

Stellen Sie sich vor, Sie haben ein recht erfahrenes Entwicklungsteam vor sich, das Sie davon überzeugen sollen, seinem monolithischen System nichtmonolithische Produkte hinzuzufügen. Mit welchen Werkzeugen gelingt das? Wir berichten von unseren Erfahrungen.

Bei diesem Projekt lag der Hauptfokus im ersten Schritt darauf, aus einem Process Owner einen Product Owner zu formen. Dieser sollte als Teil des Scrum-Teams etabliert werden, um nützliche, den Sprint Goals entsprechende oder benutzerzentrierte Produktinkremente entwickeln zu können. Was nützlich war und was nicht, erarbeiteten wir zusammen mit dem Product Owner, den Stakeholdern und den Entwicklern in verschiedenen Workshops, in denen wir unter anderem User Story Mapping einsetzten. Daraus sollte ein einheitliches Verständnis für einzelne MVPs (Minimal Viable Products) abgeleitet werden, die verschiedene Fragen der Kunden und der internen Anforderer beantworten sollen.

Die Fragen, die es zu beantworten galt, waren teils technisch, teils fachlich. Eine große Herausforderung stellte sich uns, als klar wurde, dass diejenigen, die die Anforderungen seitens der internen Einheiten in User Stories übertragen sollten, immer noch der alten Wasserfalllogik und dem Konzept der Feinspezifikation verhaftet waren. So mussten wir das Konzept MVP klar und nachhaltig im Product-Owner-Kreis verankern. Das Scrum-Team glich die Sprintziele entsprechend daran an, um die gestellten Fragen mit höherer Wahrscheinlichkeit beantworten zu können. Der Umgang mit den jeweiligen MVPs und den damit verbundenen Sprintzielen gelang nach jedem Sprint besser. Der Fokus auf die kleineren und kompakteren Schritte wurde immer besser.

Die erste Phase des agilen Transformationsprozesses konnte dahingehend erfolgreich abgeschlossen werden, dass sich daraus die nächsten Schritte eines ganzheitlichen agilen und integrierten Prozesses ableiten ließen. Das gesamte Scrum-Team wurde in der ersten Phase zu einhundert Prozent intern gecoacht. Das bedeutet, dass wir als Teil des Teams und die Teammitglieder selbst das Coaching übernahmen und die Idee eines agilen Prozesses gemeinschaftlich weitertrugen. Eine zentrale Erkenntnis aus der ersten Phase war, dass es für die zweite Phase notwendig wäre, sich weitere externe Unterstützung zu holen. Folgende Gründe machten das deutlich:

  1. Es kamen sehr spezielle Themen und Fragestellungen an die Oberfläche, die für das Projekt maßgeblich waren. Es war entscheidend, diese Punkte detailliert zu klären und den entsprechenden Grundstein zu legen.
  2. Aufgrund der erforderlichen Transformationsgeschwindigkeit wurde damit auch ein höherer Druck aufgebaut.
  3. Die internen Coachingressourcen waren begrenzt und mussten gezielt erweitert werden.

In der zweiten Phase lag der Fokus auf der Weiterentwicklung der Softwarearchitektur. Als Kern wählten wir einen Microservices-Ansatz, da er sehr gut zu unserem selbststeuernden Organisationsansatz passte. So konnten wir im späteren Verlauf der Transformation die Entwicklungsteams unabhängiger arbeiten lassen, da sich die Microservices, so wie wir sie geplant hatten, unabhängig von anderen Komponenten gestalten ließen.

Zu dem Zeitpunkt war jedoch der Erfahrungsschatz in Bezug auf Microservices im Entwicklungsteam ausschließlich theoretischer Natur. Um das gesamte Team tiefer in das Thema einzuführen und auch die Frage nach dem „Wie“ direkt mit einem Experten klären zu können, setzten wir auf eine intensive Drei-Tages-Schulung, die genau auf unser Projekt zugeschnitten wurde. Nach der eher theoretischen Schulung wurden im Team die ersten MVPs mittels Microservices umgesetzt und anschließend im Sinne eines agilen KVP (kontinuierlicher Verbesserungsprozess) in Workshops mithilfe von externen Experten bewertet und Verbesserungspotenzial herausgearbeitet.

Durch dieses begleitete Vorgehen fühlte sich das Entwicklerteam von Sprint zu Sprint sicherer in der Umsetzung der einzelnen Microservices und damit der MVPs. Es kristallisierte sich in den einzelnen Sprints heraus, dass der Produkt Owner zusätzlich Unterstützung benötigt, um die User Stories in einer verständlichen Form (CCC, INVEST) aufbauen zu können. So bekam er im Verlauf der zweiten Phase Unterstützung durch fachkundige Businessanalysten und einen Customer-Service-Mitarbeiter. Somit konnten zwei weitere Sichtweisen in den Anforderungsprozess einfließen. Durch diese erweiterte Erfahrung konnten die Anforderungen aus Kundensicht besser erfasst und in User Stories umgewandelt werden. Doch gab es aufgrund der heterogenen Erfahrungen der einzelnen Personen Kommunikationsprobleme – was mitunter seine Ursache darin hatte, dass wir bisher kein einheitliches Vokabular implementiert hatten.

Auch hier griffen wir auf externe Berater zurück, die eine Basisschulung veranstalteten, mit dem Ziel, einen einheitlichen Wortschatz bereitzustellen und damit die unterschiedlichen Wissensstände anzugleichen. Es gab bereits während der Schulung spannende Aha-Erlebnisse. So waren einige Teammitglieder überrascht, dass mehr eigenes Wissen vorhanden war als ursprünglich gedacht. Das hatte den Nebeneffekt, dass das Selbstbewusstsein stieg und sich mehr zugetraut wurde. Durch dieses Angleichen wuchs auch das gesamte Team, bestehend aus Product Owner, Analysten, Customer Service und Entwicklungsteam, stärker zusammen.

Transformationsprozesse sind für Unternehmen immer eine Herausforderung. Die Gründe dafür sind vielschichtig. Angefangen bei einer nicht erkannten Notwendigkeit über ein Ignorieren bis hin zu einer sichtbaren Angst, nach einer erfolgten Transformation ohne Aufgabe dazustehen – diese Gründe sind aus organisatorischer Sicht verständlich. Aus diesen Gründen heraus hatten wir uns, anstatt mit einem Big Bang zu starten, von Anfang an für den evolutionären Weg entschieden. Einen Weg, der auch in Kanban anzutreffen ist und als Kaizen bezeichnet wird. Wir bedienten uns einiger Mechanismen aus Kanban, um den Change-Prozess auf mehreren Ebenen zielgerichtet zu unterstützen und sichtbarer aufzubauen. Es war uns wichtig, dass jeder wusste, was ihn erwartet.

Skalieren mit Scrum und Microservices

In Anlehnung an Kanban analysierten wir den bestehenden Entwicklungsprozess. Um keine Widerstände hervorzurufen, beließen wir alle Rollen vorerst unverändert – auch das ist ein Gedanke, den wir von Kanban abgeschaut haben. Werden die Prozesse zusammen mit den Rollen auf einen Schlag verändert, ist oft mit Widerstand der Personen zu rechnen, deren Rollen geändert werden. Auch wäre eine gleichzeitige Änderung nicht mehr evolutionär, sondern ginge eher Richtung Big Bang – ein Vorgehen, das vermieden werden sollte.

In klassischen Unternehmenskontexten werden Produkte meist noch mittels Projekten entwickelt, es gibt pro Projekt einen Lenkungsausschuss, der einen Projektleiter bestellt, es werden Businesspläne erstellt, Reports geschrieben und vieles mehr. Diesen Prozess stellten wir fürs Erste nicht in Frage. Unser Ansatz war es, ihn durch einen Prozess an das Scrum-Team zu koppeln, der von der Wasserfalllogik geprägt ist, mittels PRINCE2. PRINCE2 Agile erschien uns aus mehreren Gründen in der aktuellen Situation hilfreich:

  • Es ist eine etablierte Projektmanagementmethode, die bestehenden Rollen können wie gewohnt arbeiten und finden ihren Platz.
  • PRINCE2 Agile beschreibt mit sieben Grundprinzipien, sieben Themen und sieben Prozessen, wie ein Projekt ablaufen sollte. Das gibt dem Team und dem Management eine gewisse Struktur an die Hand.
  • Der Charme von PRINCE2 Agile in Kombination mit Scrum ist, dass auch PRINCE2 und PRINCE2 Agile den Focus auf das zu entwickelnde Produkt legen.
  • Auch die Prozessempfehlung lässt sich gut mit Scrum kombinieren: PRINCE2 teilt ein Projekt in Managementphasen, nach denen gezielt geprüft wird, ob der Business Case noch erfüllt ist.
  • Da wir in dieser Phase nur über ein Scrum-Team verfügten, entschieden wir uns bewusst, nur mit PRINCE2 Agile zu starten, da die implementierte Mechanik vollkommen ausreichte. Eine Entscheidung, welches Agile Skalierungsframework wir später bei mehreren Scrum-Teams (bspw. LeSS, SAFe oder Nexus) einsetzen werden, stellten wir zurück.
  • PRINCE2 Agile eröffnete uns die Möglichkeit, den Entwicklungsprozess mittels der Kanban-Methode Stück für Stück zu beleuchten und zu verbessern.

Die Projektleiter aus den anfordernden Abteilungen wurden ermutigt, ihre Projekte in kürzeren Abschnitten zu planen und die Anforderungen entsprechend zu formulieren. Wir setzten die Dauer für eine Managementphase auf vier Wochen, die Sprints waren von jeher zwei Wochen. Unser Ziel war es, zusammen mit den Abteilungen nach jeder Managementphase – nach zwei Sprints – ein Produktinkrement zu releasen. Die Vision umfasste zwei Managementphasen, in denen das Management seine Anforderungen grob einsteuern konnte. Damit war der neue Entwicklungsprozess über alle Bereiche und Phasen in agiler Form entwickelt und implementiert worden. Die über die ersten Monate entwickelten MVPs gaben dem Team eine gewisse Sicherheit, und die Velocity des Scrum-Teams konnte ein Stück weit besser abgeschätzt werden. Mittels dieser, den geschriebenen Epics und den User Stories konnten wir eine grobe Releaseplanung für unser Big Picture entwickeln.

Lesen Sie auch: Die Scrum-Revolution

Das Big Picture war zu dieser Zeit noch sehr grob, auch gab es an diversen Stellen noch Unsicherheiten, welche Produkte mit welchen Featuresets zu welchem Zeitpunkt entwickelt werden sollten. Für die nächsten Wochen musste sich zeigen, wie der Teamaufbau gelang, um das angesprochene Featureset schärfen zu können. Vom Teamaufbau war im Speziellen abhängig, welche Möglichkeiten der Skalierung uns in Zukunft gegeben sein werden. Unser Ziel war es, sechs Scrum-Teams zu etablieren, die entweder zusammen an einem Produkt, entkoppelt durch Microservices, oder getrennt an mehreren Produkten arbeiten sollten. Das entstandene zweite Scrum-Team wurde mittels PRINCE2 Agile gut in das bestehende Gefüge integriert. Das erste Produkt konnte mittels der zwei Scrum-Teams zeitnah auf den Markt gebracht werden. Parallel dazu wurden weitere MVPs – teilweise auch Spikes – entwickelt, um architektonische Fragen zu beantworten und technische Risiken zu minimieren.

 

Geschrieben von
René Schröder
René Schröder
René Schröder ist seit dem Jahr 2001 als zertifizierter Projektleiter (AXELOS, IPMA/GPM, Scrum Alliance) und Softwarearchitekt (iSAQB) erfolgreich am Markt unterwegs. Er ist Experte für die erfolgreiche Implementierung eines ganzheitlichen Methodenmixes bestehend aus Projektmanagement, Softwarearchitektur und Testing in komplexen Entwicklungkontexten, um langfristig den Projekt- und Produkterfolg sicherzustellen. Website: regsus.de, E-Mail: r.schroeder@regsus.de; rs@wizardsofecommerce.com
Thomas Kerschis
Thomas Kerschis
Thomas Kerschis, CTO, Dipl. Kaufmann, Wirtschaftsinformatiker und Arbeits- und Organisationspsychologe. Seit 1991 als Entre- und Intrapreneur hauptsächlich in komplexen Handelskontexten unterwegs. Er ist Experte in der Etablierung moderner Organisations- und Systemarchitekturen in Konzernumfeldern und dem Aufbrechen von Verkrustungen und Stillständen in Unternehmen zur Einführung ganzheitlicher Digitalisierungsansätze. Website: wizardsofecommerce.com E-Mail: tk@wizardsofecommerce.com, tkerschis@me.com
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.