Agiler mit Scrum

Rein ins Gedränge! Wir werfen einen Blick auf die agile Arbeitsmethode.

Rein ins Gedränge

Agiler mit Scrum

Das Wort Scrum (aus dem Englischen: das Gedränge) geistert schon seit einiger Zeit durch die Medien. Aber was sich genau dahinter verbirgt, weiß vielleicht nicht jeder. Gelegenheit für uns, das Thema näher zu beleuchten. Dass wir uns überhaupt damit beschäftigen, hängt mit den umfassenden Veränderungen der Arbeitswelt zusammen – auch bei uns. Aufgaben werden immer komplexer, und gleichzeitig schrumpfen die Zeitfenster. Deshalb müssen wir unsere Arbeitsweise so verändern, dass wir Schritt halten können. Ein wichtiger Begriff in diesem Zusammenhang lautet „agil“. Es gibt keine in Stein gemeißelten Projektanforderungen und -ziele mehr, vielmehr müssen sich alle Beteiligten ständig an veränderte Rahmenbedingungen anpassen. Herkömmliche Formen der Organisation stoßen damit an ihre Grenzen. Einen Weg, um agil zu arbeiten, bietet Scrum.

Ein Rahmen für komplexe Projekte

Zunächst einmal wollen wir ein Missverständnis ausräumen: Scrum ist nicht lediglich ein neuer Begriff für Projektmanagement. Vielmehr handelt es sich um ein komplettes Rahmenwerk. Scrum dient einerseits dazu, komplexe und adaptive Aufgabenstellungen angehen zu können. Andererseits soll Scrum dazu führen, die Selbstorganisation in Unternehmen zu etablieren. Scrum folgt dabei dem Grundsatz des Servant Leadership, also des selbstbestimmten Handelns der einzelnen Scrum-Rollen. Das Ziel heißt, bei hoher Unklarheit und Komplexität „auf Sicht“ zu managen. Es ist nicht mehr erforderlich, vor Projektbeginn einen detaillierten Projektplan zu entwerfen – und das wäre auch gar nicht möglich, weil sich die Anforderungen häufig ändern. Damit diese Art des Arbeitens überhaupt funktioniert, kommt es auf die engmaschige Kommunikation sämtlicher Beteiligten an. Scrum arbeitet mit Teams, die interdisziplinär zusammengesetzt sind. Ziel und Richtung sind vorgegeben, die Teams können den Weg dorthin jedoch weitgehend selbst gestalten.

Wie Scrum funktioniert

Scrum basiert auf der Theorie empirischer Prozesssteuerung. Das bedeutet, dass Wissen aus Erfahrung entsteht und Entscheidungen auf Basis des Bekannten getroffen werden. Damit dieser Ansatz funktioniert, bedarf es Transparenz, Überprüfung und Anpassung. So müssen die wesentlichen Aspekte des Prozesses für alle sichtbar sein, die das Ergebnis verantworten. Scrum-Anwender müssen ihre Teilprojekte und den Fortschritt regelmäßig mit den existierenden Zielen vergleichen, um unerwünschte Abweichungen zu erkennen. Weichen Aspekte des Prozesses von den akzeptablen Grenzwerten ab oder ist das resultierende Produkt so nicht akzeptabel, müssen der Prozess oder das zu bearbeitende Produkt angepasst werden. Der Hintergedanke ist ganz einfach: Ein funktionierendes Produkt ist wichtiger als eine dreihundertseitige Spezifikation.

Die Rollen bei Scrum

Laut dem offiziellen Scrum Guide gibt es bei Scrum drei Rollen, die alle miteinander selbstbestimmt arbeiten:

Der Product Owner

Der Product Owner ist für den wirtschaftlichen Erfolg des Projekts verantwortlich. Er erstellt die Produkteigenschaften und erläutert diese, damit am Ende eines jeden Sprints die nötigen, von ihm festgelegten Eigenschaften erfüllt werden. Zudem sorgt er für die Kommunikation zwischen Entwicklungsteam und den Stakeholdern. Der Product Owner ist für das Management des Product Backlogs verantwortlich. Handelt es sich um eine Dienstleistung, wird der Product Owner zum Business Owner.

