Was ist Scrum?

Was ist Scrum? Scrum ist ein agiles Framework. Einige sind sogar der Meinung, dass die beiden Begriffe identisch sind. Dies ist jedoch nicht richtig. Agil ist eine Projektmanagement-Methode, bei der es darum geht, den größten Nutzen zu liefern. Sie nennt 12 Prinzipien, die Unternehmen befolgen müssen. Scrum ist ein Framework, das Teams und Unternehmen verwenden, um agile Werte in ihre täglichen Aktivitäten zu integrieren. Was ist also Scrum?

Die Scrum Methode ist ein Framework für agiles Projektmanagement. Lassen Sie uns Ihnen mehr davon erzählen.

Die Geschichte von Scrum 

In den 90er Jahren fingen die Gespräche über die Verbesserung von den Arbeitsmethoden des Software-Entwicklungsteams an. Wasserfall-Projekte lieferten ständig verspätete Ergebnisse, und alles, was die Manager taten, um die Situation zu verbessern, machte sie noch schlimmer. Auf der Suche nach etwas, das funktioniert, begann Jeff Sutherland mit kleineren Teams zu arbeiten und Projekte um Iterationen herum zu organisieren. Er verstand schnell, dass diese Art der Arbeitsorganisation Transparenz, Fokus und Engagement bot – dies fehlte den Wasserfall-Projekten.

Als Teams begannen, schnell Ergebnisse zu liefern, wuchs das Interesse an dieser neuen Projektmanagementmethode. Jeffs Kollege zog die Parallele zwischen einem kleinen Software-Team, das eng zusammenarbeitete, und „scrummage“ im Rugby. So wurde der Name Scrum geboren. Und es waren Ken Schwaber und Jeff Sutherland auf der OOPSLA-Konferenz 1995, die den Prozess von Scrum offiziell der Öffentlichkeit vorstellten.

Seitdem wurde Scrum von vielen anderen verbessert und wuchs von einem Prozess zu einem voll entwickelten Framework. Und als solches wurde es zu einer der beliebtesten Arten der Anwendung von Agile. Laut dem 14. State of Agile-Bericht gaben 58% der Befragten an, dass sie Scrum zur Anwendung von Agile verwenden. Ein Teil dieser Popularität hängt zweifellos mit der Tatsache zusammen, dass Scrum recht einfach zu verstehen ist. Der Hauptgrund für die breite Anwendung ist jedoch, dass es eine Möglichkeit bietet, komplexe Probleme zu lösen und gleichzeitig produktiv und kreativ Ergebnisse von höchstmöglichem Wert zu liefern.

Die Hauptidee 

Die Scrum Methode ist einfach – das Team plant und erledigt die Arbeit in Iterationen von 1 bis 4 Wochen und liefert nach jedem Sprint einen hohen Mehrwert. Nach jedem Sprint wird dann eine Besprechung mit den Stakeholdern organisiert, um Feedback zu erhalten, und das Team kann die Vorgehensweise für den nächsten Sprint entsprechend den Kommentaren der Stakeholder anpassen. Dadurch wird es einfach, auf Veränderungen innerhalb oder außerhalb des Unternehmens zu reagieren und sich an diese anzupassen.

Mit Scrum kann das Team einfacher kommunizieren, schneller Feedback sammeln und weiter in die Richtung arbeiten, die für alle am besten geeignet ist. Diese Arbeitsweise erfordert Transparenz und Verantwortlichkeit und das Team arbeitet als eine Einheit an einem einzigen Ziel.

Scrum funktioniert am besten, wenn es in einer Teamumgebung eingesetzt wird. Die autonomen Teams spielen daher in Scrum eine entscheidende Rolle. Scrum kann skaliert werden, um Unternehmen unterschiedlicher Größe zu unterstützen. Mit steigender Unternehmensgröße sinkt jedoch die Scrum-Produktivität. Sie sollten sich auf ein solches Szenario vorbereiten.

Wie funktioniert es? 

Um die Arbeit zu organisieren und die gewünschten Ergebnisse zu liefern, verwendet Scrum bestimmte Rollen, Werkzeuge und Praktiken. Und wenn man sie kennt, bekommt man eine genaue Vorstellung davon, wie die Arbeit in einem Scrum-Projekt aussieht. Hier sind sie also.

Die Rollen

