Die SCRUM Methode

Das “angeordnete Gedränge” im Rugby – oder eine agile Produktentwicklungsmethode aus der Softwareentwicklung?

Auch wenn sich Scrum manchmal so anfühlt, geht es nicht darum sich aufeinanderzudrängen um sich bestmöglich für den Balleinwurf zu positionieren, sondern um eine Methode zur interativen Umsetzung von Ideen. Entstanden in der agilen Softwareentwicklung, wird Scrum vielfach in Unternehmen als agiler Prozess für Projektmanagement und zur Produktentwicklung eingesetzt.

Scrum folgt Design-Thinking und Lean Startup

Ideen und Konzepte, die in vorherigen Projektphasen mit agilen Methoden wie Lean Startup oder Design Thinking ausgearbeitet und anhand von Prototypen getestet wurden, werden mit der Scrum Methode in Interaktionen zu einem marktreifen Produkt weiterentwickelt und umgesetzt. Scrum ist somit im Gegensatz zu anderen agilen Innovations- und Produktentwicklungsmethoden eine reine Umsetzungsmethode.

Wobei Scrum keine dogmatische Methode, sondern ein Framework ist, welches dem Team und den beteiligten Stakeholdern Leitplanken und Orientierungspunkte für ihre Kollaboration und Kommunikation bietet. Die Scrum Methode wird durch www.scrum.org permanent weiterentwickelt und ist im aktuellen Scrum Guide dokumentiert. Auf Scrum.org können auch Zertifizierungen erworben werden.

💡Scrum Vorteile

Die Stärke der Scrum-Methode liegt in ihrer strikten Prozess- und Rollenstruktur, sowie der Möglichkeit, kurzfristige Änderungen vorzunehmen. Die Komplexität und ressourcenbezogene Risiken neuer Produktentwicklungsvorhaben lassen sich mit der Scrum-Methode deutlich reduzieren. Es gibt klar definierte Rollen, Artefakte und Events, die folgend unter Scrum Struktur erläutert werden. In der Praxis erlebe ich häufig, dass Scrum bereits vorhandene Probleme sichtbar macht. Dies sollte als Möglichkeit zur Verbesserung betrachtet werden und nicht als ein Zeichen, daß Scrum nicht funktioniert. Die Einführung von Scrum ist eben auch ein Organisationsentwicklungsprojekt und sollte entsprechend professionell begleitet werden, um den vollen unternehmerischen Mehrwert zu entfalten anstatt Frustration zu erzeugen.

💡5 Scrum Prinzipien

Die Scrum-Methode basiert auf fünf Leitsätzen:

• Mit Respekt entsteht Vertrauen.

• Durch Mut können Missstände früh angesprochen und korrigiert werden.

• Mit Selbstverpflichtung entsteht Verbindlichkeit und Leistung.

• Offenheit erzeugt Transparenz und Sicherheit.

• Fokus auf das Richtige und Wichtige.

In 2001 wurden die obige Scrum Prinzipien und die aus der praktischen Anwendung gewonnenen Erkenntnisse ins agile Manifesto überführt.

💡Scrum Struktur

Die Gründer Jeff Sutherland und Ken Schwaber haben ihre Methode erstmals 1995 vorgestellt und seitdem wurde sie kontinuierlich weiterentwickelt sowie deren Anwendungsgebiete erweitert.

Die Teammitglieder des Scrum Teams arbeiten mit definierten Artefakten und Werkzeugen und treiben die Produktentwicklung zyklisch in sogenannten Scrum Events z.Bsp. Sprints voran.

💡Scrum Team:

In jedem Scrum Team gibt es drei klar verteilte Rollen und Aufgabenbereiche. Die Scrum Rollen sind eindeutig definiert und geben dem Projekt von Beginn an eine klare Struktur. Dank dieser strukturierten Aufgabenverteilung arbeiten Scrum Teams zielorientiert, ressourcenschonend und schnell miteinander. Vor Beginn des Projekts werden die Rollen zugeordnet und dadurch die Aufgaben- und Kompetenzbereiche zugeordnet sowie die Arbeitsweise festgelegt.

1 Entwicklungsteam

Das Entwicklungsteam besteht in der Regel aus vier bis sieben Personen, die individuell verschiedene Fähigkeiten haben. Sie entwickeln das Produkt oder den Service und verantworten dabei die Produktqualität. Entscheidendes Kriterium ist, daß sie selbstorganisiert arbeiten.

2 Scrum Master

Der Scrum Master ist sozusagen der methodische Coach des Scrum Teams. Diese Scrum Rolle kümmert sich darum, dass das Development Team fokussiert und effizient arbeiten kann. Insofern obliegt es dem Scrum Master unnötige externe Einflüsse und Hindernisse zu beseitigen.

3 Product Owner

Der Product Owner ist für den wirtschaftlichen Erfolg des Projektes verantwortlich und sorgt dafür, dass das Produkt oder der Service die wirtschaftlichen Anforderungen erfüllt. Es ist ebenfalls Aufgabe des Product Owners die Product Vision zu erarbeiten und ihm obliegt die Priorisierung und Pflege des Product Backlogs. Er ist ebenfalls zuständig für Klärung von Fragen als auch für die Produktentscheidungen.

💡Scrum Prozess – Sprint und Scrum Meetings

Im Scrum Prozess – auch Scrum Events genannt – treibt das Scrum Team in strukturierten Entwicklungsschritten die Weiterentwicklung eines Produktes oder Services voran.

Dazu werden sequentiell die folgenden Events abgehalten:

1 Sprint

Die Scrum Sprints haben ein klar definiertes Ziel und stets die gleiche Dauer von ca. zwei bis vier Wochen. Das Sprint Ziel und die Sprint Dauer dürfen während eines Scrum Sprints nicht verändert werden und sind vom Scrum Team gemeinsam zu Projektbeginn festzulegen. In der Interation werden die vom Product Owner priorisierten Items (Eigenschaften, Funktionen und Verbesserungen des Produkts) aus dem Product Backlog vom Development Team umgesetzt. Die explizite aus dem allgemeinem Product Backlog priorisierten Items werden im Sprint Backlog erfasst und im anstehenden Scrum Sprint umgesetzt. Der Sprint Backlog darf somit während des Scrum Sprints nicht geändert werden. Das Ergebnis eines jeden Scrum Sprints ist eine verbesserte Produktversion, das sogenannte Product Increment.

2 Sprint Planning Meeting

Vor jedem Scrum Sprint trifft sich das gesamte Scrum Team zum sogenannten Sprint Planning Meeting. In diesem wird zunächst festgelegt, welche Items aus dem Product Backlog im kommenden Sprint eingebaut oder verbessert werden sollen. Diese Items werden in den Sprint Backlog aufgenommen und dienen der Erstellung des Umsetzungsplans. Hier wird festgehalten welche Aufgaben während des kommenden Sprints zu erledigen sind. Hierfür schätzt das Entwicklungsteam den Aufwand einzelner Aufgaben. Denn dies ermöglicht dem Product Owner den erwarteten Nutzen und den Aufwand direkt gegenüberzustellen und bildet somit die Basis der Priorisierung. Als gängige Schätzmethode hat sich das Planning Poker etabliert.

Konkret heißt dass: das Scrum Team, unter Moderation des Scrum Masters, setzt die Ziele und den Umsetzungsplan für den nächsten Scrum Sprint fest. Der Product Owner steht dem Team dabei für Rückfragen zur Verfügung.

Dieses Sprint Planning Meeting besteht aus drei Teilen:

1) Priorisierung: Im ersten Teil präsentiert der Product Owner die Priorisierung der Einträge im Product Backlog und stellt das übergeordnete Ziel für den nächsten Scrum Sprint vor. Das Development Team klärt Verstsändnisfragen und bestimmt mit dem Product Owner die Art und den Umfang der Umsetzung.

