Mit der Scrum Methode zu mehr Erfolg in digitalen Projekten

Agilität am Arbeitsplatz ist ein Mindset, das aus modernen Unternehmen nicht mehr wegzudenken ist und dabei das Ziel verfolgt, Organisationen flexibler, anpassungs- und reaktionsfähiger zu machen. Auch Transparenz, Flexibilität, kontinuierliche Verbesserung, Effizienz und Kundenzentrierung sind Merkmale von Scrum. Dabei sollen komplexe Projekte und Arbeitsabläufe so organisiert werden, dass möglichst schnell ein lauffähiges Ergebnis entsteht und die Time-to-Market verkürzt wird. Durch regelmäßiges User-Feedback wird ebenso eine höhere Qualität geschaffen. Somit gilt Scrum als effektive und effiziente Weise, um hochwertige Ergebnisse zu liefern. In einem agilen Unternehmen besteht ein stetiger Wille zur kontinuierlichen Verbesserung. Ergebnisse werden fortlaufend überprüft und gegebenenfalls angepasst. Alle Projektbeteiligten besitzen die notwendige Befähigung zur Ausübung ihrer Arbeit und es findet ein regelmäßiger Austausch aller Beteiligten statt. Führungskräfte besitzen im Agile Leadership Szenario nur noch eine unterstützende Rolle und erhalten das Rahmenwerk aufrecht.

Die agile Scrum Methode bezeichnet ein Framework für das Projektmanagement. Eine schnelle, schrittweise Produktentwicklung mit kontinuierlicher Verbesserung, eine produktive Zusammenarbeit mit regelmäßigem Feedback und schlanke Workflows zeichnen die agilen Methoden des Scrum aus. Im Scrum Vorgehensmodell ist es wichtig, dass alle Beteiligten die nötigen Befugnisse besitzen, um selbstständig zu arbeiten.

Scrum, Kanban und Agile: Wo liegen die Unterschiede?

Im Projektmanagement und Entwicklungsprozess werden viele unterschiedliche Begriffe verwendet. Scrum vs. Kanban vs. agile Methoden – da geht Laien schnell der Überblick verloren. Tatsächlich sind Agile vs. Scrum keine Gegensätze, denn das Scrum Prinzip ist ebenso wie Kanban ein Framework zur Umsetzung der agilen Methoden. Obwohl beide zur gleichen Unterart gehören, finden sich einige Unterschiede zwischen Kanban vs. Scrum, beispielsweise in der Rollenverteilung. Während Scrum Rollen fest verteilt sind, bietet Kanban in diesem Fall größeren Spielraum in der Projektumsetzung. Scrum fokussiert sich auf eine iterative Produktentwicklung, Kanban dagegen auf die kontinuierliche Verbesserung des Prozesses.

Demzufolge ist der Scrum Prozess optimal geeignet, um gewünschte Produkte für einen Kunden zu entwickeln, während Kanban darauf abzielt, interne Prozesse auf lange Sicht zu optimieren und Schwachstellen oder Engpässe aufzudecken.

Geschichtlicher Exkurs

Das Wort „Scrum“ ist keine moderne Wortneuschöpfung, sondern stammt ursprünglich aus dem Sportbereich. Im Rugby bezeichnet der Begriff so viel wie „dichtes Gedränge“, welches dann entsteht, wenn sich die Spieler um den Ball versammeln. In unserem Kontext geht das Scrum Framework jedoch auf einen Aufsatz von Ikujirō Nonaka und Hirotaka Takeuchi zurück, der den Titel „The New New Product Development Game“ trägt und im Jahr 1986 veröffentlicht wurde. Basierend auf diesen Artikel entwickelten Mike Beedle, Jeff Sutherland und Ken Schwaber für die agile Softwareentwicklung das Scrum Modell in den 1990er-Jahren. Seitdem hat sich die Methode jedoch stark ausgebreitet und wird heutzutage in der allgemeinen Produktentwicklung angewandt.

In diesem Abschnitt folgt ein Scrum Ablauf in unserer Agentur. Dabei übernehmen wir alle Rollen des Scrum Teams und besetzen diese mit entsprechenden Expert:innen. Die Prozessverwaltung sowie die Moderation liegt in unserer Verantwortung. Zu Beginn des Prozesses findet ein Onboarding statt, bei dem Kund:innen über den gesamten Prozess aufgeklärt werden.

1. Organisation des Product Backlogs vom Product Owner

Der Product Owner stimmt in Zusammenarbeit mit den Kund:innen den Product Backlog ab, der dabei verfeinert und mit Prioritäten versehen wird. Zudem finden regelmäßige Scrum Meetings und Abstimmungen mit Kund:innen im zweiwöchentlichen Rhythmus statt, um Zwischenstände zu übermitteln und Feedback einzuholen. Der Hauptansprechpartner unserer Kund:innen bleibt der Product Owner, der für alle Seiten des Product Backlogs verantwortlich ist. Dazu zählen das Sammeln der relevanten Anforderungen, die Priorisierung, Briefings und auch das Budget.

