Das könnte dich auch interessieren

Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 23

Scrum in der Praxis: Projekte agil durchführen

Das Vorgehen bei IT-Projekten befindet sich im Wandel. Spätestens mit dem Erfolg von Scrum haben sich zahlreiche Agenturen und IT-Firmen das Attribut „agil“ auf die Fahne geschrieben. Doch viele dieser vermeintlich agil agierenden Unternehmen können ihr Versprechen nicht wirklich einlösen. Oftmals hakt es in Teams und Projekten bei der Einführung und Umsetzung agiler Arbeitsweisen. Dieser Artikel zeigt, worum es bei Scrum eigentlich geht und wie man agil plant und entwickelt.

Es ist Montag. In einem Projektteam eines fiktiven Unternehmens arbeitet Jörg als Projektmanager. Jörg hat soeben mit seinem Teamleiter Marc über die Ziel- und Leistungsvereinbarungen des kommenden Geschäftsjahres gesprochen. Zum einen hat das Unternehmen erkannt, dass es von seinen Zweijahres-Releasezyklen weg muss, zum anderen will man sich flexibler am Markt orientieren. Dies sollen alle Team- und Projektleiter umsetzen. Marc hat schon einiges von diesem Scrum gehört und so kommen Marc und Jörg zu der Übereinkunft, dass das Unternehmen zukünftig Scrum einsetzen soll. Jörg ist für die Einführung in seinem Team zuständig. Jörg hat sich bisher nicht mit dem Thema „agiles Projektmanagement“ auseinandersetzen müssen. Er bemüht kurzum eine bekannte Suchmaschine und schon der erste Treffer wirkt durchaus vielversprechend: der ScrumGuide [1]. Jörg notiert sich die wichtigsten Begriffe und Features von Scrum, um sich in das Thema einzuarbeiten.

Scrum im Überblick

Scrum ist eine Methode für die agile Durchführung von Projekten. Dabei beschreibt diese Methode einen interaktiven und inkrementellen Prozess für das Organisieren von Teams und das Entwickeln von Produkten. Scrum soll dabei helfen, Tasks schneller und auch besser zu erledigen. Die Methode setzt auf Eigenmotivation von Teams, die sich aus dem Fakt ergibt, dass Teammitglieder selbst entscheiden, wann und wie sie einzelne Aufgaben ausführen. Während des Scrum-Prozesses setzt das Team Kundenanforderungen durch schrittweise Priorisierung schneller um als bei Projekten, die nicht auf Scrum setzen.

Die Basis des agilen Ansatzes ist demnach die Maßgabe, etwas Schritt für Schritt zu entwickeln. Meist setzt man als erstes auf die wichtigsten Features. Scrum baut auf drei Säulen auf: Transparenz, Inspektion und Adaption. Transparenz soll für die Sichtbarkeit aller Prozessaspekte sorgen, die das Ergebnis beeinflussen. Mit Inspektion ist gemeint, dass alle Prozessaspekte so häufig untersucht werden, dass man inakzeptable Abweichungen entdecken kann. Stellt das Team fest, dass Prozessaspekte abweichen, kommt die dritte Säule von Scrum zum Tragen. Dann gilt es, entweder den Prozess selbst oder die Arbeitsgegenstände zu adaptieren und anzupassen.