Als erstes sollten Sie auf die Struktur Ihres Unternehmens achten. Scrum funktioniert am besten, wenn die Arbeit in kleinen Teams mit spezifischen Zielen verteilt wird. Sie sollten also Ihre Struktur überprüfen und vielleicht auch neu gestalten. Sobald die Verteilung von Teams klar ist, werden Sie auch neue Rollen zuweisen müssen. Scrum erfordert, dass in jedem Team 3 bestimmte Rollen zur Verfügung stehen.

Das Scrum Entwicklungsteam

Scrum ist nicht nur eine agile Entwicklungsmethode, sondern auch eine Möglichkeit, Zusammenarbeit effektiv zu organisieren. Wir nennen das Team, das die Anforderungen schließlich umsetzt, das Entwicklungsteam. Wenn das Team vom Product Owner die Anforderungsliste (Product Backlog) bekommt, entscheidet es, wie es mit den Anforderungen in der nächsten Arbeitsphase (Sprint) umgeht. Ein Team sollte aus ca. 7 Personen aus verschiedensten Disziplinen bestehen.

Der Product Owner

Der Product Owner ist derjenige, der das Ziel und die Anforderung des Projektes formuliert und beim Scrum Team in Auftrag gibt. Dazu fungiert er als Schnittstelle zwischen dem Scrum Team und der Außenwelt, also Kunden, Stakeholdern und anderen Beteiligten.

Das heißt, der Product Owner ist verantwortlich dafür, dass das entstandene Produkt später beim Kunden auch gut ankommt, dass es für den Kunden attraktiv und dadurch marktfähig ist. Die Informationen, die er vom Kunden erhält, schlüsselt er in einzelne Arbeitsaufgaben auf und stellt dem Team dann das zu erreichende Ziel sowie die Schritte dorthin zur Verfügung; dafür erstellt er eine Anforderungsliste (Product Backlog).

Weiterhin fällt in seinen Verantwortungsbereich die Priorisierung der Aufgaben: Womit wird angefangen, was ist im Moment das Wichtigste? Er kann einschätzen, worauf der Kunde gerade seinen größten Schwerpunkt legt; so könnte es in der Softwareentwicklung vorrangig sein, dem Kunden einen bestimmten Teil eines Programms zügig zum Testen vorlegen zu können.

Nach Abschluss eines Sprints nimmt der Product Owner die gemachten Fortschritte ab, gibt seine Meinung dazu und holt die Rückmeldungen von Kunden und Stakeholdern dazu ein. Diesen Arbeitsschritt nennt man Sprint Review.

Der Scrum Master

Der Scrum Master moderiert den Prozess, indem er sicherstellt, dass die Kommunikation fließt und dass die verschiedenen Meeting-Formate und Strukturen auch gelebt werden. Statt Aufgaben zu organisieren und zu verteilen, stellt er die Plattform zur Verfügung, die dem Entwicklungsteam ermöglicht selbst zu entscheiden wer wann welche Aufgaben übernimmt, wie sie organisiert werden und wie viele davon in welchem Zeitraum zu schaffen sind. Bei diesen Entscheidungen steht er moderierend zur Seite.

Der Scrum Master räumt Hindernisse aus dem Weg und schützt sein Team vor Störungen von außen.

 Wenn einmal Konflikte auftreten, dann übernimmt er die Rolle des Mediators.

Hier ist ein ausführlicher Artikel, der den Unterschied zwischen einem Scrum Master und einem Projektmanager erklärt.

Die Tools

Es ist jetzt Zeit, von den Werkzeugen von Scrum zu erzählen. Scrum erfordert eine etwas andere Art und Weise der Planung und Verfolgung der Arbeit. Daher verwendet das Framework ein Scrum-Board, User Stories und Story Points, um die Arbeit des Teams zu beschreiben. Hier ist ein wenig mehr über jedes Werkzeug.

Scrum-Board 

Das Scrum-Board ist eines der wichtigsten Werkzeuge, das eine effektive Planung und Verfolgung des Fortschritts ermöglicht. Es besteht normalerweise aus 3 Teilen, die vom Product Owner oder dem Scrum-Team verwaltet werden.

Das erste Element ist das Product Backlog. Dieses wird nur vom Product Owner verwaltet und enthält alle Pläne für das Projekt in Form von priorisierten User Stories. Das Scrum-Team kann zwar auch User Stories von den Stakeholdern sammeln, aber nur der Product Owner kann sie zum Product Backlog hinzufügen. Dieses Element des Boards wird bei jedem Sprintplanning verwendet, um das Sprint-Ziel festzulegen und Aufgaben zu planen.

