Ihr Standort: movisco // Blog »
kontakt mail icon
kontakt phone icon

SCRUM – Was wir vom Rugby lernen können

„Scrum (aus englisch scrum für "Gedränge") ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung.“

So nüchtern liest sich die Definition von Scrum in der Wikipedia Enzyklopädie. Doch was ist nun dieses „Scrum“ und wie hilft es uns im täglichen Projekteinsatz mit seinen unterschiedlichsten Facetten? Dies möchte ich aus meinen Bankenprojekten heraus einmal beleuchten.

Benannt nach dem aus dem Rugbysport bekannten Gedränge scheint also auch Scrum eine auf den ersten Blick chaotisch wirkende Vorgehensweise zu sein, die dennoch irgendwie zum Ziel führt. Schauen wir uns das einmal an.

Agiles Manifest

Damit ein agiles Projekt erfolgreich ablaufen kann, sind dabei unbedingt Regeln einzuhalten. Sie bilden das Rahmenwerk, innerhalb dessen das agile Team agiert.

Seit seinen ersten Anfängen in 1993 versuchten die Scrum-Väter Jeff Sutherland und Ken Schwaber ein Regelwerk zu erstellen, das die neue Rolle des Projektleiters als Teammitglied und Moderators beschreibt sowie ferner das Produkt nicht als Ergebnis der Überlegungen eines Managers zu verstehen, sondern vielmehr als das Ergebnis eines teamweiten Entwicklungsprozesses. Schwaber sagte dazu bereits 1995 auf der OOPSLA: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“

Dies manifestierte sich dann auch im ursprünglichen Rugby-Begriff „Scrum“, der als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams steht. Ohne Managerführung arbeiten diese Teams als kleine, selbst-organisierte Einheiten, denen nur die Richtung vorgegeben wird, in die das Produkt sich entwickeln soll, nicht aber der Weg zur gemeinsamen Zielerreichung. Dies alles führt zu einem hochmotivierten, qualifizierten und interdisziplinär besetzten Entwicklungsteam, das mit dem nötigen Freiraum ein hochwertiges Produkt entwickeln kann. Ganz im Gegensatz zu den bis dato üblichen Befehls- und Kontrollorganisationen, in welchen die Mitarbeiter über exakte Arbeitsanweisungen an der Verwirklichung eigener Ideen eher gehindert wurden.

Diese Grundsätze von Scrum wurden 2001 im agilen Manifest von u.a. Ken Schwaber und Jeff Sutherland zusammengefasst:

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Software ist wichtiger als umfassende Dokumentation.
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
  • Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Rollen

Das Scrum Team besteht grundsätzlich aus drei verantwortlichen Rollen: Product Owner, Scrum Master und Entwickler. Für größere Entwicklungsteams wurden basierend auf Scrum spezielle Frameworks geschaffen, die weitere Rollen definieren, um auch große agile Organisationen abzubilden. Eines dieser Frameworks ist das Scaled Agile Framework „SAFe“, welches hier im movisco Blog ebenfalls noch beleuchtet werden wird.

Die Person des Product Owners gestaltet hauptsächlich das nutzenoptimierte Produkt und ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Dafür steht dem Product Owner mit dem Product Backlog ein Tool zur Verfügung, mit dem er die Eigenschaften des Produkts verwalten und detaillieren kann. Eine der wichtigsten Aufgaben in bislang managementorientierten Unternehmen ist zudem die Kommunikation mit den Stakeholdern. Oft erhalten Product Owner schlicht nicht die erforderliche Kompetenz, die zur eigengesteuerten Entscheidungsfindung notwendig wäre, auch wenn dies nach Scrum vorgesehen ist.

Eine solche Abweichung vom Scrum-Regelwerk nennt man häufig „Scrum-but“ und bedeutet: „ja, wir arbeiten nach Scrum, aber…“. Bekannt als ein sicherer Weg, ein nach Scrum geführtes Projekt vom erfolgreichen Pfad abzubringen. Dazu später mehr.

Robert Meinl

Der Scrum Master sorgt für das agile Umfeld. Er arbeitet eng mit dem Entwicklungsteam zusammen, ohne selbst dazu zu gehören. Für ein reibungsloses Arbeiten ist es wichtig, dass der Scrum Master Störungen, die sog. Impediments, beseitigt. Außerdem organisiert er die Scrum Events und stellt deren Einhaltung sicher. Der Scrum Master dient dabei dem Team. Er ist kein Vorgesetzter oder Product Owner, sondern hilft dem Team bei der Zielerreichung. Dabei ist Fingerspitzengefühl hilfreich; jedes Team benötigt eine andere Unterstützung und „situative Führung“. Ist das Vorgehen erst einmal gefestigt, sinkt der Bedarf am Scrum Master und er kann sich neben seiner Zeit für das Team um weitere Aufgaben kümmern, wie z.B. Scrum im Unternehmen bekannter zu machen.

Die Gruppe der Entwickler setzt nun die im Product Backlog definierten und im Sprintplanning festgelegten Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge um. Sie tragen ferner die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards, den sogenannten „Definitions of Done“. Damit ist das Scrum-Team eigentlich schon fertig. Die Entwickler sollten so interdisziplinär aufgestellt sein, dass sie das Ziel eines Sprints ohne größere äußere Abhängigkeiten erreichen können, wobei eine Teamstärke von 10 Mitgliedern nicht überschritten werden sollte.

Die Vorteile des Interdisziplinären Teams liegen auf der Hand: nur ein solches Team kann die sich ständig ändernden Anforderungen des Projektalltags besser bewältigen. Ein interdisziplinäres Team mit vielfältigen Fähigkeiten ist besser in der Lage, das gemeinsame Ziel zu erreichen.

Stakeholder außerhalb des eigentlich Scrumteams

Der Kunde ist der wichtigste Stakeholder für das Team. Er wird das Produkt nach Fertigstellung erhalten und nutzen. Es ist damit das oberste Ziel, ein für den Kunden ideales Produkt zu generieren. Der Product Owner hat dabei die Aufgabe, das Produkt perfekt zu definieren und dem Team die Vision des perfekten Produkts zu vermitteln. Nur so werden sich die Kunden später auch dafür begeistern. Innerhalb eines Unternehmens wie einer Bank ist der Kunde die interne Fachabteilung bzw. die internen Fachabteilungen, es können aber genauso auch externe Personengruppen sein.

Das Management ist für das perfekte Projektumfeld verantwortlich und stellt Infrastruktur und Budget zur Verfügung. Zudem sorgt es zu Beginn für die ideale Besetzung des Scrumteams. Sarüber hinaus soll es das Projekt vor externen Einflüssen wie anderen Arbeitsaufträgen bewahren.

Sprints

Eine Zeiteinheit im agilen Vorgehen wird „Sprint“ genannt. Er dauert idealerweise zwischen 1 und 4 Wochen und ist fest einzuhalten. Ein Sprint stellt eine abgeschlossene Entwicklungseinheit dar, beginnend mit der Sprint Planung (inkl. Aufwandsschätzung der vom Product Owner ausgewählten Product Backlogeinträge) mit dem Ergebnis des Sprint Backlogs mit seinen Tasks. Während des Sprints erzeugt das Team ein sogenanntes „Shipable Increment“, also eine Version des Products, das nach dem Sprint veröffentlicht werden könnte. Ob eine Veröffentlichung durchgeführt wird, hängt wiederum vom Product Owner ab. Dies ist sicher nicht nach jedem Sprint sinnvoll, möglich muss es aber sein. Das sprintweise Vorgehen dient dem inkrementellen Weiterentwickeln des Produktes und der Möglichkeit, dieses jederzeit den Stakeholdern sowie den Kunden zum Test oder der Nutzung bereitzustellen. Frühes Anwenderfeedback ist dabei eine positive Folge für ein sehr gutes späteres Produkt.