Kleines Scrum-Lexikon
Scrum-Team Scrum setzt auf drei Rollen: Team, Scrum Master, Product Owner.
Team Die Mitglieder des Teams sind bei Scrum für die Umsetzung aller geplanter Features verantwortlich.
Scrum Master Der Scrum Master ist dafür verantwortlich, dass der Prozess verstanden und eingehalten wird. Er kümmert sich auch um die Bedürfnisse des Teams.
Product Owner Der Product Owner ist dafür verantwortlich, den Return on Invest zu optimieren. Er ist für den Erfolg des Projekts verantwortlich.
Produkt-Backlog Priorisierte Liste von allem, was in dem Produkt benötigt werden könnte.
Sprint-Backlog Liste mit Aufgaben, die dazu dient, aus dem Produkt-Backlog für einen Sprint ein potenziell auslieferbares Produkt-Inkrement zu machen.
Timeboxen Timeboxen sind feste Zeitabschnitte und dienen zur Herstellung von Regelmäßigkeit: Release-Planning-Meeting, Sprint-Planning-Meeting, Sprint, Daily Scrum, Sprint Review und Sprint-Retrospektive.
Sprint Zentrales Element des Entwicklungszyklus. Vereinfacht ist ein Sprint die Umsetzung einer Iteration.
Release Planning Meeting Hier legt man das Ziel für den Release, die am höchsten priorisierten Backlog-Einträge, Hauptrisiken und generelle Features und Funktionalitäten fest.
Sprint-Planning-Meeting Beschreibt die Iterationsplanung.
Daily Scrum Jedes Scrum-Team trifft sich täglich zu einem kurzen Inspektions- und Adaptionsmeeting. Jedes Teammitglied erläutert, was es seit dem letzten Meeting erreicht hat, was es bis zum nächsten Meeting plant und welche Hindernisse bestehen.
Sprint Review Findet am Ende eines Sprints statt, um die Arbeitsergebnisse zu begutachten.
Sprint-Retrospektive Findet zwischen dem Sprint Review und dem nächsten Sprint-Planning-Meeting statt. Die Sprint-Retrospektive inspiziert, wie der abgelaufene Sprint in Bezug auf Menschen, Beziehungen, Prozess und Werkzeuge gelaufen ist.
Definition of Done Am Ende jedes Sprints sollte ein potenziell auslieferungsfähiges Produkt stehen. Definition of Done beschreibt was getan werden muss, um eine Aufgabe als erledigt zu betrachten.

So viel zur Theorie. Nun muss Jörg seine Erkenntnisse in die Praxis umsetzen.

Aller Anfang ist schwer

Aber wo fängt man an? So schwer kann das ja eigentlich nicht sein, denkt sich Jörg. Immerhin umfasst der Scrum Guide nur wenige Seiten und die wichtigsten Punkte hat er schließlich auch noch mal selbst zusammengefasst. Flexibilität lautet das Ziel und da passt ja im Grunde der iterative Ansatz von Scrum hervorragend! Allerdings müssen diese ganzen anderen Sachen wie noch mehr Meetings oder neue Rollen von Teammitgliedern ja nun wirklich nicht sein.

In vielen Fällen möchten Unternehmen zwar Scrum einführen, gehen aber davon aus, dass das Lesen eines Buchs ausreicht, um die grundlegenden Gedanken zu verstehen. Doch obwohl die Grundlagen relativ einfach sind, ist die disziplinierte Umsetzung meist schwieriger als gedacht. Man sollte sich zumindest nach anderen agilen Praktikern umsehen, um Gedanken dazu auszutauschen.

Auf in Richtung Ziel

Es sind nun etwa zwei Monate vergangen und Marc erkundigt sich bei Jörg, wie es denn um die Umsetzung von Scrum bestellt ist. Jörg ist nicht ganz glücklich mit der Situation. Die Sprints sind zwar da, aber nicht wirklich greifbar. Jörg zeigt Marc seine Übersicht der Sprints:

Sprint Länge [Wochen] Fokus
#1 3 Konzeption
#2 2 Architekturentwurf
#3 Läuft noch Umsetzung UI

Ein Besuch bei der lokalen User Group [2] bringt ein wenig mehr Licht ins Dunkel. Jörg hat eine Gruppe von Praktikern gefunden und tauscht bei einem der Treffen Erfahrungen aus. Jörg scheint mit seinem Problem nicht allein zu sein: Er erfährt, dass die Sprintlängen konsequent auf gleicher Länge gehalten werden sollten, um die einzelnen Sprints untereinander vergleichen zu können. Nur so kann man die Produktivität auch messen.