Das zweite Element ist das Sprint Backlog. Dies ist der Ort, den das Scrum-Team verwendet, um User Stories in konkrete Aufgaben zu unterteilen. Das Sprint Backlog wird während des Sprints geleert und dann während jeder Sprintplanning-Sitzung mit neuen Tasks wieder aufgefüllt.

Die Spalten zur Fortschrittsverfolgung sind das letzte Element des Scrum-Boards. Diese wird ebenfalls vom Scrum-Team verwaltet und hilft, den Fortschritt des Sprints zu verfolgen. Dieses Element kann nur aus zwei Teilen bestehen – Doing und Done – oder so detailliert, wie es das Team benötigt, sein, um den Fortschritt effektiv zu verfolgen. Hier sind ein paar Beispiele für Scrum-Boards.

What is Scrum board

What is Scrum board

User Stories 

Um Pläne und Elemente zu definieren, verwendet Scrum User Stories. Diese werden von den Kunden gesammelt und definieren, wie das Endergebnis des Projekts aussehen soll. Um beim Schreiben der User Stories zu helfen, gibt es ein bestimmtes Format, das sie folgen müssen – Als …, ich will …, damit … .

Wenn der Product Owner also Informationen von Kunden und Beteiligten sammelt, schreibt er die User Stories in diesem Format auf und platziert sie entsprechend ihrer Priorität im Product Backlog. Während des Sprint-Plannings wählt das Scrum-Team die wichtigsten User Stories aus und hat dann die wichtigsten Aufgaben, die es erledigen muss.

Beim Schreiben von User Stories ist es wichtig zu beachten, dass das Scrum-Team in der Lage sein muss, diese in einem Sprint zu bewältigen. Wenn das nicht möglich ist, wird die User Story zu einem Epic. Dies teilt der Product Owner dann in kleinere User Stories auf. Lesen Sie mehr über User Stories.

Story Points 

Story Points sind eine Einheit zur Beschreibung der Größe einer User Story. Sie repräsentieren den Entwicklungsaufwand und die Faktoren, die diesen Aufwand beeinflussen.

Es geht bei Story Points primär also nicht um die Zeit, die zur Umsetzung der User Story benötigt wird, sondern um die strukturellen Eigenschaften einer User Story. Ein erfahrenes Entwicklungsteam kann natürlich im Vergleich zu einem weniger erfahrenen Team größere User Storys in einem Sprint umsetzen, doch die Größe der Story bleibt davon unberührt. In anderen Worten: die Eigenschaften einer User Story hängen nicht von den Fähigkeiten des Teams ab. Die Schätzung einer User Story verändert sich also auch nicht, wenn anstelle eines Junior-Entwicklers ein Senior-Entwickler die Implementierung vornimmt.

Da es jedoch nicht einfach ist, alle Faktoren in einer einzigen Zahl wiederzugeben, empfiehlt es sich, immer den Aufwand zu den Faktoren zu bestimmen: Wie viel Aufwand macht es bspw., mit dem Risiko und der Ungewissheit umzugehen? Je höher der Aufwand zur Beseitigung einer Unsicherheit ist, desto höher wird die Einschätzung der Story Points. Die Kombination der Faktoren führt somit zur Story Points Schätzung – auch als Story Points Estimation bezeichnet.

Scrum Prozess

Der Scrum Prozess besteht aus Sprints. Dabei ist jeder  Sprint durch fest definierte Meetings gekennzeichnet, deren Intention, Dauer und Ziele klar definiert sind.

Der Sprint 

Der Sprint ist das oberste zentrale Ordnungsprinzip im Scrum Framework. Dabei ist ein Sprint ein fest definiertes Zeitintervall, in dem das Team an der Erledigung der vereinbarten Aufgaben und der Erreichung des Sprint-Ziels arbeitet. Sprints geben sich die Klinke in die Hand. Das heißt, das Ende des einen Sprints ist der Anfang des nächsten Sprints. Die Dauer eines Sprints beträgt typischerweise 1-4 Wochen und wird in Abhängigkeit des Produktes / Projektes festgelegt. 

Die Sprintdauer ist fix, d.h. alle Sprints haben die gleiche Dauer. Das gilt solange, bis man möglicherweise feststellt, dass eine andere Sprintdauer angemessener wäre. Dann ändert man die Sprintdauer und bleibt dabei.  

Sprints dauern max. vier Wochen. Der relativ kurze Zyklus von vier Wochen ist der Einsicht geschuldet, dass mit zunehmender Länge eines Zyklus die Qualität der Planung sinkt.