2) Zielsetzung: Danach erfolgt die Auswahl der Items aus dem Product Backlog, die im anstehenden Scrum Sprint umgesetzt werden sollen. Wobei das Scrum Team die Umsetzungsentscheidung fällt und nicht der Product Owner. Die Items – dies können Produkteigenschaften, Funktionen oder Verbesserungen sein – werden anschließend in den Sprint Backlog aufgenommen.

3) Aufgabendefinition: Nun werden die ausgewählten Items in konkrete Aufgaben, die zur Umsetzung notwendig sind, heruntergebrochen. Dadurch bekommt das gesamte Scrum Team einen Überblick über die Aufgaben und individuellen Aufgabenbereiche.

Pro Sprintwoche sollten ca. zwei Stunden Meetingzeit eingeplant werden; sprich bei einem zwei Wochen Sprint entspricht dies vier Stunden. Hier kommt das Kanban Board aus dem agilen Werkzeugkoffer gerne zum Einsatz. Die Teamabschätzungen über die zu schaffenden Items wird nicht immer stimmen, aber von einem zum nächsten Sprint immer genauer.

3 Daily Scrum Meeting

Beim Daily Scrum Meeting koordiniert das Scrum Team täglich, in einem knappen und kompakten Format seine Arbeit. Jedes Mitglied teilt der Gruppe mit, an welcher Aufgabe es am Vortag gearbeitet hat und welche Aufgabe es heute angehen wird. Wichtig ist auch die Information, welche Hindernisse oder Schnittstellen es auf dem Weg zum Projektziel identifiziert hat. Dadurch schafft das Daily Scrum Meeting nicht nur Transparenz und Überblick sondern auch ein Gemeinschaftsgefühl im Team.

Dieses Meeting findet im Stehen statt und heißt deswegen oft auch Daily Stand Up oder Stand-up Meeting. Das Meeting findet am besten immer zur gleichen Uhrzeit und am gleichen Ort – meist vor dem Kanban Board – für maximal 15 Minuten statt. Das “Daily” wird vom Scrum Master moderiert. Eine regelmäßige Teilnahme des Product Owners ist empfehlenswert, damit auch der Produktverantwortliche den erreichten Fortschritt verfolgen kann und offene Fragen direkt mit ihm geklärt werden können. Hierbei ist es wichtig zu beachten, daß die Anwesenheit des Product Owners weder den Ablauf noch den Inhalt beeinflusst, denn das Daily Scrum Meeting ist kein Projektstatusmeeting.

💡Sprint Review Meeting

Am Ende eines jeden Sprints trifft sich das gesamte Scrum Team zum Sprint Review Meeting. Dieses Treffen dient dem Feedback und der Überprüfung, ob die Produktentwicklung in die gewünschte Zielrichtung verläuft. Hier werden auch die vergangenen Scrum Sprints und seine Ergebnisse dargestellt, analysiert und diskutiert. Der Fokus liegt darauf etwaige Anpassungsnotwendigkeiten zu identifizieren und für den nächsten Sprint zu initiieren. Deswegen sind sowohl das gesamte Scrum Team als auch weitere Stakeholder wie Auftraggeber, Sponsoren und interne Kunden am Sprint Review Meeting beteiligt.

Im Sprint Review Meeting werden folgende drei Aspekte beleuchtet:

1) Product Increment Demo

Die im vergangen Scrum Sprint implementierten Funktionen werden präsentiert, wobei nur vollständig umgesetzte Items gezeigt werden.

2) Feedback

Konstruktives Feedback vom Product Owner zu den entwickelten Items ist ein zentraler Bestandteil. Er entscheidet auch, ob diese akzeptiert, abgelehnt oder angepasst werden müssen. Erst im nächsten Schritt geben weiter Stakeholder ihr ergänzendes Feedback.

3) Bewertung und nächste Schritte

Am Ende der Feedback-Runde beurteilt der Product Owner, ob das Ziel des Scrum Sprints erreicht wurde. Mit den gesammelten Erkenntnissen kann er sowohl den nächsten Scrum Sprint als auch die nächste Produktveröffentlichung oder den Release planen.

Der Scrum Master moderiert hierbei das Sprint Review Meeting und achtet besonders auf eine offene und konstruktive Atmosphäre und die Einhaltung der Feedbackregeln.