Auch die Messung des Fortschritts ist bei Jörg anscheinend suboptimal gelaufen. Ein Mitglied der User Group erklärt ihm, dass man den Fortschritt bei Scrum entgegen traditionellem Vorgehen nicht in abgeschlossenen Phasen misst, sondern in der Anzahl produktionsreifer, hochqualitativer, getesteter Funktionen.

Wie Software schrittweise entsteht

Einer der Werte des Agilen Manifests [3] leitet sich aus dem Fakt ab, dass die Offenheit gegenüber Änderungen höher bewertet wird als das strikte Befolgen eines Plans. Doch was bedeutet das konkret? Man geht in Softwareprojekten davon aus, dass das, was zu Anfang des Projekts an Anforderungen da ist, nicht fix ist. Vielmehr wird sich der Leistungsumfang über die Projektlaufzeit verändern und sich den Gegebenheiten anpassen. Aus diesem Grunde muss man die Software beziehungsweise die Entwicklung selbiger so flexibel wie möglich halten.

Aus dem eXtremeProgramming ist YAGNI („You ain't gonna need it“) bekannt. Grob gesagt heißt das, dass man Dinge nur dann entwickeln sollte, wenn klar ist, dass man sie auch tatsächlich braucht. Somit entwickelt sich das Produkt inkrementell und nur im nötigen Rahmen. Daraus ergeben sich Produkte, die schlank sowie leichter wart- und erweiterbar sind. Die Entwickler können sich dadurch auf das Wesentliche konzentrieren und verschwenden ihre Zeit nicht auf Dinge, die vielleicht gar nicht benötigt werden.

Jörg nimmt die Hinweise der anderen erfahrenen Praktiker aus dem Treffen der lokalen User Group mit und setzt die Länge eines Sprints auf zwei Wochen fest. Noch mal im Scrum Guide nachgeschlagen, ergeben für Jörg nun auch die zusätzlichen Meetings einen Sinn:

  • Sprint-Planung
  • Daily Scrum
  • Sprint Review

Wenn Sprints immer die gleiche Länge haben, sind Start- und Endzeitpunkt auch immer gleich. Jörg wurde außerdem noch ein kleines Büchlein mit Praxiserfahrungen [4] genannt, aus dem er die Idee mitgenommen hat, Sprints am Montag zu starten und am Freitag zu beenden. So hat das Team noch ein wenig Erholungspause zwischen den Sprints.

Das Review am Ende eines Sprints ist für Jörg allerdings eher enttäuschend, denn das Team ist meist nicht in der Lage, ihm einen entsprechenden Fortschritt zu präsentieren. Auch die Fortschrittmessung in geleisteten Mannstunden bringt Jörg nicht wirklich voran, da sich die entsprechenden Schätzungen zu sehr ändern und nur schwer vergleichbar sind.

Jörg hat zwar einige Ideen gut aufgenommen und umgesetzt. Bei anderen Dingen besteht allerdings noch viel Verbesserungspotenzial.

Das Geheimnis erfolgreicher Sprints

Wie schon erwähnt, sollten Sprints immer die gleiche Dauer haben, damit diese untereinander vergleichbar werden und somit eine Verbesserung des Teams ersichtlich wird. Man bezeichnet einen Sprint auch als „timeboxed“. Viele Teams scheitern am Timeboxing. Timeboxing ist aber eigentlich nichts anderes, als dass man sich für eine bestimmte Tätigkeit einen festen zeitlichen Rahmen setzt und diesen um nichts in der Welt überzieht. Eher sollte man sich am Ende fragen, ob eine weitere Timebox nötig ist und welche Länge diese dann haben sollte. In Scrum ist im Grunde alles timeboxed (siehe das Kleine Scrum-Lexikon). Timeboxen helfen allen Beteiligten, fokussiert an einem konkreten Thema zu arbeiten.

Links und Literatur

  1. The Scrum Guide
  2. Scrum User Groups
  3. Das agile Manifest
  4. Scrum and XP from the trenches
  5. Michael James' Scrum Master Checklist

Finde einen Job, den du liebst

Schreib den ersten Kommentar!

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen