how to develop your own website

 

 

Scaled Scrum & DevOps: Entwicklung und Betrieb von 80 Websites mit Nexus Scrum

Ein größeres Projekt war in die Krise geraten. Mithilfe von fünf Scrum-Teams und dem Scaled Scrum Framework Nexus haben wir die Krise abgewendet, das Projekt erfolgreich abgeschlossen und ein DevOps-Team gestaltet.

Kontext
Ein internationales Multi-Marken-Unternehmen hatte geplant, seine Online-Präsenz zu überarbeiten. Dazu sollten mehr als 80 Websites konsolidiert, neu gestaltet und auf Basis eines neuen, zentralen Content-Management-Systems realisiert werden. Das Unternehmen beauftragte die beiden internen Online-Marketing-Teams, die eigene IT-Abteilung sowie eine Digitalagentur mit dem Projekt. Zur Realisierung waren zwei Jahre Zeit vorgesehen, sodass das Projekt rechtzeitig zur nächsten Branchenmesse abgeschlossen sein würde. Die interne IT-Abteilung übernahm hierbei die Gesamtprojektleitung.
Krisensituation
Nach etwa einem Jahr stellte sich heraus, dass das Projekt nicht den geplanten Fortschritt erzielt hatte und drohte, den zeitlichen Rahmen sowie das Budget zu überschreiten. Die beiden Online-Marketing-Teams hatten den Auftrag, die ihnen zugeordneten Marken durch markengerechte Websites, Inhalte und Services zu präsentieren. Dabei sollten sie auch eine klare Differenzierung zu den Marken des jeweils anderen Teams entwickeln. Auch aufgrund dieses Auftrags arbeiteten die Online-Teams nicht miteinander, sondern in Konkurrenz zueinander. Die Agentur selbst teilte sich infolgedessen in zwei Teams auf, die jeweils einem der Online-Teams zugeordnet wurden. Jede dieser so entstandenen „Parteien“ erarbeitete daraufhin eigene Anforderungen und Spezifikationen für jeweils zu realisierende Websites, die in weiten Teilen redundant und widersprüchlich waren. Wo die jeweiligen Teams die Konflikte in der Zusammenarbeit nicht lösen konnten, verlagerten sich die Arbeiten auf die Diskussion und Dokumentation von Prozessen, wie die Zusammenarbeit und Realisierung des Projekts eigentlich ablaufen sollte. Durch den Zeit- und Erfolgsdruck, der zu diesem Zeitpunkt bereits auf allen Beteiligten lastete, beschuldigte man sich gegenseitig, für die aktuelle Situation verantwortlich zu sein. Bisherige Eskalationen blieben im Ergebnis erfolglos. In dieser Gemengelage wurde ein Großteil des Projektbudgets verbraucht, ohne dass inhaltliche Fortschritte erzielt wurden. Als nun die Agentur bekanntgab, dass das Budget verdoppelt werden müsse, um das Projekt abschließen zu können, eskalierte die Gesamtprojektleitung die Situation an die höchste Unternehmensebene.

Zu diesem Zeitpunkt wurden wir gebeten, eine Lösung zu erarbeiten, mit der das Projekt erfolgreich abgeschlossen werden könne. Nachdem wir uns selbst ein Bild gemacht und uns mit allen Projektbeteiligten ausgetauscht hatten, fanden wir unsere Hypothese bestätigt, dass sich die Probleme nicht durch eine Überarbeitung des Projektplans und einer Anpassung des Projektbudgets lösen lassen würden. Vielmehr mussten die Konfliktursachen soweit möglich beseitigt und Rahmenbedingungen geschafft werden, unter denen die beteiligten Personen wieder zueinanderfinden und gemeinsam das Projekt realisieren konnten.
Lösungsansatz

Als erste Maßnahme nahmen wir die Unterstützung eines externen Mediators in Anspruch, der half, die Konflikte innerhalb und zwischen den Online-Marketing-Teams sowie der IT-Abteilung aufzuarbeiten. Im Rahmen dieser Mediation konnten wir auch die Beteiligten von der Idee überzeugen, das Projekt agil fortzusetzen. Außerdem bestärkten wir sie darin, die Realisierung stärker selbst in die Hand zu nehmen, statt hauptsächlich eine Agentur zu steuern.