Das Entwicklungsteam

Das Entwicklungsteam erstellt das Produkt und arbeitet nach den Standards und Priorisierungen des Product Owners. Jedoch organisiert und entscheidet es selbst, wie die jeweiligen Sprints umgesetzt werden. Laut Lehrbuch besteht das Entwicklungsteam aus Mitarbeitern, die sich ausschließlich um die Umsetzung des Projekts kümmern. Ein Team besteht aus mindestens drei und höchstens neun Mitgliedern aus den verschiedenen benötigten Fachrichtungen.

Der Scrum Master

Beim Scrum Master handelt es sich um eine professionell geschulte Person, die agile Teams „leiten“ kann – sie coacht. Er ist für das Verständnis und die Durchführung von Scrum verantwortlich. Seine Aufgabe ist es, dafür Sorge zu tragen, dass das Scrum Team die Theorie, die Praktiken und die Regeln einhält. Der Scrum Master zeigt dem Entwicklungsteam somit nur, wie es arbeiten kann. Ob das Entwicklungsteam dies dann umsetzt, liegt allein am Team.Nur wer Erfolge und Schwierigkeiten im Team offen anspricht, kann ein optimales Ergebnis erzielen. Es ist die Aufgabe des Scrum Master, die Zusammenarbeit so zu optimieren, dass der durch das Scrum Team generierte Wert maximiert wird. Ein guter Scrum Master kann zwei Projekte gleichzeitig managen – ein sehr guter eins.

Die Stakeholder

Stakeholder bei Scrum sind zum einen Kunden, denen das finale Produkt zur Anwendung übergeben wird, sowie sämtliche Interessengruppen, die durch die Umsetzung eines Projektes betroffen sind: Geldgeber, Mitarbeiter, Betriebsräte, eigenes Entwicklungsteam etc.
Stakeholder sind somit eine Anforderungsquelle und äußern dementsprechend auch regelmäßig Feedback an das Entwicklungsteam, um den Fortschritt der Anforderungen transparent verfolgen zu können. Die Priorisierung der Anforderungen erfolgt durch den Product Owner.

Die Umsetzung

Die Anforderungen (Requirements) werden ausschließlich vom Product Owner in einer Liste (Product Backlog) angelegt, erweitert und priorisiert. Die Product Backlog Items (PBI) geben grob vor, was passieren soll. Diese PBI werden vom Product Owner und dem Entwicklungsteam gemeinsam nach Aufwand geschätzt und priorisiert. Anhand dieser erarbeiteten Informationen kann der nächste Sprint (Sprint Planning) vorbereitet werden.
Die vorbereiteten PBIs (Wie soll es passieren?) werden nun zu Beginn eines jeden Sprints dem gesamten Entwicklungsteam vom Product Owner vorgestellt; anhand derselben wird das Sprintziel definiert.

Innerhalb eines Sprints finden täglich Meetings, sog. „Daily Scrums“ statt (max. 15 min), um mögliche Verzögerungen oder gar Stillstände im Projekt zu vermeiden. Nach Ablauf des Sprints (1 – 4 Wochen) werden im „Sprint Planning“ den Stakeholdern die Ergebnisse präsentiert, die ggf. noch ihre eigenen Impulse durch ihr Feedback in das Projekt einfließen lassen können.

Neben den fachlichen Anforderungen möchte sich das Scrum Team auch stets verbessern. Um mögliche Streitpunkte innerhalb eines Sprints zu vermeiden, finden dazu regelmäßige Termine zur „Sprint Retrospective“ statt. In dieser spricht das Entwicklungsteam ohne Führungskräfte über mögliche Probleme innerhalb des Projekts und über Verbesserungsmöglichkeiten in der eigenen Teamarbeit. Nach dem Abschluss einer jeden Sprint Review / Retrospective beginnt dieser Zyklus wieder von vorne. Somit wird gewährleistet, dass man sich dem Ziel langsam immer weiter annähert, um somit das perfekte Produkt zu erschaffen.

Weitere Informationen zu Scrum