Analog dem Sprint Planning Meeting werden ca. zwei Stunden Meetingzeit pro Sprintwoche angesetzt. Wichtig ist auch, daß die Präsentation des Product Increments durch das Development Team und keinesfalls durch den Scrum Master erfolgt. Nun ist auch ein guter Zeitpunkt gekommen, das Erreichte gemeinsam zu Feiern!

💡Sprint Retrospektive

Im Anschluss an das Sprint Review Meeting trifft sich das Scrum Team, um die vergangene Interation zu reflektieren. Hierbei überprüft das Scrum Team die Qualität und Effizient der gemeinsamen Arbeit und legt fest, welche Verbesserungsmaßnahmen getroffen werden müssen. Die kontinuierliche Weiterentwicklung des Prozesses, der Teamarbeit und jedes Einzelnen ist wesentlicher Bestandteil der Scrum Philosophie. Dies stärkt den Zusammenhalt im Team und verbessert auch die Geschwindigkeit der Produktentwicklung.

Die Sprint Retrospektive bietet dem Scrum Team einen geschützten Raum, in der der Scrum Master die Moderatorenrolle übernimmt und das Scrum Team vertrauensvoll durch die drei Schritte der Retrospektive führt.

1) Informationen sammeln

Welche Dinge haben während des letzten Scrum Sprints gut funktioniert? Welche haben schlecht funktioniert? Wie geht es uns als Scrum Team? Wie funktioniert die Zusammenarbeit?

2) Erkenntnisse ableiten

Was sind mögliche Gründe für die gute oder schlechte Zusammenarbeit? Welche tiefergehenden Ursachen und Muster liegen der Qualität der Kollaboration zugrunde?

3) Maßnahmen beschließen

Was wollen wir als Scrum Team konkret ändern? Welche Hindernisse können nur außerhalb des Scrum Teams beseitigt werden und wie kann der Scrum Master dabei helfen?

In der Sprint Retrospektive gilt die Regel pro Sprintwoche ca. eine Stunde Meetingzeit einzuplanen. Entscheidend ist, daß die gemeinsam vereinbarten Verbesserungsmaßnahmen konkret und aktiv umgesetzt werden. Dies hat einen deutlich positiven Effekt für die Entwicklungsarbeit des Scrum Teams. Es empfiehlt sich auch Kennzahlen festzulegen, um den Entwicklungsfortschritt messbar zu machen.

Scrum Artefakte und Werkzeuge:

Nachdem das Scrum Team vorgestellt und der Scrum Entwicklungsprozess beschrieben wurde, geht es nun um die in Scrum eingesetzten Werkzeuge.

💡Product Backlog

Im Product Backlog werden sämtliche zur Umsetzung freigegebenen Eigenschaften und Funktionen eines Produkts oder Services festgehalten. Das heißt sämtliche funktionalen oder nicht-funktionalen Kunden- oder Nutzeranforderungen werden aufgeführt. Jeder Eintrag wird hinsichtlich seiner wirtschaftlichen Bedeutung – Business Value – bewertet und priorisiert. Hierbei werden die Einträge mit hoher Priorität im nächsten Scrum Sprint umgesetzt, wohingegen solche mit einer niedrigen Priorisierung für später Interaktionen im Product Backlog verbleiben.

Die Aktualität des Product Backlogs ist wichtig und somit sind folgende Aufgaben zu erledigen:

1) Items werden kontinuierlich aufgenommen, beschrieben, angepasst oder entfernt.

2) Dem Product Owner obliegt die Priorisierung anhand des Business Value und verschiebt diese Items nach oben.

3) Jegliche Product Backlog Items werden mit Aufwandsschätzungen versehen. Hierbei schätzt das Development Team die relative Komplexität und aktualisiert diese sofern notwendig.

Die Pflege des Product Backlog erfolgt im Backlog Refinement Meeting, in welchem der Product Owner neue Items oder Anpassungen mit dem Scrum Team bespricht und offene Fragen klärt. Achten Sie darauf, den Product Backlog überschaubar zu halten. Niedrig priorisierte Items müssen zum Beispiel nicht ausführlich dokumentiert werden.

