Scrum ist seit Jahren in aller Munde und sicherlich vielen Lesern dieser Seite bereits bekannt. Es gibt durch die enorme Verbreitung im Einsatz und mangels einer DIN-Norm gegenüber seiner ursprünglichen Form zahlreiche und teilweise auch inkonsistente Interpretationen von Scrum. Gerade deshalb möchten wir hier in kompakter Form unser Verständnis der ursprünglichen Fassung des Frameworks und seiner möglichen Verwendung vorstellen:

Scrum ist keine Projektmanagement-Methode, sondern ein Methoden-Framework zur Beantwortung der Frage, mit welchem minimalen Set an Zuständigkeiten, Arbeitsweisen und Ergebnissen ein kleines Team die Steuerung seiner (Entwicklungs-) Arbeit leisten könnte. Das bedeutet insbesondere, dass Sie viele Antworten auf viele Fragen zu einer „klassischen“ Vorstellung von Projektabwicklung hier nicht beantwortet finden werden.

Scrum eignet sich dank seiner häufigen Feedback-Schleifen besonders für hohe Prognosesicherheit und Risikokontrolle in der Abwicklung komplexer Projekte und der Entwicklung komplexer Produkte unter Verzicht auf einen zu Beginn festgelegten Funktionsumfang und mit einem kleinen Entwicklerteam.

Das kleine 3 mal 3 des ursprünglichen Scrums in 10 Minuten

Die Kernidee: Der Sprint

In Scrum dreht sich alles um Sprints. Jeder Sprint hat stets die zu Projektbeginn festgelegte Dauer von ein bis vier Wochen. Die Grundidee seiner Länge ist der Kompromiss aus einem möglichst langen störungsfreien Zeitraum für das Entwicklungsteam und einer möglichst kurzen Unterbrechung des Ideenflusses des Product Owners.

3 Rollen: Das Scrum-Team

Ein Scrum-Team besteht aus dem Product Owner, dem Entwicklungsteam und einem Scrum Master.

small-team_am_klotz2Das Entwicklungsteam ist selbstorganisiert und entscheidet ohne Projektleiter und äußeren Einfluss selbst, wie die Arbeit erledigt wird. Maximale Produktivität, Flexibilität und Verantwortung sind das Ergebnis.

small-product_ownerDer Product Owner ist die Rolle, die alle Schnittstellen zu weiteren Kunden / Anforderungsträgern / Stakeholdern bildet.  Er liefert dem Scrum-Team eine priorisierte Liste von Anforderungen zu.

small-scrum_masterDie Aufgabe des Scrum Masters ist es, dem Team ungestörte Arbeit zu ermöglichen und die Einhaltung der Scrum-Regeln zu überwachen. Der Scrum Master interagiert insofern auch mit dem produktverantwortlichen Product Owner, welcher in den Planungsphasen die Anforderungen an das Team heranträgt, und achtet auf dessen Zusammenarbeit mit dem Entwicklungsteam.

3 Zeremonien: Die Beschreibung des Ablaufs von Scrum

small-sprint-planning Am Anfang eines jeden Sprints wird ein Sprint Planning Meeting abgehalten. In diesem befragt das Entwicklerteam den Product Owner so lange zu dessen Anforderungen höchster Priorität, bis klar wird, wieviele davon das Entwicklerteam zur Realisierung in den neuen Sprint aufzunehmen in der Lage ist. Der Product Owner wird auch zu möglichen Kostenersparnissen bei Änderung seiner Prioritäten beraten. Das Ergebnis ist die Liste der für den Sprint eingeplanten Anforderungen. 

small-daily_scrumr

Die zweite Zermonie ist das tägliche Abhalten des Daily Scrum. Dies ist ein ca. 15-minütiges Standup Meeting (Meeting im Stehen) des Entwicklerteams, bei dem jedes Teammitglied den vergangenen Tag resümiert, mögliche Arbeitshemmnisse benennt und ausstehende Aufgaben formuliert. Jede eventuell entstehende Diskussion wird vom Scrum Master verhindert, um die Meetingzeit im Plenum zu minimeren.

Am Ende eines jsmall-sprint_revieweden Sprints findet das Sprint Review statt. Hier werden die Sprint-Ergebnisse vom Entwicklerteam präsentiert und vom Product Owner entweder abgenommen oder verworfen. Weitere anwesende Stakeholder liefern wertvolles zusätzliches Feedback. Der Scrum Master hält dieses für den Product Owner fest und moderiert im Anschluss noch eine Retrospektive des Entwicklungsteams zur Entdeckung von Optimierungspotentialen.

 

3 Artefakte: Braucht es mehr Management-Papier?

Die ersten beiden Artefakte kennen Sie nun bereits: Die priorisierte aktuelle Gesamt-Liste der Anforderungen des Product Owners wird Product Backlog genannt. Die Liste der Anforderungen, die vom Entwicklungsteam für im nächsten Sprint realisierbar gehalten werden, heißt Sprint Backlog. Zu guter Letzt werden sogenannte Burn Down Charts zur Visualisierung des Arbeitsfortschritts während eines Sprints genutzt. Dies ist beispielweise die täglich über die Zeitachse aufgetragene Anzahl aller noch unerledigter Aufgaben.

scrum-overview

Scrum mit Braintime umsetzen?

Auch wenn dieser kurze Überblick natürlich eine hanebüchene Verkürzung des Wissens zu Scrum darstellt, ist das Grundwissen zu Scrum schnell erlernt. Das Meistern im Alltag ist meist der spannendere Teil.

  • Wie findet man heraus, ob Scrum für ein Projektverhaben / Team geeignet ist?
  • Wie führt man am besten agile Methoden wie Scrum in der Praxis ein?
  • Kann man Scrum in großen Projekten mit Hunderten Entwicklern einsetzen?

Wenn Sie möchten, beantworten wir diese und viele andere Fragen mit Ihnen gemeinsam.

Scrum mit Braintime