Wichtige Erkenntnisse

  • Auf die Backlogpflege kommt es an: im Backlog sollten nur konkrete Einträge vorgenommen werden und auf vage Ideen und Vorschläge verzichtet werden. Ferner ist vom Product Owner eine Priorisierung und Reihenfolge sowie eine Bewertung vorzunehmen.
  • Im Scrum-Poker schätzt das Team den relativen Aufwand einer Anforderung ein.
  • Nutzen Sie die Retrospektive, um den vergangenen Sprint rückwirkend zu betrachten und für die nächsten Verbesserungen im Prozess umzusetzen.
  • Ein guter Daily bietet den Mehrwert einer guten teaminternen Kommunikation.
  • Gehört Empowerment zur Firmenkultur, kann sich jeder mit seinen Ideen einbringen. Durch die Wertschätzung entwickelt sich eine Motivation und Dynamik, die das ganze Unternehmen voranbringt. Viele Banken haben dies verstanden und arbeiten daran.
  • Scrum sollte vom Management unterstützt, aber besser nicht beschlossen werden. In ungeeigneten Projekten kann eine agile Vorgehensweise auch hinderlich sein, statt zu unterstützen. Aber wird es in geeigneten Projekten eingesetzt, so hat sich auch das Management in die entsprechende Stakeholder Rolle einzufügen.
  • Continuous Integration und sprintweises Testen mit abgeschlossenen Iteration verhindert den Big Bang der Wasserfallprojekte und der Verwunderung des hohen Testaufwands am Schluss. Regelmäßige „shippable increments“ helfen, auch während des Projektes den Überblick über den Projektfortschritt zu behalten.
  • Der Burn-Down-Chart zeigt den Fortschritt ggü. dem Plan und vor allem die Steigerung der Velocity, also dem Geschwindigkeitszuwachs eines zusammenwachsenden Teams, an.

Die reale Welt – oder „Scrum, but“

Wie aber sieht nun ein agiles Projekt in der Realität aus? Von den vielen regelmäßigen Pflichtterminen genervte Teams, durchgreifendes Management, Festlegung von Scope und Zeitplan, all dies sind agilitätshemmende Einflüsse, mit denen die agil aufgesetzten Projekte tagtäglich zu kämpfen haben. „Wir haben Scrum mal teilweise gestartet“ hört man dabei oft. Wie geht man damit also nun um?

Kurz gesagt: das ist leider oft der Alltag, also lassen Sie uns den besten Kompromiss finden. „Scrum, but“ muss nicht immer schlecht sein, hat aber mindestens genauso oft einfach nicht funktioniert. Es verbindet die alten Strukturen und unternehmens- und bankinternen Prozesse mit der neuen Welt. Dabei ist es wichtig, unternehmensweite Prinzipien einzuführen, die den agilen Teams auch wirklich ihren Freiraum bieten und dies mit Managementunterstützung. Oft ist dies aber nur in Think Tank-ähnlichen Researchabteilungen möglich, wo an „wirklich neuen“ Produkten gearbeitet wird, nehmen wir zum Beispiel das iPhone. Sind die Projektinhalte aber vielmehr Tagesgeschäft, gibt es schlicht keinen Raum für große Innovation, beispielsweise der Datenanbindung, die von der Muttergesellschaft zu Reportingzwecken gefordert wird.

Die Kunst besteht darin, dennoch einen großen Vorteil aus dem agilen Vorgehen zu gewinnen.

Fazit: Lohnt sich das Rugby-artige „Gedränge“ auch in Standardprojekten?

Unsere Erfahrungen haben gezeigt, dass es sich lohnt, sich mit althergebrachten Strukturen zu arrangieren und auf Ebene der Product Owner sowie Scrum Master abzufangen, damit den Teams ein Arbeitsumfeld geboten wird, das motiviert und zu Höchstleistungen verleitet. Das Risiko liegt dabei aber klar bei den eben erwähnten Personen, die in Richtung Management ein Commitment abgeben, ihren Teams aber Scrum-typische Freiheiten lassen.

Ob und wie das gut geht, erläutern wir gerne anhand Beispielberichten aus unseren zahlreichen agilen Projekten in der Bank- und Finanzdienstleistungsbranche und erarbeiten mit Ihnen ein passendes Modell für Ihr Projekt.

Sprechen Sie uns hierzu gerne an: Robert Meinl: robert.meinl@movisco.com, Michael Junklewitz: michael.junklewitz@movisco.com

Tipp:

Und wenn Sie an skalierten agilen Ansätzen interessiert sind, lesen Sie in Kürze unseren Artikel „SAFe – das scaled agile framework“, welcher ebenfalls hier im movisco-Blog erscheinen wird.


Weitere Beiträge

  • Scrum hautnah - was steht auf Ihrer Bucketlist? weiterlesen

Kommentare

Schreiben Sie den ersten Kommentar!

Kommentar schreiben

* Diese Felder sind erforderlich

Mit der Abgabe eines Kommentars stimme ich der Nutzung meiner Daten zur Kontaktaufnahme zu!

Nach oben

Ihre Ansprechpartnerin

Susanne Jung

info@movisco.com
elektronische Visitenkarte

Fon +49 40 767 53 777

Schnellkontakt-Formular

Schnellkontakt-Formular
zweite Formularseite