Scrum – Was ist das?

Ursprung und Besonderheiten der Projektmanagement-Methode und Einordnung in den Bildungskontext

Miriam Lerch

Die Entstehung von Scrum

Scrum ist ein Rahmenwerk zur Bearbeitung von Projekten, welches seinen Ursprung im wirtschaftlichen Umfeld hat. Ken Schwaber und Jeff Sutherland gelten als die Urväter von Scrum, auch wenn die Anfänge sich auf die Wissenschaftler Ikujirō Nonaka und Hirotaka Takeuchi zurückführen lassen. Im Jahr 1986 schrieben sie den Artikel “The New Product Development Game” im Harvard Business Review, in dem sie erklärten, dass Projekte einen neuen Ansatz brauchen:

“Der traditionelle sequentielle oder “Staffellauf”-Ansatz bei der Produktentwicklung […] steht im Widerspruch zu den Zielen der maximalen Geschwindigkeit und Flexibilität. Ein ganzheitlicher oder “Rugby”-Ansatz – bei dem ein Team versucht, den Abschnitt als eine Einheit zu gehen, wobei der Ball vor- und zurückgegeben wird – erfüllt die heutigen wettbewerbsorientierten Anforderungen besser.”

(Nonaka; Takeuchi, 1986)

Scrum hat demnach eine enge Analogie zu Rugby. Im Rugby ist Scrum (engl. Gedränge) eine Formation, bei der sich das Team aneinander klammert um sich gemeinsam als eine Formation bewegen zu können. Dieses Team arbeitet als kleine, selbstorganisierte Einheit und bekommt von außen nur eine Richtung vorgegeben, bestimmt aber selbst die Taktik, wie es sein gemeinsames Ziel erreicht. Der Begriff “Sprint”, der einen Lieferzyklus beschreibt, ist ebenfalls eine Analogie zu Rugby.

Scrum kann definiert werden als ein Rahmenwerk, innerhalb dessen Menschenkomplexe, adaptive Aufgabenstellungen angehen könnenund durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit demhöchst-möglichen Wert auszuliefern.

Scrum besteht aus nur wenigen Regeln und orientiert sich an Werten und Prinzipien der agilen Softwareentwicklung:

Werte	Prinzipien
Selbstverpflichtung Sei bereit, dich einem Ziel zu verpflichten	Selbstorganisation Agile Teams haben keinen Teamleiter, sondern organisieren sich selbst
Fokus Fokussiere dein Handeln auf deine Zusagen	Regelmäßige Lieferung Planung kurzer Zeitspannen, nach denen ein Ergebnis an die Stakeholder geliefert wird
Mut Erzähle die Wahrheit über den Projektfortschritt	Inspect & Adapt Frühe Überprüfung der Ergebnisse und Anpassung der Planung und Vorgehensweise
Feedback Sei offen für Feedback und passe dein Vorgehen an	Bereichsübergreifende Zusammenarbeit Alle Beteiligten kommen regelmäßig zum Austausch zusammen
Offenheit Liefere Informationen zeitnah und transparent	Direkte Kommunikation Face-to-Face und synchron
Respekt Respektiere die Unter-schiedlichkeit im Team

Das agile Manifest

Aus diesen Werten und Prinzipien entstand das agile Manifest, welches Ken Schwaber und Jeff Sutherland im Jahr 2001 veröffentlichten:

Scrum bietet als Rahmenwerk klare Regeln und Strukturen. Diese beschreiben vier Ereignisse, drei Artefakte und drei Rollen, die den Kern ausmachen. Die Regeln sind im Scrum Guide beschrieben (Schwaber; Sutherland, 2017). Gleichzeitig ist das Framework offen für individuelle Herangehensweisen. Die Ausgestaltung durch spezielle Methoden, Techniken und Zeitspannen bleibt dem Team überlassen.

Scrum auf einen Blick 

In Scrum werden die Anforderungen eines Produkts in Form von Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen nennt man Product Backlog. Diese Anforderungen werden nach und nach in 1-4 Wochen langen Zyklen, sogenannten Sprints umgesetzt. Am Ende eines Sprints steht bei Scrum die Lieferung einer fertigen Teilfunktion / eines Teilprodukts, das Produkt-Inkrement. Das Produkt-Inkrement sollte getestet und in einem Zustand sein, sodass es an den Kunden ausgeliefert werden kann. Im Anschluss an den Zyklus werden das Teilprodukt, Anforderungen und Vorgehen überprüft (durch Tests und Retrospektiven) und im nächsten Sprint weiterentwickelt.