4 Schlüsselereignisse finden bei jedem Sprint statt, um ihn effektiv zu gestalten.

I. Sprint Planning 

Jeder Sprint startet mit einem gemeinsamen Planning, an dem das gesamte Scrum Team (PO, Projektteam, Scrum Master) teilnimmt. Während des Plannings werden anstehende Aufgaben diskutiert und der erwartete Aufwand geschätzt. Mit der Schätzung über den erwarteten Aufwand wird der PO befähigt, um auf Basis des erwarteten Nutzens und der Kosten eine Entscheidung bzgl. der Priorisierung zu treffen.

Das umsetzende Team committet sich auf die Aufgaben, übernimmt die priorisierten Aufgaben in sein Sprint Backlog und der PO formuliert abschließend ein Sprint Ziel. Bei einem vierwöchigen Sprint werden für ein Planning 8 Stunden angesetzt.

II. Daily Scrum 

Das Daily ist eine tägliche Synchronisation des umsetzenden Teams. Da die Dauer auf 15 Minuten begrenzt ist, findet es oft im Stehen statt. Deswegen wird es mitunter auch “Stand Up” genannt. Dabei haben das Stehen und die enge Timebox einen ganz einfachen Hintergrund. Denn statt sich in epischer Breite auszulassen, ist jedes Teammitglied eingeladen ein kurzes Update zu geben, um sich mit den Kollegen zu synchronisieren.

Wo stehe ich gerade, brauche ich Hilfe, habe ich sonstige Fragen? Sollte sich daraus weiterer Gesprächsbedarf ergeben, finden im Anschluss an das Daily weiterführende Gespräche statt, anstatt das gesamte Team während des Dailys damit zu behelligen. Das Daily ist ein Meeting das Projektteams, das jeden Tag zu gleicher Zeit am gleichen Ort stattfindet. Das heißt, der Scrum Master und der Product Owner nehmen nur optional teil. 

III. Sprint Review 

Zum Ende des Sprints präsentiert das Projekt- bzw. Produktteam die Arbeitsergebnisse des Sprints. Zu der Review werden neben dem Product Owner, vor allem interessierte Stakeholder und auch ausgewählte Kunden eingeladen. Zum einen bietet die Review dem Projekt- bzw. Produktteam eine Bühne für das was es im zurückliegenden Sprint geschafft hat. Zum anderen erhalten Stakeholder und eingeladene Personen die Möglichkeit Feedback zu geben und Fragen zu stellen, um damit auch auf künftige Planungen Einfluss zu nehmen.

Die Entscheidung, was davon wie priorisiert wird, obliegt jedoch alleine dem Product Owner. Das heißt, die Review ist keine Abnahme und auch ausdrücklich nicht mit einem Lenkungsausschuss zu vergleichen. Denn hier präsentiert ein autonomes Team, das auf Basis einer gemeinsamen Planung mit dem Product Owner sein bestmögliches getan hat. Nicht fertiggestellte Arbeitspakete und Aufgaben wandern direkt in das nächste Planning. 

IV. Sprint Retrospective 

Schließlich endet der Sprint mit einer Retrospektive des Scrum Teams. Dazu treffen sich das Projektteam, der Product Owner und der Scrum Master, um die Zusammenarbeit zu reflektieren und basierend auf diesen Einsichten Vereinbarungen für künftige Sprints zu treffen. Das heißt, in der Retrospektive geht es ausschließlich um den Arbeitsprozess, gar nicht um Inhalte bzw. Arbeitsergebnisse. 

Dabei sind Retrospektiven dann besonders wirksam, wenn Teilnehmer den Wunsch nach ständiger Verbesserung und eine gesunde Portion Selbstreflexion mitbringen. In der japanischen Lean Philosophie wird diese Haltung mit den Prinzipien Kaizen und Hansei bestens beschrieben. Die Retrospektive schließt mit konkreten Vereinbarungen, die im nächsten Sprint umgesetzt werden und unter Umständen auch einen eigenen Eintrag im Sprint Backlog erhalten.

Häufige Missverständnisse

Hier sind einige der häufigsten Missverständnisse in Bezug auf den Scrum Prozess:

1. Scrum Master ist der Boss

Das Wort „Master“ klingt zwar grandios, aber der Scrum Master ist nicht da, um Befehle zu geben. Die Rolle des Scrum-Masters besteht darin, dem Team zu helfen, die Scrum Praktiken umzusetzen. Scrum Master soll den Scrum-Prozess erleichtern und die Unternehmenskultur verändern.

