Scrum – die inzwischen gängigste agile Methode im Projekt- und Produktmanagement. Doch was ist Scrum eigentlich? Im nachfolgenden Beitrag werden wir einen kurzen Überblick über die Methode und ihre Einsätze in Unternehmen geben.
Schon 1995 wurde der erste Konferenzbeitrag zu Scrum als Methode veröffentlicht. Jeff Sutherland schuf mit Scrum – inspiriert von Ikujiro Nonaka und Hirotaka Takeuchi – eine neue Rolle für Projektleiter, die nun zu Teammitgliedern wurden und statt Manager nun die Rolle von Moderatoren einnahmen. In diesem Konferenzbeitrag schreibt Sutherland, „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.“
Auch der Begriff Scrum stammt von Nonaka und Takeuchi, die das Gedränge (engl. Scrum) im Rugby als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams beschrieben. Kleine, selbst-organisierte Einheiten, die von außen nur eine Richtung vorgegeben bekommen, aber selbst die Taktik bestimmen, wie sie ihr gemeinsames Ziel erreichen.
Scrum kann als Gegenentwurf zur Befehls-und-Kontroll-Organisation verstanden werden, in der die Mitarbeiter möglichst genaue Arbeitsanweisungen erhalten, die sie auszuführen haben. Bei Scrum dagegen wird auf hochqualifizierte, interdisziplinär besetzte Entwicklungsteams gesetzt, die zwar eine klare Zielvorgabe bekommen, die für die Umsetzung jedoch allein zuständig sein. So bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial selbstständig zur Entfaltung zu bringen.
Scrum ist für ein Team mit 3-9 Entwicklern konzipiert. Für größere Projekte benötigt es ein erweitertes Framework, das die Koordination mehrerer Teams organisiert.
Der Ansatz von Scrum beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können, ein wesentlicher Teil der Anforderungen und Lösungsansätze ist zu Beginn unklar. Diese Unklarheiten werden beseitigt, indem Zwischenergebnisse geschaffen werden, anhand der sich die fehlenden Anforderungen und Lösungstechniken effizienter finden lassen als durch eine abstrakte Klärungsphase.
Neben dem Produkt wir auch die Planung iterativ und inkrementell entwickelt; der langfristige Plan (Product Backlog) wird kontinuierlich verfeinert und verbessert, der Detailplan (Sprint Backlog) wird nur für den jeweils nächsten Zyklus (Sprint) erstellt.
Die empirische Verbesserung der Planung fußt dabei auf drei Säulen:
Transparenz – Fortschritt und Hindernisse werden regelmäßig und für alle sichtbar festgehalten, beispielsweise auf einem Taskboard/Kanban-Board
Überprüfung – Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet
Anpassung – Anforderungen an das Produkt, die Pläne oder das Vorgehen werden nicht einmalig festgelegt, sondern kontinuierlich und detailliert angepasst
2001 wurden außerdem Werte im agilen Manifest formuliert, die Scrum ausmachen:
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
Scrum besteht nur aus wenigen Regeln, die vier Ereignisse, drei Artefakte und drei Rollen beschreiben und den Kern der Methode ausmachen. Sie bilden das Scrum-Framework, das durch Techniken für Umsetzung der Ereignisse, Artefakte und Rollen konkretisiert werden muss, damit die Methode tatsächlich eingesetzt werden kann.
Zusätzliche Anforderungen sind außerdem die Transparenz des Fortschritts, das gemeinsame Verständnis des Scrum Teams unter welchen Bedingungen eine Arbeit als fertig bezeichnet werden kann (Definition of Done) sowie die Definition of Ready, die sicherstellen soll, dass ein Eintrag im Product Backlog vom Team implementiert werden kann.
Das Ziel ist eine schnelle und kostengünstige Entwicklung hochwertiger Produkte, entsprechend einer formulierten Vision. Die Umsetzung dieser Vision erfolgt dabei nicht durch die Aufstellung möglichst detaillierter und umfangreicher Lasten- und Pflichtenhefte, sondern Anforderungen werden im Product Backlog in Form von Eigenschaften aus Anwendersicht formuliert.
Scrum reduziert dabei die Komplexität der Aufgaben nicht, sondern strukturiert sie in kleinere und weniger komplexe Bestandteile (Inkremente).
Product Owner
Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg eines Produkts verantwortlich. Er gestaltet das Produkt mit dem Ziel, seinen Nutzen zu maximieren. Er erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften und urteilt darüber, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden.
Ihm alleine obliegt auch die Entscheidung über das Produkt, seine Eigenschaften und Reihenfolge der Implementierung. Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog, in dem er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt einträgt. Er hält regelmäßig Rücksprache mit Stakeholdern um deren Bedürfnisse und Wünsche zu verstehen, er muss die Interessen und Anforderungen unterschiedlichster Stakeholder verstehen und abwägen.
In der Praxis erhalten Product Owner oft nicht die Vollmacht, die notwendigen Entscheidungen verbindlich zu treffen, anders als in der Rollenkompetenz eigentlich vorgesehen, oft wird er auch mit fremden Aufgaben überlastet.
Entwickler
Die Entwickler sind für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Sie tragen die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Das Scrum-Team organisiert sich selbst, und entscheidet auch, wie es Backlogeinträge umsetzt. Weitere Aufgaben sind die Schätzung des Umfangs der Einträge im Product Backlog (im Product Backlog Refinement) sowie das Herunterbrechen der ausgewählten Einträge in Arbeitsschritte für die Sprint-Planung (= Sprint Backlogs).
Die interdisziplinäre Besetzung eines Scrum-Teams ist wichtig, damit das Team in der Lage ist, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Gute und schlechte Ergebnisse werden nie auf einzelne Mitglieder sondern auf das Team als Einheit zurückgeführt.
Das Scrum-Team besteht aus höchstens 10 Mitgliedern – es muss einerseits groß genug sein, um alle benötigten Kompetenzen zu vereinen, andererseits steigt mit wachsender Teamgröße der Koordinationsaufwand.
Scrum Master
Der Scrum Master ist dafür verantwortlich, dass Scrum als Rahmenwerk gelingt. Er arbeitet mit dem Entwicklungsteam zusammen, gehört aber selbst nicht dazu. Er führt die Scrum-Regeln ein, überprüft deren Einhaltung und kümmert sich um die Behebung von Störungen und Hindernissen, beispielsweise durch mangelnde Kommunikation und Zusammenarbeit, Störungen in Zusammenarbeit zwischen Product Owner und Entwicklungsteam oder Störungen von außen.
Der Scrum Master moderiert die Sprint Retrospektive und oft auch die Sprint Planung und das Backlog Refinement.
Stakeholder
Stakeholder sind Rollen außerhalb von Scrum, beispielsweise Kunden, Anwender oder das Management. Das Scrum-Team tritt mit allen Beteiligten in Kontakt, Fortschritte und Zwischenergebnisse sind für alle Stakeholder transparent und die Stakeholder dürfen bei den meisten Ereignissen zuhören.
Kunden können je nach Situation sowohl interne Fachabteilungen als auch externe Personen oder Gruppen sein. Der Product Owner sollte für die Dauer des Projektes im engen Austausch mit ihnen stehen, zu Beginn muss ein möglichst genaues Verständnis der Wunschvorstellung seiner Kunden gewonnen werden. Kunden sollten schon nach den ersten Sprints Gelegenheit haben, sich die neuen Funktionalitäten anzuschauen und hierzu Feedback zu geben.
Anwender sind die Personen, die das Produkt letztendlich benutzen. Das kann, muss aber nicht zugleich der Kunde sein. Die Rolle des Anwenders ist für das Scrum-Team von besonderer Bedeutung, denn nur Anwender können das Produkt aus der Perspektive des Nutzers beurteilen. Anwender und Kunden sollten beim Sprint Review und dem Product Backlog Refinement hinzugezogen werden, um das Produkt zu erproben und Feedback zu geben.
Das Management trägt die Verantwortung dafür, dass die Rahmenbedingungen stimmen, beispielsweise durch die Bereitstellung von Räumen oder Arbeitsmitteln oder generell Unterstützung für den eingeschlagenen Kurs. Es ist dafür verantwortlich, das Scrum Team vor externen Arbeitsanforderungen zu schützen, eine adäquate personelle Besetzung zu finden sowie den Scrum Master dabei zu unterstützen, Hindernisse auszuräumen.
Ereignisse bei Scrum sind Meetings, in denen bestimmte Themen in einem festen Zeitfenster besprochen werden. Sie drehen sich dabei um „Sprints“, Arbeitsabschnitte in dem ein Teil einer Produktfunktionalität implementiert wird.
Ein Sprint beginnt mit dem Sprint Planning, endet mit dem Sprint Review und der Sprint Retrospektive. Ein Sprint folgt unmittelbar dem nächsten, und während einem Sprint sind keine Änderungen erlaubt, die das Ziel beeinflussen. Er umfasst ein Zeitfenster von 1 bis 4 Wochen, alle Sprints sollten dabei idealerweise die gleiche Länge haben um dem Projekt einen Takt zu geben. Ein Sprint wird niemals verlängert, kann jedoch vorzeitig abgebrochen werden, wenn das Sprint-Ziel nicht mehr erreicht werden soll, beispielsweise weil sich die Zielvorgaben oder Marktbedingungen verändert haben.
Sprint Planning
Im Sprint Planning sind zwei Fragen zu beantworten: Was kann im kommenden Sprint entwickelt werden? Wie wird die Arbeit im kommenden Sprint erledigt? Das Ereignis dauert in Summe maximal 2 Stunden je Sprint-Woche, z.B. maximal 8 Stunden für einen 4-Wochen-Sprint.
Daily Scrum
Für den Daily Scrum trifft sich das Entwicklerteam jeden Tag zu Beginn des Arbeitstages für maximal 15 Minuten. Scrum Master und Product Owner sind häufig anwesend, jedoch nicht aktiv beteiligt, falls sie nicht selbst Backlog-Elemente bearbeiten. Der Zweck ist der Informationsaustausch und der Überblick über den aktuellen Stand der Arbeit, beispielsweise über ein Taskboard. Die zu beantwortenden Fragen sind hierbei, was seit dem letzten Daily Scrum erreicht wurde, was bis zum nächsten erreicht werden soll und was dabei im Weg steht.
Beim Daily Scrum kann offensichtlich werden, dass die Erledigung einer Aufgabe länger als geplant dauert. Dann ist es sinnvoll, diese Aufgabe in kleinere Aufgaben zu teilen, die dann auch von anderen Mitgliedern des Entwicklungsteams übernommen werden können. Treten Fragen auf, die nicht innerhalb der 15-Minuten-Vorgaben beantwortet werden können, werden sie entweder notiert und dem Scrum Master übergeben, oder ihre Beantwortung wird auch ein späteres Meeting – häufig direkt im Anschluss – verlegt.
Sprint Review
Der Sprint Review steht am Ende des Sprints, hier überprüft das Team das Inkrement um das Product Backlog bei Bedarf anzupassen. Das Entwicklungsteam präsentiert Ergebnisse und es wird überprüft ob das zu Beginn gesteckte Ziel erreicht wurde, dann folgt die Besprechung der Ergebnisse und was als nächstes zu tun ist. Hierbei ist die Beteiligung von Kunden und Anwendern wichtig, da diese die fertige Funktionalität benutzen und validieren können, sie liefern wichtiges Feedback für die weitere Produktgestaltung. Der Sprint Review dauert maximal 1 Stunde je Sprint-Woche.
Das Ergebnis des Sprint Reviews ist das vom Product Owner notierte Feedback der Stakeholder, eine notwendige Information bei der weiteren Gestaltung des Product Backlogs im nächsten Product Backlock Refinements.
Die Abnahme ist nicht primärer Gegenstand des Sprint Reviews, bei dem es vorrangig um Feedback der Stakeholder geht. Die Abnahme wird daher häufig im Rahmen des Sprints umgesetzt.
Sprint-Retrospektive
Die Sprint-Retrospektive steht am Ende eines Sprints, das Scrum Team überprüft dabei seine bisherige Arbeitsweise um sie in Zukunft effizienter und effektiver zu machen. Es ist ein gemeinsames Ereignis des Scrum Teams, bei dem das Team seine Arbeitsweise offen und ehrlich überprüfen können soll. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können, das schließt auch Gefühle und Empfindungen ein. Daher dürfen Stakeholder nur auf Einladung dazukommen.
Die Verbesserungsmaßnahmen werden dokumentiert und geplant, das Ereignis dauert dabei maximal 45 Minuten je Sprint-Woche.
Product Backlog
Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt, es ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss seinen Ursprung im Product Backlog haben. Die Pflege ist in der Verantwortung des Product Owners, er entscheidet über die Reihenfolge beziehungsweise die Priorisierung der Einträge. Die Priorisierung erfolgt dabei unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit.
Das Product Backlog ist nicht vollständig – und erhebt auch nicht den Anspruch – und erhält zu Beginn die bekannten und am besten verstandenen Anforderungen. Diese Anforderungen sollten nicht technisch sondern fachlich und anwenderorientiert sein, beispielsweise durch die Formulierung als User Stories.
Das Product Backlog Refinement ist der fortlaufende Prozess, bei dem Product Owner und Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln.
Sprint Backlog
Ein Sprint Backlog ist der aktuelle Plan der für den Sprint zu erledigenden Aufgaben. Es umfasst Product Backlog-Einträge, die für den aktuellen Sprint ausgewählt wurden sowie die dafür nötigen Aufgaben. Es wird laufens nach der Erledigung einer (Teil-)Aufgabe von Team-Mitgliedern aktualisiert, es dient zur Übersicht des aktuellen Bearbeitungsstands.
Product Increment
Product Increments sind die Summe aller Product Backlog-Einträge, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden.
Wie viele andere Prozesse und Vorgehensmodelle bietet auch Scrum keine Erfolgsgarantie. Und laut Machern der Methode muss man sich darauf einstellen, dass die ursprünglichen Einschätzungen permanent über- oder untertroffen werden.
Auch entstehen häufig Rollenkonflikte, da die Selbstorganisation der Teams die Bereitschaft benötigt, dass sich die Mitglieder entsprechend ihrer Rollen in der Hierarchie anpassen, auch wenn diese außerhalb von Scrum andere sind.
Und auch juristische Faktoren sind zu erwägen: im Rahmen von Werkverträgen und vor dem Hintergrund des Produkthaftungsgesetzes kann die Anwendung von Scrum begrenzt sein.