Die Rollen im Scrum

Scrum definiert drei Rollen. Den Product-Owner, den Scrum-Master und das Entwicklungsteam.

Product Owner

Der Product Owner (abgekürzt PO)ist eine Person, kein Komitee und für das Produkt und die Rendite verantwortlich. Er sammelt, beschreibt und priorisiert die Anforderungen des Kunden. Der PO hält außerdem regelmäßig mit den Stakeholdern Kontakt. Er trifft Entscheidungen über das Produkt, seine Merkmale und Reihenfolge der Implementierung. Somit maximiert er den Wert des Produktes.

Scrum Master

Der Scrum Master (abgekürzt SM) sorgt für den reibungs-losen Ablauf in der Produktentwicklung. Er stellt sicher, dass die Scrum-Regeln eingehalten werden und sorgt für eine möglichst gute Arbeitsumgebung. Er ist dafür verantwortlich, dass Hindernisse – auch Impediments genannt – aus dem Weg geräumt werden. Der SM unterstützt das Team dabei eigenständig zu arbeiten und hilft ihm so bei der Weiterentwicklung.

Entwicklungsteam

Das Entwicklungsteam (abgekürzt ET) arbeitet selbstorganisiert und liefert das Produkt. Es besteht aus mindestens drei Personen. Das Entwicklungsteam entscheidet wie ein Inkrement (= einzelner Bestandteil / Teilprodukt) umgesetzt wird. Es ist verantwortlich für alle Schätzungen und prognostiziert, welche Product-Backlog-Einträge es während des Sprints liefern wird.

Stakeholder

Die Stakeholder gehören nicht direkt zum Scrum Team, haben aber Einfluss auf das zu liefernde Produkt. Zu den Stakeholdern gehören Kunden, Anwender und das Management.

Scrum-Ereignisse

Im Scrum gibt es festgelegte Ereignisse um eine Regel-mäßigkeit im Entwicklungsprozess herzustellen und Transparenz an kritischen Stellen zu ermöglichen. Alle Ereignisse sind zeitlich beschränkt (Time-Boxing)

Sprint Planning: Planung der Arbeit im Sprint

In der Sprint-Planung I stellt der Product Owner dem Entwicklungsteam die im Product Backlog festgehaltenen Anforderungen in der zuvor priorisierten Reihenfolge vor. Anschließend bespricht der PO mit dem Entwicklungsteam das zu erreichende Sprint-Ziel. Das Team wählt die Backlog-Einträge aus dem Product-Backlog aus, die es liefern soll und überführt diese ins Sprint-Backlog.

In der Sprint-Planung II plant das Entwicklungsteam, welche Aufgaben / Tasks zur Lieferung der ausgewählten Einträge erforderlich sind.

Daily-Scrum: Austausch und Tagesplanung

Das Daily Scrum ist eine kurze 15-minütige Besprechung des gesamten Entwicklungsteams, um den Fortschritt zu überprüfen und den Tag zu planen. Meistens findet es am Morgen eines Arbeitstages statt. Im Daily Scrum sollten von jedem Einzelnen folgende Informationen ausgetauscht werden:

• Was habe ich seit dem letzten Daily erreicht?
• Was nehme ich mir für heute vor?
• Welche Hindernisse behindern meine Arbeit?

Sprint-Review: Optimierung des Produkts

Das Entwicklungsteam präsentiert im Review die Ergebnisse seiner Arbeit mit Bezug auf das Sprint-Ziel. Das Scrum-Team und die Stakeholder besprechen die Ergebnisse und was als nächstes zu tun ist. Der PO nimmt das Inkrement ab. Das Ergebnis des Sprint Review ist das vom Product Owner notierte Feedback der Stakeholder, welches auch die Grundlage für die Anpassung des Product Backlog bildet.

Sprint-Retrospektive: Optimierung der Arbeitsweise