2. Sprint Meeting

Kund:innen sind im darauffolgenden Sprint Meeting nicht anwesend, werden aber anschließend von uns über das Sprintziel und alle wichtige Fakten informiert. Wir arbeiten in zweiwöchentlichen Sprints, welche die Punkte 2–5 beinhalten und nach Ende eines Sprints von vorn beginnen. Dabei starten wir mit der Sprintplanung, welche die vom Product Owner definierten Ziele enthält, die am Ende des Sprints erreicht werden sollen. Ein Beispiel für die Erreichung des Sprintziels ist die Entwicklung einer Website-Navigation, die das Navigieren durch die Seite für Nutzer:innen intuitiv und einfach macht.

Dabei bringen Entwickler:innen oft User Stories (Software-Anforderungen) zum Einsatz, die nach dem INVEST-Prinzip klar formuliert werden. Das Prinzip basiert auf den folgenden Bestandteilen:

• Independent (unabhängig)
• Negotiable (verhandelbar)
• Valuable (nützlich)
• Estimable (schätzbar)
• Small (klein)
• Testable (überprüfbar)

Bei der Aufnahme der User Stories wird darauf geachtet, dass in den einzelnen Projektmanagement-Sprints genügend Kapazitäten zur Verfügung stehen.

3. Daily Scrum

Ein Daily Scrum ist ein festgelegtes Event, welches jeden Morgen stattfindet, um die Aufgaben für den Tag zu besprechen. In diesem Meeting teilen Entwickler:innen ihren Status quo, zeigen eventuelle Hürden auf und besprechen Wege, wie diese Hürden beseitigt werden können. Es kann als ein schneller Abgleich innerhalb des Teams verstanden werden. Auch hier sind Kund:innen nicht anwesend.

4. Sprint Review

In einem Review Meeting wird das aktuelle Produktinkrement als Zwischenergebnis von dem gesamten Scrum Team präsentiert. Dabei handelt es sich stets um einen live-fähigen Stand des Produkts. Kund:innen sind in diesem Meeting anwesend und können das Ergebnis einsehen. Sie haben ebenfalls die Möglichkeit, Fragen zu stellen und Feedback zu geben.

5. Retro

Ein Retro findet am Ende eines Sprints intern statt, um den vergangenen Sprint zu besprechen. In den retrospektiven Scrum Methoden geht es vor allem um die Zusammenarbeit im Team und was daran in zukünftigen Sprints verbessert werden kann.

Mit diesem Schritt ist ein Sprint abgeschlossen. Im Anschluss beginnen Phase 2–5 erneut.

Product Backlog

Der Product Backlog beinhaltet eine Liste aller Anforderungen an das Produkt und hat als oberste Maxime das Produktziel. Der Product Owner ist für den Product Backlog verantwortlich und trägt alle nötigen Anforderungen zusammen, die von Auftraggeber:innen gestellt werden. Anschließend legt der Product Owner in Zusammenarbeit mit den Entwickler:innen fest, welche Anforderungen in den aktuellen Sprint übernommen werden. Das ist abhängig von der Priorität, dem Aufwand und anderen Abhängigkeiten innerhalb des Projekts. Der Product Backlog wird im Laufe der Produktentwicklung stets verändert, erweitert und angepasst.

Sprint Backlog

Der Sprint Backlog beinhaltet alle Anforderungen, die im kommenden Sprint umgesetzt werden sollen. Die Maxime des Sprint Backlogs ist das Sprintziel, das in der Planungsphase entwickelt und stetig im Auge behalten wird. Verantwortlich für den Sprint Backlog sind die Developer:innen. Alle Aufgaben des Sprint Backlogs sind bereits verfeinert und werden von den Entwickler:innen ausgewählt und bearbeitet.

Produktinkrement

Das Produkt, welches nach den einzelnen Sprints entsteht, wird auch als Produktinkrement bezeichnet. Das bedeutet, dass jeder Sprint ein vorangeschrittenes Produktinkrement hervorbringt, wodurch sich Schritt für Schritt dem fertigen Produkt angenähert wird. Jedoch verfolgt Scrum die Mentalität, dass es niemals ein fertiges Produkt geben wird. Stattdessen soll ein Minimum Viable Product erreicht werden – also das Minimum, das benötigt wird, um mit dem Produkt live zu gehen. Die Maxime, das dem Produktinkrement übergeordnet ist, wird als „Definition of Done“ bezeichnet – also die Definition des fertigen Produkts, wobei betrachtet wird, wie langlebig die einzelnen Produktanforderungen umgesetzt wurden. Das Produktinkrement muss Nutzer:innen einen Mehrwert liefern.

Product Owner:in

