mini|Scrum Agile Events – Überblick Scrum (englisch für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt.The State of Scrum: Benchmarks and Guidelines (PDF; englisch) – siehe auch ebenda auf Seite 10 (von 48); Scrum Alliance, Juni 2013 (abgerufen am 25. Dezember 2014) Es ist eine Umsetzung von Lean Development für das Projektmanagement.Mary Poppendieck, Tom Poppendieck: Lean Software Development: An Agile Toolkit. Addison-Wesley, Upper Saddle River 2003, ISBN 0-321-15078-3.Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, ISBN 978-3-9815837-5-5, S. 50–51. Der Begriff ist dem Rugby entlehnt und bezeichnet dort eine kreisförmige Aufstellung von zwei Mannschaften, die gemeinschaftlich versuchen, dem Gegner keinen Raum zu überlassen.Boris Gloger: Scrum Produkte zuverlässig und schnell entwickeln. Hanser, München 2013, S. 6.
Geschichte und Grundlegendes Die Anfänge von Scrum lassen sich auf Ikujirō Nonaka und Hirotaka TakeuchiThe New New Product Development Game. Cb.hbsp.harvard.edu, 1. Januar 1986.I. Nonaka, H. Takeuchi: The Knowledge-Creating Company. Oxford University Press, 1995.Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms. 1998. zurückverfolgen. Inspiriert von deren Erkenntnissen schuf Jeff Sutherland 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. 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. Auf der OOPSLA 1995 wurde dann der erste Konferenzbeitrag über Scrum veröffentlicht.Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 5. Auflage. Carl Hanser, München 2016, S. 21. Darin schrieb Schwaber: . Der Begriff Scrum stammt aber von Nonaka und Takeuchi, die damit das Gedränge ( ) 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.How did Scrum originate? (englisch) – abgerufen am 25. Mai 2018.
2002 veröffentlichte Ken Schwaber mit Mike Beedle, einem der ersten Scrum-Anwender, mit das erste Buch über Scrum, 2004 folgte Schwabers . 2007 erschien schließlich Ken Schwabers drittes Buch . Darin geht es nicht mehr bloß um die Einführung von Scrum in Software-Entwicklungsteams, sondern um die Ausweitung auf das gesamte Unternehmen.Ken Schwaber: Scrum im Unternehmen. Microsoft Press, Unterschleißheim 2008, S. XI–XII. Spätestens seit der ersten jährlichen Umfrage von VersionOne (2006) ist Scrum die gängigste agile Methode.1st Annual State of Agile™ Report bis 13th Annual State of Agile™ Report
Parallelen zu Scrum finden sich in der schlanken Produktion (englisch ), 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 der, heute überholten, „alten Schule“ 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 sei subjektiv und intuitiv und enthalte Realitäts- und Zukunftsvorstellungen. 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.Ikujiro Nonaka, Hirotaka Takeuchi: A Theory of the Firm’s Knowledge-Creation Dynamics. In: Alfred Chandler u. a. (Hrsg.): The Dynamic Firm. The Role of Technology, Strategy, Organization, and Regions. Oxford University Press, Oxford 2008, ISBN 0-19-829052-7, S. 215–216.
Scrum stellt einen bewussten Kontrast zur, heute weitgehend überholten, „traditionellen“ Befehls-und-Kontroll-Organisation dar, in der, möglichst wenig qualifizierte, Mitarbeitende möglichst detaillierte Arbeitsanweisungen vom qualifizierten Management erhalten. Stattdessen setzt Scrum auf hochqualifizierte, interdisziplinäre Teams. Diese bekommen zwar klare Zielvorgaben, sind jedoch eigenverantwortlich für die Umsetzung. Dieser Ansatz schafft den nötigen Freiraum, damit Teams ihr Fachwissen und ihre Kreativität selbstbestimmt entfalten können – statt starr vorgegebene Prozesse abzuarbeiten.Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 5. Auflage. Carl Hanser, München 2016, S. 31–45.
Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:Scrum Code of Ethics
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 aus nur wenigen Regeln. Diese beschreiben vier Ereignisse, drei Artefakte und drei Rollen (Verantwortlichkeiten), die den Kern (englisch ) ausmachen. Die Regeln sind im beschrieben; es gibt eine weitere Kurzdarstellung im Agile Atlas.Der Agile Atlas – Core Scrum – Improuv (improuv.com), mit Verweis auf ein 12-seitiges PDF (≈ 120 KB); Übersetzung vom Januar 2013; abgerufen am 25. Dezember 2016. 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.Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, ISBN 978-3-9815837-5-5, S. 112–113.
Die empirische Verbesserung fußt auf drei Säulen:
Transparenz Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar aufgezeigt. Überprüfung Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet. 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 (). Im Anschluss an den Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 12.
Scrum ist für Teams mit einer Größe von drei bis neun Entwicklern konzipiert.Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 7. Größere Projekte benötigen ein weitergehendes oder alternatives Framework, das die Koordination mehrerer Teams organisiert. Wenn diese Koordination den gleichen Prinzipien wie Scrum folgt, spricht man von Skalierungs-Frameworks oder agilen Projektmanagementmethoden.Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development). Addison-Wesley, Boston 2010.Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
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.Scrum Alliance: V 2012.12.13, S. 4–6.
Verschiedene Autoren haben argumentiert, dass weitere Rollen einbezogen werden sollten, wenn man Scrum als Management-Framework verstehen will.Boris Gloger, Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 4. Auflage, 2013. 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 Skalierungs-Frameworks. Diese Frameworks definieren weitere Rollen, die in großen agilen Entwicklungsorganisationen benötigt werden.Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development). Addison-Wesley, Boston 2010.Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
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 er Eigenschaften, Auslieferungszeitpunkte und Kosten.Scrum Alliance: V 2012.12.13, S. 4.