In der Praxis haben sich sogenannte User Stories als Darstellung- und Beschreibungsform der Items durchgesetzt. Die Dokumentation erfolgt sehr häufig ebenfalls in Form eines Kanban-Boards.

💡Definition of Done

Die Definition of Done (DoD) ist eine für den Sprint spezifische Vereinbarung und das gemeinsame Verständnis des Teams, wann eine Aufgabe als erledigt gilt. Es gilt zu klären, was alles getan werden muss, damit das Ziel des Scrum Sprints erreicht wird. Hierfür werden allgemeingültige Akzeptanzkriterien sowie allgemeine Anforderungen und Qualitätskriterien festgelegt und beschrieben.  Entsprechend kann eine Aufgabe im Kanban Board erst auf “Done” gestellt werden, wenn sie vollständig die Bedingungen der “Definition of Done” erfüllt. 

💡Sprint Backlog

Der Sprint Backlog folgt in der Struktur dem Product Backlog, ist jedoch der konkrete Plan für den aktuellen Sprint und enthält somit alle Aufgaben, die im laufenden Sprint durch das Entwicklungsteam bearbeitet werden. Während das  Product Backlog im Verantwortungsbereich des Product Owners steht, gehört der Sprint Backlog einzig und allein dem umsetzenden Team. Der Sprint Backlog ist das Ergebnis der gemeinsamen Sprint Planung, indem Product Owner und das Projektteam gemeinsam die Backlog Items für den kommenden Sprint ausgewählt haben .

💡Product Increment

Das Product Inkrement beschreibt das in einem Sprint erreichte Arbeitsergebnis und entspricht somit der Summe aller Product-Backlog-Einträge, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden. Ziel jedes Inkrements ist es einen nutzbaren Zustand zu erreichen und der Definition of Done zu entsprechen. Es ist damit ein wesentlicher Bestandteil und Erfolgsfaktor der Scrum-Methode und unterscheidet sich mit seinem expliziten Anspruch schnell nutzbaren Mehrwert zu erzielen von klassischen Projektmethoden.

Mittlerweile hat das Scrum Modell über 25 Jahre Reifeprüfung und viele Adaptionen hinter sich. Dadurch ist Scrum in Verbindung mit dem Kanban-Board mittlerweile ein defacto Standard für die agile Produktentwicklung und agiles Projektmanagement geworden. Aber nicht nur die klare Struktur, die Fokussierung auf ein konkretes Ziel, sondern auch die Anwendung agiler Werte und Prinzipien sind entscheidende Erfolgsfaktoren dieser Methode.

💡Product Vision

Genau vor diesem Hintergrund gibt die Product Vision Antworten auf die Fragen, warum das Produkt entwickelt wird und welchen Mehrwert es dem Kunden oder Nutzer generieren soll. Diese Product Vision muss nicht nur für das gesamte Scrum Team, sondern auch für weitere Stakeholder wie die Geschäftsführung, wichtige Netzwerkpartner sowie den Kunden verständlich sein. Insofern ist eine kurze, klare und prägnante Product Vision zielführend und sollte die Bestandteile wie Zielgruppe, deren Bedürfnisse  und Probleme als auch die Erfolgsfaktoren des Produktes beinhalten. Häufig fehlt diese Product Vision und damit wichtige Leitplanken in grundlegenden Entscheidungssituationen. Somit empfiehlt es sich, nicht nur auf Unternehmensebene eine klare Vision zu formulieren sondern auch auf Produktentwicklungs- und Projektmanagementebene.

Sie überlegen wie Sie agiles Projektmanagement in Ihrem Unternehmen einführen sollen oder ihre ersten Schritte in den neuen Arbeitswelten sind noch holprig? Dann unterstützen Sie Ihr Führungskräfteteam auf dem Wege der Transformation und stellen Ihnen einen Agile Coach für strategischen und konkrete Fragen im unternehmerischen Alltag zur Seite.