Suche
Scrum als Werkzeug der Transformation

Wie Sie starre Strukturen aufbrechen – mit Scrum!

René Schröder, Thomas Kerschis

© Shutterstock / OnBlast

Unternehmen mit differenzierten Konzernstrukturen tun sich teilweise schwer, sich auf neue Anforderungen seitens des Markts einzustellen. Vielfach gelangen aktuelle Projektvorgehen in eine Sackgasse, da die Strukturen und Systeme solcher Projekte maßgeblich durch unflexible und starre Mechanismen gesteuert und eingebunden sind. So auch im Fall eines Unternehmens, bei dem wir geholfen haben, Wege aus der Sackgasse zu finden – mit Scrum.

Scrum als Werkzeug der Transformation

Das Unternehmen musste zwingend auf sich ständig verändernde Marktgegebenheiten reagieren. Neue Wettbewerber betraten den Markt, und disruptive Geschäftsmodelle griffen einzelne Marktpositionen an. Steigender Kostendruck zwang dazu, effizienter zu werden, und sinkende Margen dazu, neue Geschäftsmodelle zu entwickeln. Eine zunehmende Digitalisierung in allen Umfeldern erforderte ein schnelles Reagieren darauf. Daraus ergab sich die Notwendigkeit, vorhandene und geplante Projekte im Digitalbereich neu zu bewerten.

Es galt, diese Projekte in Bezug auf Flexibilität, Time to Market, Nachhaltigkeit, Disruption und Effizienz zu betrachten. Das Ergebnis war, dass das aktuelle Set-up der Projekte nicht darauf ausgelegt war, diese Themen und Kriterien zu erfüllen. Es war nicht möglich, auf neue Wettbewerber, auch branchenfremde oder die großen digitalen Pure Player, in adäquater Form reagieren zu können. Das Alleinstellungsmerkmal des Unternehmens ist nach wie vor der enge Kundenkontakt und das hohe fachliche Know-how der Mitarbeiter.

Aus dieser Situation heraus resultierte der Projektauftrag, die von einer Beratung vorgeschlagene Systemarchitektur auf Basis der vorhandenen Systeme zu überprüfen, zu bewerten und gegebenenfalls zu überarbeiten oder neu zu skizzieren. Diese skizzierte Architektur sollte anschließend im Rahmen eines Projekts mit dem Ziel umgesetzt werden, eine neue Onlinewelt für alle Produktbereiche aufzubauen – one face to the customer. Im Sinne einer ganzheitlichen Betrachtung wurden sowohl Strategie, Strukturen als auch Systeme einer umfangreichen Analyse unterzogen, um daraus Ansatzpunkte abzuleiten, die alle Bereiche mit einbeziehen.

Dabei wurde klar, dass die Strukturen maßgeblich dafür verantwortlich waren, wie in der Vergangenheit Systeme ausgewählt, Architekturen gebaut und Teams geführt wurden. Die Strukturen waren von politischen Verflechtungen und festen hierarchischen Strukturen geprägt. Die darin gelebten Prozesse waren dazu ausgelegt, die vorhandenen Strukturen weiter zu festigen und Zustände zu bewahren. Sätze wie „Das haben wir immer schon so gemacht“, „Es müssen doch alle eingebunden werden“, „Ich kann das nicht entscheiden, das muss meine Führungskraft machen“ oder „Wir müssen erst alle Anforderungen kennen und das große Bild beschrieben haben, bevor wir loslegen können“ sind nur einzelne Beispiele der Reaktionen. Gerade in Stresssituationen verfiel die Organisation in althergebrachte und tausendfach erlebte Reaktionsmuster.

Aus diesen Verhaltensmustern und hierarchischen Strukturen ergaben sich ähnlich komplexe und monolithisch hierarchische IT-Systemarchitekturen. Bei den Systemstrukturen kam insbesondere eine klassische, in großen Unternehmen vorzufindende Logik zur Anwendung: Alles aus einer Hand wird uns helfen, nachhaltig in die Zukunft zu gehen. Die daraus resultierenden durchgängigen Abhängigkeiten zwischen klassischer IT (Legacy-Systeme) und E-Commerce-IT führten dazu, dass die Entwicklungen im E-Commerce-Bereich nahezu zum Stillstand gekommen waren. Die Systeme wirkten mehr hemdsärmlig als durch Experten gebaut. Einzelne Systemteile mussten mit hohem Aufwand funktionsfähig gehalten werden, da viele Fehler seit Jahren immer weiter kultiviert wurden und sich vielfach erst nach Jahren bemerkbar machten. Learning by doing – und nichts anderes ist ein iteratives Vorgehen im Grunde – ist in einer komplexen Welt zwar genau der richtige Weg, den ein Team beschreiten sollte, dennoch ist es wichtig, dass man ein Team hat, das bereits über ausgeprägte Erfahrung in diesen komplexen Systemwelten verfügt, um ein wissentliches Vorgehen zu wählen und nicht generell im Nebel zu stochern.

Lesen Sie auch: Scrum richtig anpassen: Vor- und Nachteile von Agile Hybrid-Frameworks

