Anzeige
Anzeige
UX & Design
Artikel merken

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.

10 Min. Lesezeit
Anzeige
Anzeige

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

Anzeige
Anzeige

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.

Anzeige
Anzeige
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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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:

Anzeige
Anzeige
  • 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.

Anzeige
Anzeige

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.

Will das Team einen Sprint erfolgreich abschließen, muss es diesen zuvor vernünftig planen. Die Timebox für das Sprint Planning beträgt dabei fünf Prozent der Sprintlänge. Bei einem Sprint mit einer Dauer von zwei Wochen sind das vier Stunden. Zu den Ergebnissen eines Sprint-Planning-Meetings gehören stets:

  • Commitment: Woran arbeitet das Team in diesem Sprint und was hat es am Ende des Sprints zu liefern? Dazu gehört auch das Aufbrechen der Anforderungen für diesen Sprint in konkrete kleine Arbeitspakete.
  • Geschätzte Anforderungsliste für die Release-Planung
  • Zeit und Ort für das Sprint Review und die Retrospektive

Auch Sprint Review und die Retrospektive sind zeitlich begrenzt. Zusammen sollte diese Timebox ebenfalls nicht länger als fünf Prozent der Sprintlänge dauern. Das Daily Scrum dauert nicht länger als 15 Minuten. Ein Fehler, den Jörg gemacht hat und den man häufig antrifft, ist folgender: Das Daily Scrum ist kein Report an den Projektleiter oder den Scrum Master. Es ist ein Update der einzelnen Teammitglieder für das gesamte Team. Es sollte täglich zur gleichen Zeit am gleichen Ort stattfinden und jedes Teammitglied sollte folgende Fragen für sich beantworten:

Anzeige
Anzeige
  • Was habe ich gemacht?
  • Was mache ich als nächstes?
  • Was hindert mich?

Wenn das Team mit diesen Fragen durch ist, hat es sich bewährt, wenn sich das Team eine letzte Frage stellt:

  • Sind wir in der Lage, das Commitment zu halten?

In allen Meetings findet man häufig ausschweifende Diskussionen oder Themen, die eigentlich nicht dahin gehören. Hier muss der Scrum Master darauf achten, dass der Fokus nicht verloren geht. Diese Diskussionen und Gespräche sind zwar wichtig und man möchte diese auch nicht unterbinden, aber vielleicht kann man diese auch nach einem der Meetings fortsetzen, damit nur die Personen daran beteiligt sind, die es auch betrifft.

Jörg hat auch zu den aktuellen Problemen Hilfestellung in der lokalen Community bekommen und setzt diese Dinge sofort um. Zum Verwalten der Anforderungen und zur Arbeit mit dem Commitment besorgt Jörg eine entsprechende Softwarelösung, die Scrum perfekt unterstützen soll. Am Ende des Sprints sieht es ja schon mal ein wenig besser aus, aber so richtig rund läuft es immer noch nicht, und das trotz der neu gekauften Software.

Anzeige
Anzeige

Scrum funktioniert auch analog

Häufig kauft ein Unternehmen schon bei der Entscheidung für Scrum eine Softwarelösung, um das Vorgehen zu unterstützen. Man braucht derartige Lösungen aber nur dann, wenn es sich um Arbeit mit verteilten Teams handelt. Ansonsten reichen auch einfache Office-Lösungen zur Verwaltung von Anforderungen. Ein weiteres Argument gegen das verfrühte Anschaffen der Softwarelösung ist, dass eigentlich noch niemand weiß, wobei diese Software denn eigentlich unterstützen soll. Somit sei jedem Team nahegelegt, zuerst mit Papier und Stift zu arbeiten, um zu planen. Ein probates Mittel ist außerdem das Taskboard.

Ein Taskboard ist in den meisten Fällen eine Art Whiteboard oder
Metaplanwand. Auf dem Taskboard findet man eine Tabelle, der man den
aktuellen Sprintstatus entnehmen kann: Welche Arbeitspakete sind noch
offen, was wird zurzeit bearbeitet und was ist fertig? Der so genannte
Burndown-Chart visualisiert das und befindet sich ebenfalls auf dem
Taskboard. Der Burndown-Chart liefert schon sehr früh Anhaltspunkte
dafür, ob das Team sein Commitment halten kann oder nicht.

Einen weiteren Bereich sollte man für die so genannten Impediments reservieren. Diesen Bereich sollten alle Teammitglieder für die Dinge nutzen, die sie aktuell behindern. Das Taskboard sollte spätestens im
Daily Scrum aktualisiert werden. Man kann bei vielen Teams einige Verhaltensweisen beobachten, die sich eher nachteilig auswirken. Dazu gehören Multitasking, Doppelarbeit und das Ignorieren der Impediments.

Beim Multitasking übernimmt eine Person einen ganzen Haufen an Arbeitspaketen. Das führt dazu, dass es (a) nicht möglich ist, den genauen Status des Projekts zu erkennen, (b) anderen schwer fällt, hier zu unterstützen und (c) ein hohes Risiko entsteht, da ein Fehlen dieser Person den Sprint-Erfolg stark gefährden kann.

Doppelarbeit entsteht hingegen immer dann, wenn die Teammitglieder die Status der einzelnen Arbeitspakete nicht aktualisieren. Das kann dazu führen, dass mehrere Personen eine Aufgabe bearbeiten, ohne dass diese das wissen. Dadurch vergeudet das Team viel Zeit.

Man redet nicht gern über Probleme. Bleiben allerdings die Impediments auf dem Taskboard leer, ignoriert man eines der
Erfolgsgeheimnisse der agilen Vorgehensweise: die Transparenz. Spricht man
Probleme nicht aus, kann man diese
auch nicht lösen. Je eher
jedes Teammitglied Probleme anspricht, um so eher kann das Team eine Lösung finden.

So könnte ein mögliches Taskboard aussehen: Ganz links sind die Anforderungen (hier als User Stories formuliert), daneben kommen die einzelnen Arbeitspakete. Es fehlen hier noch der Burndown-Chart und der Bereich für die Impediments.

So könnte ein mögliches Taskboard aussehen: Ganz links sind die Anforderungen (hier als User Stories formuliert), daneben kommen die einzelnen Arbeitspakete. Es fehlen hier noch der Burndown-Chart und der Bereich für die Impediments.

Hätte Jörg das vorher gewusst, hätten er und sein Unternehmen viel Geld sparen können. Außerdem hätte Jörg wahrscheinlich bei der oben beschriebenen Vorgehensweise so manche Klippe im agilen Prozess umschiffen können.

Fazit

In diesem Artikel wurde auf einige Bereiche eingegangen, die man häufig bei der Einführung agiler Methoden (hier Scrum) unterschätzt. Eine weitere Hilfestellung ist die Scrum Master Checklist [5], die klar macht, dass der Scrum Master weit mehr zu tun hat, als hier beschrieben und in den meisten Unternehmen gelebt wird.

In der nächsten t3n-Ausgabe begleiten wir Jörg weiter, um zu sehen, welchen Problemen er sich noch auf dem Weg zum perfekten Scrum Master stellen muss.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

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

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige