Herkunft

Beschrieben wird Scrum im sogenannten Scrum Guide, der von Ken Schwaber und Jeff Sutherland kontinuierlich gepflegt wird und der frei zum Download in mehreren Sprachen zur Verfügung steht.

Schwaber und Sutherland entwickelten Scrum in den 1990er Jahren und publizierten das Scrum Framework 1995 in einem Konferenzbeitrag. 2002 erschien das Buch von Ken Schwaber und Mike Beedle "Agile Software Development with Scrum". Der erste Scrum Guide erschien 2010. Darin definieren die beiden Autoren Scrum als:

"A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."

("Ein Rahmenwerk, mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.")

Das Prinzip von Scrum: iterativ-inkrementelles Arbeiten

Scrum zählt zu den bekanntesten agilen Ansätzen. Auch wenn die Grundgedanken aus der Entwicklung mechatronischer Produkte stammen, war Scrum, wie es heute bekannt ist, zunächst darauf ausgerichtet, Software zu entwickeln. Ausgangspunkt für die Entwicklung von Scrum in den 1980er und 1990er Jahren war, dass eine Software-Entwicklung nicht von Anfang bis Ende präzise durchgeplant werden konnte.

Deshalb erfolgt die Produktentwicklung bei Scrum iterativ in Feedback-Schleifen von wenigen Wochen, den sog. Sprints. Bei jedem Sprint soll eine verwendbare Produktversion entstehen, das Inkrement – auch wenn dieses nur einen minimal zusätzlichen Funktionsumfang hat. Dieser iterativ-inkrementelle Ansatz erlaubt es dem Projektteam, auf Änderungen oder Probleme zu reagieren und Feedback von den Stakeholdern anhand eines funktionieren Produkts zu erhalten anstatt anhand von Dokumenten. Der Erfolg von Scrum bei der Software-Entwicklung führte dazu, dass mittlerweile auch andere Vorhaben mit Scrum angegangen werden, z.B. Hardware-Entwicklungen, Organisationsentwicklungen oder die Bereitstellung von Dienstleistungen.

Scrum und Projektmanagement

Scrum sieht keine Projekte vor. Mit der Projektbrille kann Scrum so interpretiert werden: Jeder Sprint ist ein in sich abgeschlossenes kleines Vorhaben. Es gibt Anforderungen, eine Planung, die Arbeit im Sprint, eine gemeinsame Begutachtung der Ergebnisse und ein “Lessons-Learned”. Die Stakeholder können nach jedem Sprint entscheiden, ob ein weiterer Sprint erfolgen soll oder nicht. Wenn sie mit dem aktuellen Inkrement zufrieden sind, ist die Arbeit am aktuellen Produkt beendet und das Team widmet sich anderen Aufgaben. Im Gegensatz zu klassischen Projekten bleibt das Team langfristig zusammen. Eine neue Zusammenstellung des Teams für das nächste Vorhaben würde alle Optimierungen im Team zunichtemachen. Ein stabiles Scrum Team kann sich über Jahre hinweg optimieren und vervielfacht in dieser Zeit oft seinen Durchsatz.

Wie starte ich mit Scrum?

Teams, die von klassischer Projektarbeit auf Scrum umstellen, müssen nicht nur Rollen, Artefakte und Meetings einführen. Der Wechsel vom klassischen zum agilen Projektmanagement geht auch mit großen Veränderungen in der Zusammenarbeit einher. Wie Sie den Wechsel trotzdem erfolgreich meistern, erklärt Stefan Willuda. Er schlägt einen Fahrplan vor, mit dem der Umstieg in einfachen Schritten gelingt.

Weiterlesen

Arbeiten mit Scrum