Der Scrum-Master sorgt dafür, dass der Scrum-Prozess funktioniert.

2. Am Ende eines jeden Sprints wird ein Produktinkrement geliefert und veröffentlicht

Das Entwickler-Team kann jederzeit und so häufig wie gewünscht im Laufe eines Sprints Auslieferungen vornehmen, solange mindestens ein potentielles Produktinkrement pro Sprint freigegeben wird. Wie im Abschnitt „Sprint“ beschrieben, können Veröffentlichungen ebenfalls jederzeit und so oft wie gewünscht durchgeführt werden. Scrum verlangt nicht einmal, dass jeden Sprint eine Veröffentlichung durchgeführt werden muss. Ausschließlich der Product Owner entscheidet, wann veröffentlicht wird. Und das kann theoretisch auch mehrmals während eines Sprints sein.

3. Der Sprint-Review für einen einmonatigen Sprint dauert vier Stunden

Wo vorher im Scrum Guide stand:
„Es ist ein vierstündiges Meeting für einen 1-Monat-Sprint.“

Steht jetzt im Scrum Guide geschrieben:
„Es ist zumeist ein vierstündiges Meeting für einen 1-Monat-Sprint.“

Dies betont, dass es in Ordnung ist, die Timebox bei Gelegenheit zu verkleinern. Das gilt zudem auch für die Sprint Retrospektive. Also wenn Sie fertig sind, bevor die Timebox abläuft, können Sie das Meeting auch eher beenden.

4.  Scrum wird nur in der IT angewandt

Auch wenn der Scrum Guide keine Wörter wie „IT“ oder „Software“ beinhaltet, hört man trotzdem oft, dass Scrum nur für die IT-Branche gedacht ist. Ironischerweise beinhaltet die neueste Version des Scrum Guide jetzt sogar das Wort „Software“, aber nur in dem Zusammenhang, dass Scrum nicht nur auf die Softwareentwicklung limitiert ist. Das neue Kapitel „Uses of Scrum“ erklärt, dass Scrum zudem auch für Produkte, Dienstleistungen und das Management der einzelnen Organisationen genutzt werden kann. Scrum ist ein Framework, in welchem komplexe Probleme angesprochen werden können, und ja, die Softwareentwicklung neigt ebenfalls dazu komplex zu sein.

5. Der Scrum Master ist nur ein Team Coach

Die Rolle des Scrum Master wird oft missverstanden. Glücklicherweise beschreibt der aktuelle Scrum Guide ausführlicher, welche Verantwortungen der Scrum Master trägt: „Die Aufgabe des Scrum Masters ist es, Scrum so zu fördern und zu unterstützen, wie es im Scrum Guide niedergeschrieben ist. Scrum Master machen das, indem sie allen dabei helfen, die Scrum Theorien, Praktiken, Regeln und Werte zu verstehen.“

Ein Scrum Team operiert in einem organisatorischen Umfeld. Dieses beeinflusst, wie effektiv das Scrum Team sein kann. Die anderen Personen zu coachen und das Umfeld um das Scrum Team zu optimieren ist ausschlaggebend, um mit Scrum erfolgreich zu sein. Der Scrum Master kann auch als Change Agent für Agilität und Scrum im gesamten Unternehmen angesehen werden, der kontinuierlich Hindernisse beseitigt.

Zusammenfassung

Scrum ist ein großartiges Framework, um neue Ideen zu testen. Man kann auch sofort verstehen, ob sie auf lange Sicht funktionieren werden. Nach ein paar Iterationen haben Teams bereits messbare Ergebnisse, die sie den Stakeholdern liefern können. Scrum ist eine gute Wahl für Teams, die Projekte unter sich ständig ändernden Umständen verwalten müssen. Und ehrlich gesagt, das sind die meisten von uns.

Im Vergleich zu anderen agilen Frameworks ist Scrum das verständlichste. Allerdings sollten Sie darauf achten, dass die Implementierung von Scrum nicht so einfach ist, wie Sie vielleicht denken. Wenn es Sie interessiert, wie Scrum im Vergleich zu anderen agilen Frameworks aussieht, hier ist Scrum vs Kanban vs Scrumban.  

Und wenn Sie Scrum in einem größeren Unternehmen testen wollen, hier ist ein Überblick über den Scrum of Scrums.

Wh

at is Scrum board

What is Scrum board

Resources

Wissensbasis