Scrum


« Zurück zum Lexikon

Scrum (aus englisch scrum für „ Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt. Es ist eine Umsetzung von Lean Development für das Projektmanagement.

Scrum (aus englisch scrum für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt.[1] Es ist eine Umsetzung von Lean Development für das Projektmanagement.[2][3]

Geschichte und Grundlegendes

Die Anfänge von Scrum lassen sich auf Ikujirō Nonaka und Hirotaka Takeuchi[4][5][6] zurückverfolgen. Inspiriert von deren Erkenntnissen schuf Jeff Sutherland[7] eine neue Rolle für die Projektleiter. Diese wurden zu Teammitgliedern, und ihre Rolle war eher die eines Moderators als die eines Managers. Zusammen mit Ken Schwaber formalisierte er Scrum ab 1993.[8] Dabei wurde Scrum durch die Theory of Constraints und das Toyota 3M Modell (Muda, Mura, Muri) beeinflusst, die Idee eines Daily Meetings stammt von James Coplien.[9][10] Auf der OOPSLA 1995 wurde dann der erste Konferenzbeitrag über Scrum veröffentlicht. Darin schrieb Schwaber: „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.“[11] Der Begriff Scrum stammt aber von Nonaka und Takeuchi, die damit das Gedränge (englisch scrum) im Rugby als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams beschrieben. Diese Teams arbeiten als kleine, selbst-organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen.[12]

2002 veröffentlichte Ken Schwaber mit Mike Beedle, einem der ersten Scrum-Anwender, mit Agile Software Development with Scrum das erste Buch über Scrum, 2004 folgte Schwabers Agile Project Management with Scrum.[13] 2007 erschien schließlich Ken Schwabers drittes Buch The Enterprise and Scrum. Darin geht es nicht mehr bloß um die Einführung von Scrum in Software-Entwicklungsteams, sondern um die Ausweitung auf das gesamte Unternehmen.[14] Spätestens seit der ersten jährlichen Umfrage von VersionOne (2006) ist Scrum die gängigste agile Methode.[15]

Parallelen zu Scrum finden sich in der schlanken Produktion (englisch lean production), die ihren Ursprung in japanischen Unternehmen hat. Sie strebt eine bessere Wertschöpfung durch verstärkte Zusammenarbeit an. Nonaka und Takeuchi führen den Erfolg solcher Unternehmen auf ein gelungenes Wissensmanagement zurück. Im westlichen Verständnis sei die Ressource Wissen auf Worte und Zahlen begrenzt. Wissen kann nach diesem Verständnis erworben oder antrainiert werden. Japanische Firmen hingegen sehen in dieser Art von Wissen nur die Spitze eines Eisbergs. Für sie ist Wissen in erster Linie implizit („tacit“). Dieses implizite Wissen ist subjektiv und intuitiv, es enthält unser Bild der Realität und unsere Vision für die Zukunft. Während explizites Wissen sich leicht darstellen und verarbeiten lässt, ist dies bei implizitem Wissen deutlich schwerer. Unternehmen wie Toyota oder Canon profitieren vom impliziten Wissen ihrer Mitarbeiter, indem sie hohen Wert auf die Interaktion zwischen ihren Mitarbeitern legen.[16]

Scrum lässt sich in diesem Zusammenhang als Gegenentwurf zur Befehls-und-Kontroll-Organisation verstehen, in der Mitarbeiter möglichst genaue Arbeitsanweisungen erhalten. Stattdessen baut Scrum auf hochqualifizierte, interdisziplinär besetzte Entwicklungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Dadurch bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen.[17]

Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:[18]

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

Scrum besteht aus nur wenigen Regeln. Diese beschreiben vier Ereignisse, drei Artefakte und drei Rollen (Verantwortlichkeiten), die den Kern (englisch core) ausmachen. Die Regeln sind im Scrum Guide beschrieben, es gibt eine weitere Kurzdarstellung im Agile Atlas.[19][20] Das Scrum-Framework muss durch Techniken für die Umsetzung der Ereignisse, Artefakte und Rollen konkretisiert werden, um Scrum tatsächlich umsetzen zu können. Der Kern von Scrum wurde von den Umsetzungstechniken getrennt, um einerseits die zentralen Elemente und Wirkungsmechanismen klar zu definieren, andererseits um große Freiheiten bei der individuellen Ausgestaltung zu lassen.

Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er 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 der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert.[21]

Die empirische Verbesserung fußt auf drei Säulen:[20]

  1. Transparenz: Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten.
  2. Überprüfung: Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet.
  3. Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich und detailliert angepasst. Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe Bestandteile, die Inkremente.

Ziel ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte entsprechend einer formulierten Vision. Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Lasten- und Pflichtenhefte. In Scrum werden die Anforderungen in Form von Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen ist das Product Backlog. Diese Anforderungen werden Stück für Stück in ein bis vier Wochen langen Intervallen, sogenannten Sprints umgesetzt. Am Ende eines Sprints steht bei Scrum die Lieferung eines fertigen Teilprodukts (das Product Increment). Das Produktinkrement sollte in einem Zustand sein, dass es an den Kunden ausgeliefert werden kann (potentially shippable product). Im Anschluss an den Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.[22]

Scrum ist für Teams mit einer Größe von drei bis neun Entwicklern konzipiert.[23] Größere Projekte benötigen ein weitergehendes Framework, das die Koordination mehrerer Teams organisiert. Wenn diese Koordination den gleichen Prinzipien wie Scrum folgt, dann spricht man von Scaled Agile Frameworks.[24][25]

Verantwortlichkeiten

Das Scrum Framework kennt drei Führungsverantwortungen: Product Owner, Entwickler und Scrum Master. Die Gesamtheit dieser Verantwortlichkeiten wird als Scrum-Team bezeichnet. Ein Scrum-Team tritt mit den Beteiligten in Kontakt, den sogenannten Stakeholdern. Fortschritt und Zwischenergebnisse sind für alle Stakeholder transparent. Stakeholder dürfen bei den meisten Ereignissen zuhören.[26][20]

Verschiedene Autoren haben argumentiert, dass weitere Rollen einbezogen werden sollten, wenn man Scrum als Management-Framework verstehen will.[27] Da sich Scrum jedoch auf das Team fokussiert und kein Management-Framework ist, sind diese Rollen nicht in das Scrum Framework aufgenommen worden. Die drei Verantwortlichkeiten haben sich als ausreichend für die Organisation eines Teams erwiesen. Für die Organisation größerer Einheiten und mehrerer Teams gibt es spezielle Frameworks wie das Scaled Agile Framework[28] oder Large Scale Scrum.[29] Diese Frameworks definieren weitere Rollen, die in großen agilen Entwicklungsorganisationen benötigt werden.

Product Owner

Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er gestaltet das Produkt mit dem Ziel, seinen Nutzen zu maximieren. Der Nutzen könnte sich beispielsweise am Umsatz des Unternehmens orientieren. Er erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften, und er urteilt darüber, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden. Er ist eine Person, kein Komitee. Ihm allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. So balanciert sie Eigenschaften, Auslieferungszeitpunkte und Kosten.[30][31]

Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt ein. Der Product Owner ordnet, priorisiert, detailliert und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement.[32]

Als Produktverantwortlicher hält der Product Owner regelmäßig Rücksprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Dabei muss er die Interessen und Anforderungen unterschiedlicher Stakeholder verstehen und abwägen.

In der Praxis erhalten Product Owner häufig nicht die Vollmacht, die notwendigen Entscheidungen verbindlich zu treffen – abweichend von der Rollenkompetenz, die in Scrum eigentlich vorgesehen ist. Häufig werden Product Owner auch mit fremden Aufgaben überlastet.[33]

Entwickler

Die Entwickler sind für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem tragen sie die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Das Scrum-Team organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es Backlogeinträge umzusetzen hat.[20]

Ein Scrum-Team sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Deshalb ist eine interdisziplinäre Besetzung des Scrum-Teams wichtig, z. B. mit Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte. Gute und schlechte Ergebnisse werden nie auf einzelne Teammitglieder, sondern immer auf das Scrum-