Product Owner:innen sind verantwortlich für den Product Backlog und übernehmen allgemeine Aufgaben des Projektmanagements, etwa die Organisation von Meetings. Sie analysieren und priorisieren alle Kundenanforderungen, die sich aus Gesprächen mit den Stakeholdern ergeben, und tragen diese an die Software Entwicklungsteams weiter. Auch das Budget fällt in ihren Aufgabenbereich. Das Ziel der Product Owner:innen ist die Nutzenmaximierung.

Scrum Master:in

Die Scrum Master:innen haben die Aufgabe, dafür zu sorgen, dass das Scrum Framework eingehalten wird. Dabei arbeiten sie eng mit den Product Owner:inen, dem Entwicklerteam und auch dem Rest des Unternehmens zusammen. Teilaufgaben, die in diesen Bereich fallen, können unter anderem die Moderation von Scrum Meetings, Unterstützung von Product Owner und Entwicklerteam oder auch Unterstützung des Unternehmens bei der Einführung der Scrum Methoden sein. Das Ziel der Scrum Master:innen ist es, ein funktionierendes Scrum Team zu ermöglichen.

Developer:innen

Developer:innen und Entwickler:innen sind verantwortlich für die Produktfunktion und den Sprint und sorgen für die Einhaltung der Qualitätsstandards. Das Ziel der Developer:innen ist ein funktionsfähiges Produktinkrement.

Scrum Teams

Scrum Teams setzen sich aus Product Owner:in, Scrum Master:in und Entwickler:innen zusammen und arbeiten sowohl selbstorganisiert als auch interdisziplinär. Dabei findet ein stetiger Wissensaustausch zwischen den einzelnen Teammitgliedern statt. Projektmanager:innen sind in einem Scrum Team nicht vorgesehen, denn die organisatorischen Funktionen werden von Product Owner:innen übernommen.

Grundsätzlich ist die Einführung eines Scrum Frameworks immer dann sinnvoll, wenn Unternehmen komplexe digitale Projekte verwirklichen möchten. Das bezieht sich nicht ausschließlich auf Websites, sondern kann auch die Umsetzung einer App oder eines Intranets beinhalten.

Vor allem in der Erstellung moderner, komplexer Websites kann die Scrum Methode viele Vorteile mit sich bringen. Mit einem Responsive Webdesign, der DSGVO, Barrierefreiheit, Sicherheitsmaßnahmen, guten Inhalten und der Ausrichtung auf die Zielgruppe für eine gute User Experience gibt es bei einem solchen Projekt viel zu beachten. In diesem Fall bietet Scrum die nötige Agilität und Flexibilität, um Anforderungen im zwei-Wochen-Takt neu zu bewerten und flexibel auf Änderungen zu reagieren, um sich dem Endprodukt schrittweise zu nähern.

Im Projektmanagement die Scrum Methode anzuwenden, ergibt nicht in jedem Unternehmen oder auch in jedem Projekt einen Sinn. Dennoch bringt sie vor allem bei komplexen und digitalen Projekten viele Vorteile mit sich, die einem Team zum Erfolg verhelfen:

Flexibilität

Scrum Teams erhalten beim agilen Arbeiten mit der Scrum Methode die nötige Flexibilität, um schnell auf Änderungen reagieren zu können. Da in Sprints gearbeitet wird, können Prioritäten und Anforderungen schnell und einfach an die aktuelle Situation angepasst werden.

Fortlaufenden Austausch

Im Scrum Modell sind regelmäßige Abstimmungen und Events vorgesehen, beispielsweise als tägliche Scrum Meetings oder als Sprint Review am Ende eines Sprints. Das fördert die Kommunikation innerhalb des Teams und sorgt dafür, dass alle Mitarbeiter:innen stets den gleichen Informationsstand besitzen. Auch regelmäßiges User-Testing und die Einbeziehung des User-Feedbacks sind ein fester Bestandteil der Scrum Methode.

Zeit- und Budgetkontrolle

Scrum ermöglicht Unternehmen eine bessere Kontrolle über die eingesetzte Arbeitszeit und das Budget. Dabei hat der Product Owner die Verantwortung, das Budget in Zusammenarbeit mit den Kund:innen festzulegen. Die Arbeit in Sprints ermöglicht ein besseres und genaueres Zeitmanagement im gesamten Team, vor allem aber unter den Developer:innen.

Kund:innen oder Stakeholder werden sehr stark in den Scrum Prozess einbezogen. Regelmäßige Meetings sind in der Scrum Methode essenziell, um die notwendige Kommunikation sicherzustellen und eine Feedback-Kultur zu erzeugen. Das bedeutet, dass Kund:innen auch schnell und kurzfristig Feedback geben können, wenn es benötigt wird.

Auf der Seite der Kund:innen bedeutet das aber ebenso, dass Unternehmen die entsprechenden Kapazitäten für diese Kultur zur Verfügung stellen müssen und einen „Single Point of Contact“ bieten – also ein fester Ansprechpartner, der die Anforderungen, die Wünsche und das Feedback unserer Kund:innen klar und deutlich kommuniziert. Wechselnde Ansprechpartner:innen und fehlende Kommunikation sind im Scrum Prozess hinderlich.