Erschwerend kam hinzu, dass die vorhandenen Systeme am Ende ihres Lebenszyklus angekommen waren und zwingend durch neue Systeme und Architekturen ersetzt werden mussten. Hierbei stellte sich die Frage, ob es sinnvoll wäre, einzelne Komponenten in die neue Architektur einzubauen, und wenn ja, wie diese Komponenten in vertretbarem Aufwand zu identifizieren wären. Das Risiko, Systeme wiederzuverwenden, die sehr fehleranfällig waren, lag klar auf der Hand. Das führte schließlich dazu, dass als Ergebnis eine Systemarchitektur und eine sich daran anlehnende Organisationsarchitektur (Prozess und Aufbau) empfohlen wurden, die, einem Greenfield Approach folgend, sowohl die vorhandenen Systeme als auch die bisher etablierte Organisationsform komplett neu aufstellten – ein revolutionärer statt evolutionärer Ansatz.

Herausforderungen

Daraus ergaben sich viele Herausforderungen. Skillsets im Team und generell in der gesamten Organisation fehlten, politische Verhaltensweisen behinderten eine klare Neuausrichtung, und Altsysteme hatten bereits ihr End of Life erreicht. Ängste der Mitarbeiter vor Veränderungen und dem Verlassen der Komfortzone blockierten ein Umdenken im Team. Alte Seilschaften, Verhinderer und Bewahrer blockierten Neuerungen und Veränderung generell. Außerdem mussten unbekannte Technologien und Prozesse den Mitarbeitern nahe gebracht werden. Manche Komponenten waren in alte Strukturen einzubinden, trotzdem war eine Entkopplung von Legacy-Systemen zwingend notwendig, und fehlende Strategien verhinderten eine strukturierte und nachhaltige Ausrichtung der einzusetzenden Ressourcen.

In der bestehenden Struktur waren Releases nur zweimal pro Jahr möglich. Das hatte mehrere Ursachen. Zum einen bedingte die monolithische Softwarearchitektur, verbunden mit einem anachronistischen Testansatz, einen hohen manuellen Testaufwand. Auch kleinste Änderungen an einzelnen Softwaremodulen sorgten für große Aufwände. Zum anderen fand eine klassische Wasserfallplanung beziehungsweise eine V-Modell-Herangehensweise Anwendung, die eine umfängliche Betrachtung des zu entwickelnden Stücks Software verlangte. Es wurden Requirements aufgenommen, entsprechend bewertet und eingeplant. Die Einplanung musste sechs Monate vor dem Ausrollen abgeschlossen, implementiert und im Gesamtsystem komplett getestet sein, damit ein Aufspielen auf das Livesystem überhaupt möglich war. Obwohl die Software auf den Testsystemen dediziert und intensiv getestet wurde, musste auf den Livesystemen erneut intensiv manuell getestet werden.

Auf zu neuen Ufern

Gerade manuelle Tests bedeuteten erheblichen Overhead, der mit hoher Priorität in der ersten Transformationsphase angegangen werden musste. Uns wurde die Möglichkeit eingeräumt, das bestehende Development-Team inklusive der verantwortlichen Product Owner zu übernehmen und mit einem Ops- und Content-Team zu integrieren. Product Owner dienten bis dato eher als Aufbereiter der erhobenen Requirements der Fachbereiche denn als vollwertige Scrum Product Owner – ein Umstand, der sich als weitere Herausforderung darstellte. Die Transformation einer klassischen in eine agile Organisation sollte ebenfalls agil und iterativ umgesetzt werden, um die Vorteile eines selbstorganisierenden Teams besser nutzen zu können.

Dieser Vorgehensansatz hat den Vorteil, dass kleinere Veränderungen besser und schneller umgesetzt, aber vor allem überwacht und bewertet werden können, als bei einem so genannten Big Bang. Ebenso mussten alle Beteiligten Stück für Stück an das Thema herangeführt und befähigt werden, die neuen Themen anders zu bearbeiten und umzusetzen als sie es bisher gewohnt waren. Dafür führten wir mit allen Beteiligten Gespräche, um die Ist-Situation besser zu verstehen, aufzunehmen, Verbesserungsvorschläge zu erarbeiten und Visionen abzuleiten.

Lesen Sie auch: „Ein Scrum-Master braucht die Autorität, um den Prozess im Team durchzusetzen“ – Interview mit Jörg Preußig

In diesem Zusammenhang haben wir uns mit der Umsetzung bereits vorhandener interner Verbesserungsvorschläge als einen guten Weg entschieden, Veränderungen schnell ins Team zu transportieren. Diese Vorschläge hatten sich von innen heraus entwickelt, das Team hatte also die Notwendigkeit von Änderungen bereits erkannt, doch eine Umsetzung im alten Prozess war anscheinend vorher nicht möglich.