Die Sprint-Retrospektive ist das letzte Ereignis eines Sprints und dient der Rückschau. Das Scrum-Team überprüft offen und konstruktiv seine bisherige Arbeitsweise, um sie für die Zukunft zu optimieren. Der SM unterstützt das Team dabei Verbesserungsmaßnahmen zu identifizieren, die im nächsten Sprint umgesetzt werden. Die Sprint-Retrospektive ist ein wichtiges Momentum der Team(weiter)entwicklung.

Scrum-Artefakte

Scrum beinhaltet mehrere wichtige Elemente, die hier näher beschrieben sind.

Product Backlog

Das Product Backlog ist die priorisierte Auflistung aller Anforderungen an das Produkt. Es ist dynamisch und wird ständig weiterentwickelt, um die identifizierten Anforderungen an das Produkt festzuhalten. Der PO ist für die Pflege des Product Backlogs verantwortlich. Er verantwortet die Reihenfolge bzw. Priorisierung der Einträge.

Sprint Backlog

Das Sprint Backlog enthält für den Sprint ausgewählte Anforderungen. Es besteht aus Einträgen, die das Team als Prognose der möglichen Funktionalität des nächsten Inkrements ausgewählt hat. Zur Erreichung des Sprint-Ziels plant das Team alle erforderlichen Aufgaben.

Inkrement

Das Inkrement ist die Summe aller Backlog-Einträge, die während des aktuellen Sprints fertig gestellt wurden. Am Ende des Sprints muss das neue Inkrement in einem nutzbaren Zustand sein und der “Definition of Done” entsprechen.

Definition of Done

Unter dieser Wortkombination (abgekürzt DoD) verbirgt sich ein gemeinsames Verständnis im Team, unter welchen Bedingungen ein Inkrement als “fertig” bezeichnet wird. Die DoD beinhaltet gewöhnlich Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen. Mit zunehmender Erfahrung des Scrum Teams entwickelt sich die Definition of Done weiter. Interessant ist, dass im Scrum die Definition of Done ein reiner Teamprozess ist, wofür eine gelungene interne Diskussion und schlussendlich ein Konsens notwendig ist.

Weitere Scrum-Begriffe und Techniken

Im Scrum-Framework gibt es noch weitere Begrifflichkeiten, die erwähnt werden, deren Zusammenhänge hier nicht näher vertieft werden sollen. Dazu gehört u.a.:

• Epic und User-Storys (spielen im Backlog eine Rolle)
• Tasks und Taskboard
• Backlog-Refinement
• Planning Poker
• Burn-Down-Chart
• Definition of ready

Einordnung in den Bildungskontext

Schaut man sich das Rahmenwerk Scrum an, dann lässt sich – mit dem Ursprung in der Softwareentwicklung – der techni-sche Bezug nicht leugnen. Dennoch gibt es mittlerweile eine Vielzahl an Projekten, die sich Teilaspekte von Scrum zu Nutze machen und diese in andere, nicht-technische Kontexte der Zusammenarbeit übertragen. Allen voran das agile Manifest und seine Werte lassen sich sehr gut als Vorlage für die Zusammenarbeit von Teams in ganz verschiedenen Lebensbereichen übertragen (von der Business-Unit, über die Vorstandsarbeit, bis zur Arbeit im Kita-Elternbeirat).

Teilaspekte von Scrum findet man auch in anderen Kontexten, so ist eine vereinfachte Variante des Sprint-Backlog als Übersicht über den Projektverlauf das Kanban-Boardmit seiner Dreiteilung in “Aufgaben”, “in Arbeit” und “Erledigt”. Oder aber die Rollen Product-Owner, Scrum-Master und Entwicklungsteam werden in andere Kontexte der Zusammenarbeit übertragen.

Scrum = Teamwork

Ein wichtiger, nicht zu leugnender Aspekt ist, dass die Projekt-managementmethode Scrum für die Produktentwicklung im Team entwickelt wurde, während im Bildungsbereich allerdings meist der Lernerfolg der Einzelperson im Vordergrund steht. Möchte man das Erfolgsmodell des agilen Arbeitens (z.B. mit Scrum) also beispielsweise auf den schulischen Unterricht übertragen, so sollte hier ebenfalls die Gruppenleistung im Vordergrund stehen. Hierbei würden vor allem vier wichtige Zukunftskompetenzen gefördert werden, nämlich Kommunikation, Kollaboration, Kreativität und kritisches Denken.