Basis von Scrum ist eine Produktvision der Stakeholder, an ihr richten sich alle weiteren Aktivitäten aus. In einem komplexen Umfeld kann nicht im Vorfeld definiert werden, wie das Produkt aussehen soll und wann das Entwicklungsvorhaben zu Ende sein wird. Anforderungen und Zeitpläne entstehen in dem Zuge, in dem das Scrum-Team mehr über den Kunden bzw. den Markt und die technische Machbarkeit lernt.

Product Owner (PO) und Product Backlog

Der Product Owner arbeitet auf Basis der Produktvision eng mit den Stakeholdern zusammen und versucht so herauszufinden, wie das gewünschte Produkt aussehen könnte und was die für die Stakeholder wertvollsten Eigenschaften sind. Die zu entwickelnden Funktionalitäten beschreibt der Product Owner im Product Backlog. Dieses ist ein eindeutig priorisierter Arbeitsvorrat für das Entwicklungsteam und wird von diesem konsequent in der vorgegebenen Reihenfolge abgearbeitet. Das Product Backlog muss nicht vollständig sein, um mit dem Vorhaben starten zu können. Ein Arbeitsvorrat für ein bis drei Sprints ist ausreichend. Der Product Owner füllt das Product Backlog nach und nach anhand des Stakeholder-Feedbacks auf.

Sprint Planning und Sprint Backlog

Zu Beginn eines Sprints findet das Sprint-Planning statt. Dabei präsentiert der Product Owner dem Entwicklungsteam das priorisierte Product Backlog. Das Entwicklungsteam entscheidet eigenständig, wie viele der am höchsten priorisierten Anforderungen es im anstehenden Sprint umsetzen kann, übernimmt diese in das Sprint Backlog und plant die Tätigkeiten im Sprint.

Das Sprint Backlog stellt einen für die Sprintlänge weitgehend stabilen Arbeitsvorrat dar, während das Product Backlog die Dynamik des Umfelds auffängt und diese somit vorübergehend vom Entwicklungsteam fernhält. Das Product Backlog kann jederzeit vom Product Owner verändert werden.

Entwicklungsarbeit, Daily Scrum und Abstimmung mit dem Product Owner

Das Entwicklungsteam arbeitet das Sprint Backlog selbstorganisiert ab. Innerhalb des Teams gibt es keine Rollen und keine Hierarchien – es trägt als Einheit die Verantwortung dafür, das nächste Produktinkrement innerhalb des Sprints in der vereinbarten Qualität fertigzustellen. Während des Sprints führt das Entwicklungsteam jeden Tag ein kurzes Meeting durch, den sog. Daily Scrum. Das ist ein Abstimmungs- und Planungsmeeting mit dem Zweck, die nächsten 24 Stunden Arbeit zu planen und den Fortschritt im Sprint zu überwachen.

Typisch für das agile Arbeiten ist die beständige Einbindung des Product Owners als Vertreter des Kunden und der Anwender. Dieses enge Feedback verhindert Reibung durch Unklarheiten oder Missverständnisse. Fertiggestellte Elemente des Backlogs werden noch während des Sprints getestet und mit dem Product Owner begutachtet.

Sprint Review

Im Sprint-Review am Ende des Sprints präsentiert das Entwicklungsteam dem Product Owner und ggf. anderen Stakeholdern das Inkrement, d.h. den Zuwachs der Funktionalität. Diese begutachten das Inkrement und erstellen bei Bedarf neue Einträge für das Product Backlog. Eine aus Projekten bekannte formale Abnahme gibt es nicht. Der Sprint wird auf keinen Fall verlängert. Das vollständig getestete und dokumentierte Inkrement zeigt auf, wo das Vorhaben im Moment steht. Dies ist der Ausgangspunkt für die Planung weiterer Schritte.

Sprint Retrospektive

Abschließend erfolgt am Ende eines Sprints die Sprint-Retrospektive, in der das gesamte Scrum-Team den Entwicklungsprozess sowie die Zusammenarbeit im vorangegangenen Sprint analysiert und ggf. Maßnahmen für die Verbesserungen der Arbeitsorganisation beschließt. Der Sprint endet mit dem Ende der Retrospektive. Direkt danach startet der nächste Sprint, wieder mit dem Sprint-Planning.