Nachdem wir die Geschäftsleitung von unserem Ansatz überzeugt hatten, dass dafür keineswegs das Budget verdoppelt werden müsste, trennten wir uns von der Agentur und formten mit den internen Beteiligten ein erstes Scrum-Team. Dieses Team entwickelte dann innerhalb von drei Sprints ein Microsite-Produkt, mit dem regionale Marketing-Teams in den über 30 Ländern, in denen das Unternehmen tätig ist, eigene Online-Maßnahmen umsetzen konnten. Durch die Entwicklung dieses Microsite-Produkts konnte sich das Scrum-Team mit der Technologie vertraut machen, die Grundlagen für eine Micro-Services-Architektur legen, Selbstvertrauen und Vertrauen des Unternehmens zurückgewinnen. Parallel arbeiteten wir daran, das Team zu skalieren und weitere Scrum-Teams aufzubauen (scaled Scrum). Nachdem wir uns selbst und dem Unternehmen bewiesen hatten, dass wir auf diese Weise in der Lage sein würden, rasch Ergebnisse vorzuweisen, skalierten wir das Team innerhalb von drei Monaten schrittweise auf vier Scrum-Teams, um die kritischen Product Backlog Items rechtzeitig bis zum Messetermin entwickeln zu können.

Neben vielen typischen Herausforderungen hatten wir zwei größere Aufgaben zu lösen:

1. Konsolidierung und Priorisieurung von Feature Requests
Das Projekt sollte unter anderem den Bedürfnissen von ca. 30 regionalen Online-Managern gerecht werden, die aufgrund der Markenvielfalt sehr unterschiedliche Anforderungen hatten. Diese wollten wir soweit möglich konsolidieren und in einem einzigen Product Backlog abbilden. Um das zu bewerkstelligen, führten wir mit den Scrum-Teams und allen 30 Online-Managern in regelmäßigen Abständen eine eigene Variante von Prioritization-Poker durch.
2. Koordination der Scrum-Teams und Entwicklung gemeinsamer Product Increments
Die vier Scrum-Teams mussten spätestens am Ende jedes Sprints ein gemeinsames Product Increment erstellen. Hierfür galt es, sich sehr eng abzustimmen. Alle Scrum-Teams arbeiteten dazu in einem gemeinsamen „Heart Beat“: Dazu wurde vor dem Product Backlog Refinement der einzelnen Scrum-Teams untereinander abgestimmt, welches Team welche Product Backlog Items vorbereitet. Die Ergebnisse der Product Backlog Refinements wurden gegenseitig vorgestellt, um Abhängigkeiten oder Unstimmigkeiten zu berücksichtigen. Vor dem Sprint Planning wurden gemeinsam Product Backlog Items für die Scrum-Teams ausgesucht. Die Scrum-Teams führten dann ihr Sprint Planning parallel durch, trafen sich währenddessen stündlich, stellten sich gegenseitig die Sprint Backlogs vor und visualisierten Abhängigkeiten zwischen den gewählten Sprint Backlog Items an einem dafür eingerichteten übergeordneten Scrum Board. Letzteres wurde von einem fünften Scrum-Team verantwortet, dessen Aufgaben darin bestanden, die vier Scrum-Teams zu coachen und bei der Integration der einzelnen Product Increments in ein einziges „done“ Product Increment zu unterstützen. Wie üblich visualisierte jedes der vier Scrum-Teams das eigene Sprint Backlog auf einem eigenen Scrum Board.

Alle vier Scrum-Teams entwickelten und integrierten ihre Sprint Backlog Items in einer gemeinsamen Umgebung.

Auf täglicher Basis trafen sich Vertreter der vier Scrum-Teams gemeinsam mit Vertretern des fünften Scrum-Teams, um Fortschritt, Abhängigkeiten, Unterstützung und Impediments zu besprechen. Zudem führte jedes der vier Scrum-Teams ein eigenes Daily Scrum durch, um die Ergebnisse des gemeinsam Daily Scrums in den Teams zu kommunizieren und abzustimmen.

Alle Scrum-Teams führten ein gemeinsames Sprint Review durch und diskutierten das Product Increment mit den teilnehmenden Online-Managern. Auf dieser Basis aktualisierten sie das Product Backlog und passten die Product Roadmap an.

Vor den Sprint Retrospectives der einzelnen Scrum-Teams wurden gemeinsame Herausforderungen identifiziert, die dann in den Sprint Retrospectives aufgegriffen wurden. Im Anschluss daran kamen die Scrum Master zusammen und besprachen die Lösungsvorschläge der Scrum-Teams für die gemeinsamen Herausforderungen.
Erfolgreicher Abschluss & DevOps-Modell
Auf diese Weise gelang es dem Projektteam innerhalb von etwa einem Jahr, das Produkt erfolgreich und rechtzeitig zur Branchenmesse zu liefern. Aufgrund der sichtbaren Erfolge kam zudem die PR-Abteilung des Unternehmens auf uns zu und bat uns, auch die umfangreiche Corporate Website umzusetzen. Aufgrund des Forecasts wusste das Team, dass dies innerhalb von Zeit und Budget möglich war und kam der Bitte entgegen. Das Unternehmen konnte so auf der Branchenmesse mit neuen, nun aktuellen und konsistenten Websites sowie neuen Online-Services punkten. Das eingesetzte Budget blieb unterhalb unserer eigenen initialen Prognose und innerhalb des ursprünglich geplanten Rahmens.

Dieses Projekt führten wir von 2013 bis Anfang 2015 durch. Das damals entstandene Team existiert im Kern noch heute und entwickelt und betreibt im DevOps-Modell einen Großteil des mittlerweile beachtlichen digitalen Ökosystems im Unternehmen. Die Art und Weise, wie wir damals Scrum einsetzten und skalierten, wurde später von Ken Schwaber und scrum.org als Nexus formalisiert. In dem gleichnamigen Guide konnte sich das Team – durchaus ein wenig stolz – „wiederfinden“. Wir können bestätigen, dass Nexus ein möglicher Weg ist, um komplexe Projekte mit mehr als zwei Scrum-Teams erfolgreich abzuschließen. Ganz ohne schwergewichtige agile Frameworks, sondern mit einem Team aus motivierten und engagierten Menschen, die gemeinsam etwas vollbringen, das viele für unmöglich erklärt hatten – wenn die richtigen Rahmenbedingungen geschaffen werden. Mit Scrum und Nexus haben wir diese Rahmenbedingungen geschaffen und gegen viele Widerstände gehalten. Wir danken diesem Team für eine spannende gemeinsame Zeit und für eines der lehrreichsten Projekte, an denen wir teilhaben konnten. Ihr seid unser A-Team!

Teilen Sie diese Seite

Interesse an Scrum und DevOps?

Sie möchten Ihre Software schneller, erfolgreicher, zuverlässiger und sicherer entwickeln, releasen und betreiben? Wir helfen Ihnen dabei und freuen uns auf Ihre Kontaktaufnahme!

über Nexus
Nexus ist ein Framework zur skalierten Entwicklung von Produkten mit Scrum. Nexus verwendet Scrum als Grundbaustein und besteht aus den Nexus-Rollen, Events und Artefakten sowie den Regeln, die alles miteinander verbinden. Mithilfe des Nexus-Frameworks können drei bis neun Scrum-Teams (scaled Scrum) gemeinsam ein Product Backlog umsetzen und integrierte Product Increments entwickeln. Ken Schwaber und Scrum.org haben Nexus 2015 entwickelt. Der Nexus-Guide wird von ihnen verfasst und veröffentlicht.
über Scrum
über JOHANNES GESKE - Guide to Business Agility

Johannes Geske ist Agile Coach für Führungskräfte und Teams. Mit agilen Prinzipien und Praktiken befasst er sich seit 2003. Aus Erfahrung weiß Johannes Geske, dass Unternehmen Agilität nicht allein durch viele agile Teams erreichen, sondern durch agile Interaktionen zwischen den an der unternehmerischen Wertschöpfung beteiligten Teams. Daher hilft Johannes Geske Unternehmen, den gesamten Wertstrom „from concept to cash“ agil zu gestalten und so Business Agility zu erreichen.

Johannes Geske ist Agile Coach, Enterprise Kanban Coach (EKC), Kanban Management Professional (KMP), Scrum Trainer, Scrum Master (SPS, PSM, PSPO, PSD) und Design Sprint Moderator und vermittelt agile Arbeitsweisen wie Design Sprints, Scrum und Kanban mit großer Leidenschaft.


Interesse an Scrum und DevOps?

Sie möchten Ihre Software schneller, erfolgreicher, zuverlässiger und sicherer entwickeln, releasen und betreiben? Wir helfen Ihnen dabei und freuen uns auf Ihre Kontaktaufnahme!