Scrum könnte für Schüler-Projektarbeiten in Gruppen zu bestimmten Themen und Zielstellungen durchgeführt werden. Hierfür lohnt es sich sogar, ebenfalls in einem “Produkt” als Ergebnis der Projektarbeit zu denken.

Eine solch enge Zusammenarbeit im Team, wie beim Scrum erfordert hohe soziale Kompetenzen und gegenseitiges Vertrauen und Verständnis für die Unterschiedlichkeit und Einzigartigkeit der Personen. Die betreuende Lehrkraft sollte SchülerInnen hierbei besonders unterstützen, und eventuell entsprechende Teams mit Teambuilding-Maßnahmen vorbereiten um die nötige Reife zu erlangen. Gleichzeitig kann das Erleben der Zusammenarbeit im Scrum-Team diesen Reifeprozess fördern und einzigartige Momente des Zusammenhalts und der positiven Energie ermöglichen, die SchülerInnen gemeinsam lernen und wachsen lassen.

Welche Rollen bekommen Lehrkraft und SchülerInnen?

Logischerweise übernehmen die SchülerInnen die Arbeit des Entwicklungsteams und sind damit gleichzeitig gefordert selbstorganisiert, iterativ, mit klaren Zeitbeschränkungen (Time-Boxing) und ergebnisorientiert zu arbeiten. 

Doch welche Rolle kommt der Lehrkraft zu? Einige sehen sie als Product Owner, d.h. die Lehrkraft dient als Bezugsperson zu den Stakeholdern und zum Kunden (= Lehrplan oder Projektpartner?), wirkt an der Projektvision gestaltend mit und priorisiert die einzelnen Anforderungen an das Ergebnis. 

Ich persönlich, sehe die Lehrkraft allerdings eher in der Rolle des Scrum Masters, der im wirtschaftlichen Umfeld auch oft als “servant leader” (also dienender Führer) bezeichnet wird. Warum? Weil ein SM immer aus dieser dienenden Haltung heraus agiert. Er fragt sich:

• Was braucht das Team, damit es seine Arbeit gut erledigen kann?
• Welche Rahmenbedingungen braucht es für ein erfolgreiches Projekt?
• Wie kann ich einzelne Teammitglieder gezielt unterstützen?

Betrachten wir den SM unter diesen Gesichtspunkten, so erkenne ich hier sehr viel Ähnlichkeit zum “Lerncoach” oder “Lernbegleiter”, der ähnliche Aufgaben im Lernprozess übernimmt.

Fazit: Scrum in der Schule? Unbedingt!

Abschließend lässt sich sagen, dass Scrum – als Projektarbeits-methode im Bildungskontext angewandt – eine hervorragende Möglichkeit bietet, um gemeinsames Zusammenarbeiten, komplexes Problemlösen und kreatives Denken zu fördern. Zudem bieten die Scrum-Ereignisse (Planning, Review und Retrospektive) auf den Projektalltag umgemünzt eine sehr gute Gelegenheit zusammen über sich als Team zu reflektieren, sich gegenseitig besser kennen-zulernen und wertzuschätzen. Mit Blick auf die Arbeitswelt von Morgen würden dadurch wichtige Grundpfeiler für ein gelingendes, kokreatives Miteinander gelegt und sich vom Einzelkämpfertum und Wettbewerb, was bisher an Schulen gefördert wurde, ein Stück weit verabschiedet.

Literatur

• Nonaka, I; Takeuchi, H (1986): The new new product development game. Harvard Business Review 64. S. 137-146
• Schwaber, K.; Sutherland, J. und weitere Autoren (2001): Manifest für Agile Softwareentwicklung. Abrufbar unter: https://agilemanifesto.org/iso/de/manifesto.html 
• Schwaber, K.; Sutherland, J. (2017): The Scrum Guide™. Aktuelle Version abrufbar unter: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf 
• Oesterreich, Bernd (2018): Warum ich es gewagt finde, Scrum zur Organisationsentwicklung einzusetzen. Blogeintrag. Abrufbar unter: https://next-u.de/2018/warum-ich-es-gewagt-finde-scrum-zur-organisationsentwicklung-einzusetzen/

---

Zum nächsten Kapitel…