Rollen in Scrum

Der Scrum Guide definiert drei Rollen:

• Scrum Master
• Product Owner
• Entwicklungsteam

Alle drei Rollen zusammen ergeben das Scrum Team. Scrum Master und Product Owner werden mit genau einer Person besetzt. Das Entwicklungsteam sollte funktionsübergreifend zusammengesetzt sein, so dass es ohne äußere Hilfe die Elemente des Product Backlogs bearbeiten kann. Als typische Größe des Entwicklungsteams gibt der Scrum Guide drei bis neun Personen an.

Scrum Master

Der Scrum Master ist für die Implementierung von Scrum und die Einhaltung der Regeln im Team zuständig. Er ist verantwortlich dafür, möglichst gute Arbeitsbedingungen für das Team zu schaffen und unterstützt es bei der Selbstorganisation. Als Schnittstelle zur Organisation ist er dafür verantwortlich, das Teamumfeld zu verbessern, also die umgebende Organisation Schritt für Schritt zu verändern, damit das Scrum Team seiner Aufgabe besser nachkommen kann.

Prüfungsvorbereitung: So werden Sie Professional Scrum Master!

Sie möchten eine Weiterbildung machen und sich zum Scrum Master zertifizieren lassen? Wir haben für Sie Tipps, wie Sie sich erfolgreich und effizient auf die Online-Prüfung zum Scrum Master (PSM I) bei Scrum.org vorbereiten.

Weiterlesen

Product Owner

Der Product Owner verantwortet den geschäftlichen Erfolg des Produkts. Er ist verantwortlich für das das Product Backlog und somit für die Ausprägung des Produkts, Zeit, Kosten und – über die Priorisierung qualitätsrelevanter Aspekte – auch die Qualität. Er steht in Kontakt mit den Stakeholdern und gibt regelmäßig Feedback an das Team. Der Product Owner ist nicht in die technische Umsetzung involviert, er verantwortet das “Was”.

Entwicklungsteam

Das Entwicklungsteam entwickelt das Produkt und ist für die die technische Ausprägung und die Produktqualität verantwortlich. Es setzt die Anforderungen aus dem Product Backlog selbstorganisiert um. Das Entwicklungsteam verantwortet dadurch das “Wie”.

Ereignisse (Events) in Scrum

Charakteristisch für Scrum sind die fünf vorgegebenen Ereignisse (“Events”), die den zeitlichen Rahmen für die Arbeit mit Scrum aufspannen. Das übergeordnete Event ist der Sprint, der die anderen vier Events umfasst:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint-Retrospektive

Alle Events sind Time Boxes, d.h. sie haben fixierte Starttermine bzw. -zeiten und eine definierte maximale Dauer, die nicht überschritten wird. Sowohl im Sprint, wie auch in den vier anderen Events kann sich das Scrum-Team selbst optimieren und lernen, was möglich ist und was nicht. Die harte Taktung verringert die Planungskomplexität und schafft verlässliche Synchronisationspunkte mit Stakeholdern und der umgebenden Organisation.

Artefakte in Scrum

Der Scrum Guide definiert drei sog. Artefakte, die essentiellen Arbeitsergebnisse des Scrum Frameworks:

• Product Backlog
• Sprint Backlog
• Inkrement

Grenzen von Scrum

Die Anwendung von Scrum macht nicht in jedem Fall Sinn. Außerhalb von komplexen Umgebungen, also wenn Anforderungen und Technologien (das “Was” und das “Wie”) halbwegs klar sind, ist ein klassischer Projektmanagement-Ansatz ohne Lernschleifen effizienter. Im komplexen Umfeld würde ein plangetriebener Ansatz jedoch nicht die erwarteten Ergebnisse liefern.