Einer dieser Vorschläge war die testgetriebene Entwicklung (TDD), die als notwendig erachtet wurde, um Software schneller und hochwertiger ausliefern zu können. Das Team hatte den explizierten Wunsch, diese Technik im agilen Kontext verwenden zu dürfen. Das Ziel, das wir damit zusammen mit dem Team anstrebten, war eine vollautomatisierte Continuous Delivery Chain, in der ein hoher Grad an automatisierten Tests jedweder Ausprägung herrscht. Das Team bestand zunächst aus sechs Entwicklern. Eine gute Größe, um mit Scrum zu starten. Ein Teammitglied hatte bereits Erfahrung als Scrum Master sammeln können und bot sich an, diese Rolle mit unserer Unterstützung auch weiterhin auszufüllen. Dazu etablierten wir binnen einer Woche die nötigen Scrum-Meetings und schulten alle Entwickler entsprechend.

Rückschritt in alte Gewohnheiten vermeiden

Vor dem ersten Scrum Backlog Refinement (Grooming) gab es große Verunsicherung im Product-Owner-Kreis, da die Product Owner sich noch nicht in ihre Rolle eingefunden hatten, teilweise über ein zu heterogenes Skillset verfügten und sich deswegen nicht oder nur bedingt gegenseitig unterstützen konnten. Sie sprachen einfach nicht die gleiche Sprache. Wir begannen auch hier, in kleinen Schritten vorzugehen und schulten den Scrum-Prozess und das Erarbeiten von User Stories aus klassischen Requirements heraus. So starteten wir zusammen mit den Entwicklern in unseren ersten Sprint.

Im Grooming und darauffolgendem Planning wurde schnell klar, dass die Product Owner noch sehr in der alten Interpretation ihrer Rolle verhaftet waren. Die bestehenden Requirements wurden nahezu eins zu eins in User Stories überführt. Das brachte zwei Herausforderungen mit sich: Zum einen war der Detailgrad zu hoch und erinnerte an alte bestehende Feinkonzepte, was dazu führte, dass den Entwickler jedweder Spielraum genommen wurde. Im Rahmen der Retrospektiven wurde offensichtlich, dass die Developer sich in ihre alte Rolle eingefügt und somit die Produktverantwortlichkeit abgegeben hatten, was natürlich nicht unser Ansinnen war. Wir mussten gegensteuern und den Prozess überarbeiten. Klassischerweise liegt die Verantwortung für das Gesamtprodukt in Scrum beim Product Owner. Er entscheidet in Bezug auf das Was, aber nicht in Bezug auf das Wie. Diese Verantwortung liegt im Entwicklerteam, das crossfunktional aus UI/UXlern, Fullstack-Entwicklern und Architekten besteht. Ein weiterer Vorteil der Ausrichtung des Prozesses auf diese Sichtweise kam sofort zum Tragen: Die Überlastung der Product Owner nahm ab, da sie keine Feinkonzepte mehr schrieben.

Die zweite Herausforderung war im Scope zu finden. Die Feinkonzepte waren hinsichtlich Planung und der nächsten Sprints sehr weitreichend formuliert. Die Prioritäten waren zu großen Teilen Must-haves. Hier setzten wir entsprechend an und implementierten die Idee vom Minimum Viable Product (MVP). Ein Ansatz aus der Lean-Start-up-Welt, der beschreibt, was ein Produkt in seiner geringsten Ausprägung können muss. Er beantwortet die Frage, ob ein bestimmtes Feature vom User angenommen und gebraucht wird oder ob es in anderer Form umgesetzt werden sollte. Mit dem MVP wird der Fail-Fast-Ansatz verfolgt. Möglichst schnell und mit einem minimalen Aufwand herauszufinden, ob eine Idee tragfähig ist oder nicht. Mit der Vermittlung dieser Idee gaben wir sowohl dem Product Owner als auch den Entwicklern ein Werkzeug an die Hand, sich auf die wesentlichen Kernfunktionen zu fokussieren. In der ersten Softwareversion sollte herausgearbeitet werden, ob ein Verkaufs- und Angebotsprozess umsetzbar ist, sowohl technisch als auch personell. Hierfür wurden alle Features gestrichen, die nicht direkt diesem Prozess dienten, z. B. eine Facettensuche, eine Registrierung und ein Mein-Konto-Bereich. Die erste Reaktion auf diese Streichungen war Widerstand, da noch mehrere Sichten vermischt wurden: Sprint-Inkrement, MVP und Release gegenüber dem Kunden. Durch eine schärfere Abgrenzung ließ sich der Widerstand auflösen und eine weitere Steigerung der Product-Owner-Effektivität erreichen. Nach den ersten Sprints – ein Sprint ist auf zwei Wochen begrenzt – konnten wir so mittels mehrerer MVPs alle Fragen beantworten und wichtige Anpassungen vornehmen, die uns sonst später mit großer Wahrscheinlichkeit auf die Füße gefallen wären. Den ersten Schritt der Transformation konnten wir so erfolgreich mit einem Scrum-Team abschließen.

Auf die Frage, ob diese Strukturen das Unternehmen nachhaltig erfolgreich machen werden, kann jetzt jedoch noch keine Aussage getroffen werden.

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.