Agiles Projektmanagement mit Scrum: was bedeutet das?

Was ist agiles Projektmanagement?

Agiles Projektmanagement ist zuallererst ein anderer Weg, die Arbeit an einem Projekt zu strukturieren und zu organisieren. „Scrum“ ist dann nur eine bestimmte Methode, um diese Arbeitsweise umzusetzen.

Entstanden ist das Konzept Anfang der 1990er Jahre im Bereich der Softwareentwicklung, anschließend wurde es kontinuierlich weiterentwickelt. Inzwischen werden agile Methoden auch erfolgreich verwendet, um interdisziplinäre Digitalprojekte durchzuführen, die Konzeption, Design und Softwareentwicklung miteinander verbinden.

Zentrales Merkmal von agil durchgeführten Projekten ist es, dass die Arbeit in kleine Einheiten zerlegt wird; die einzelnen Arbeitseinheiten werden dann von einem Team in ständiger Interaktion abgearbeitet. Die Arbeit ist dabei so organisiert, dass die Zusammenarbeit und Interaktion zwischen den beteiligten Personen möglichst reibungslos funktionieren kann: Die agile Arbeitsweise basiert wesentlich darauf, die Beteiligung aller einzelnen Personen wertzuschätzen. Zugleich werden in der Zusammenarbeit die gemeinsamen Ziele kontinuierlich überprüft und angepasst.

Rigide Pflichtenhefte spielen in diesem Rahmen keine Rolle mehr; anstatt sich um ausführliche Dokumentation zu kümmern, soll das Team zügig passgenaue Software entwickeln, soll die geplante Website noch im Prozess ihrer Entstehung an sich wandelnde Anforderungen angepasst werden können.

Im „Manifest für agile Softwareentwicklung“, in dem die Kernprinzipien dieser Vorgehensweise festgeschrieben sind, lässt sich das gut nachlesen. Aus dem Text spricht sehr deutlich der Wunsch der Softwareentwickler, nicht nur als ausführende Sklaven technischer Anforderungen wahrgenommen zu werden. Stattdessen sollen alle am Projekt Beteiligten Verantwortung füreinander und für das gemeinsame Ziel annehmen und übernehmen. Dieses Ziel lässt sich, so ist das agile Selbstverständnis, über offene, transparente und klare Kommunikation besser erreichen als durch rigide Prozesse oder Strukturen.

In diesem Text wollen wir konkret vorstellen

• wie ein agiles Projekt abläuft,
• wie es sich von den sonst üblichen Arbeitsverfahren unterscheidet, und
• wie ein Projekt abläuft, wenn es mit der sogenannten „Scrum“-Methode durchgeführt wird.

Klassisches Vorgehen: der „Wasserfall“

Die bisher meist übliche Art, digitale Projekte mit Agenturen gemeinsam durchzuführen, ist das sogenannte „Wasserfall“-Modell. Es heißt so, weil eine Menge Sachen auf einmal passieren und der ganze Prozess kaum noch aufgehalten werden kann.

Oder anders gesagt: Bevor Sie ein Projekt beauftragen – eine neue App für die Kunden oder Außendienstler, ein Tool für den internen Gebrauch –, schaffen sie im übertragenen Sinne erst einmal jede Menge Wasser auf einen Berg hinauf.

Nehmen wir einmal an, Sie wollen Ihre Website neu aufsetzen. Sie setzen sich mit allen Leuten zusammen, die über diesen Relaunch mitentscheiden können und müssen, und tragen alles zusammen, was Ihnen wichtig ist. Was soll die Website können? Welche Funktionen und Elemente, die jetzt dort zu sehen sind, sollen auch in der neuen Fassung zu finden sein? Wonach suchen die Nutzer typischerweise?

Aus all ihren Antworten entwickeln Sie gemeinsam ein ausführliches Briefing, mit dem sie an Ihre Agentur herantreten: Sie frieren gewissermaßen alle ihre Ideen zu großen Eisquadern und schaffen die nach oben auf den Berg. Die Agentur hat noch einmal jede Menge Fragen, sie schicken weitere Eismengen. Währenddessen schmilzt das Wasser da oben in eine Mulde hinein und bildet einen großen See von aufgestauten Anforderungen.

Die Wehre werden erst dann geöffnet, wenn Sie final den Auftrag erteilen. Nun aber fließt das Wasser hinab, erst als Konzeptbächlein, das zum Designflüsschen wird, bevor es sich schließlich in einen Strom von Softwareentwicklung verbreitert.

Zwischendurch können Sie immer noch einmal kleine Korrekturen vornehmen, aber sobald das Wasser abwärts fließt, ist es fast nicht mehr möglich, seine Richtung noch einmal abzuändern. (Genau genommen ist also das Bild des „Wasserfalls“ nicht ganz korrekt – es geht eher um einen großen Strom. Seine Unaufhaltsamkeit ist aber vergleichbar.)

„Don’t go chasing waterfalls“

Wenn der „Wasserfall“ erst einmal plätschert, ist er eine relativ bequeme Sache. Beim Auftraggeber wartet man in Ruhe (oder mit leichter Nervosität) das Ergebnis ab. Zugleich kann die Agentur in Ruhe arbeiten (schmort aber eben auch nur im eigenen Saft).

Nicht selten jedoch gibt es dann bei der Vorstellung von ersten Ergebnissen viel Platz für Enttäuschung:

1. Probleme und Missverständnisse werden erst spät erkannt. Je weiter die Arbeiten am Produkt schon fortgeschritten sind, umso größer wird der Aufwand, die entsprechenden Änderungen vorzunehmen. Dabei ist es ja nur menschlich, dass es zu solchen Missverständnissen kommt! Kein Briefing ist so präzise, dass es keinen Raum für Interpretation mehr ließe. Und kein Briefing ist so allumfassend, dass es wirklich jedes Detail beschreibt.
2. Änderungen am Projekt lassen sich nur mit deutlichem Mehraufwand noch unterbringen. Das wird inzwischen insbesondere deshalb zum Problem, weil digitale Projekte vom ersten Briefing bis zur Fertigstellung inzwischen leicht ein bis zwei Jahre oder länger dauern können. In der Zeitrechnung des Internets sind das Ewigkeiten, in der sich an den technischen Möglichkeiten viel wandeln kann. Womöglich haben sich aber auch Ihre Anforderungen verändert – und sei es nur, weil ein Mitbewerber sich anders auf dem Markt positioniert hat.

Agil heißt beweglich

Welche Änderungen, welche konkreten Eigenheiten aber bringt nun agiles Projektmanagement mit Scrum, die konkret diese Probleme beseitigen?

Das erste wesentliche Merkmal versteckt sich im Namen: Der Begriff „Scrum“ kommt aus der Sportart Rugby und beschreibt den Moment, in dem viele Spieler zusammenstehen, weil das Spiel nach einer Unterbrechung von neuem beginnt. Die Profisportler stehen allerdings keineswegs planlos in einem Haufen zusammen! Nicht von ungefähr wird der Sportbegriff im Deutschen als „Angeordnetes Gedränge“ übersetzt.

All hands on deck: Alle gemeinsam

Genau eine solche Anordnung versteckt sich auch hinter der Scrum-Methode: Hier arbeiten alle Teammitglieder gemeinsam, und was vielleicht aus den Augenwinkeln wie Gedrängel aussieht, ist in Wahrheit ein hochgradig strukturierter und geordneter Prozess.

Dieser Prozess hat das Ziel, dass wirklich alle nicht nur zusammen, sondern gemeinsam arbeiten – insbesondere also, dass nicht einzelne Teile wie Konzept, Design und Technik strikt nacheinander abgearbeitet werden, wie es bei der Wasserfall-Methode oft geschieht. Stattdessen arbeiten die unterschiedlichen Disziplinen gemeinsam und gleichzeitig an der Lösung einzelner Probleme.

Dieses interdisziplinäre Arbeiten vermeidet zum Beispiel,

• dass Vorschläge konzipiert werden, die technisch zu aufwändig oder gar unmöglich sind, oder
• dass technische Lösungen vorgeschlagen werden, die völlig an den Bedürfnissen der Nutzer vorbei gedacht sind.

Schrittweise arbeiten: die Sprints und das Produktinkrement

Ein Scrum-Projekt ist in fest definierte Zeiteinheiten aufgeteilt, sogenannte „Sprints“, die in der Regel jeweils zwischen einer und vier Wochen dauern. Am Ende jedes Sprints steht ein fertiges und funktionsfähiges (Teil-)Produkt (ein sogenanntes Produktinkrement), dass dem Auftraggeber (in diesem Fall also Ihnen) vorgestellt und von allen Beteiligten getestet werden kann.

Dadurch ist nach jedem Sprint ein Zwischenstand zu sehen. An jedem Zwischenstand lässt sich entscheiden: Funktioniert das so, wie es soll? Was muss noch verbessert werden? Was muss doch ganz anders gemacht werden?

Jeder neue Sprint setzt dann auf die Entwicklungen des vorherigen auf, entwickelt diese weiter bzw. verbessert diese. Auf diese Weise werden sehr früh nicht nur Fortschritte, sondern auch Herausforderungen sichtbar. Auch Fehlentwicklungen lassen sich frühzeitig revidieren – in Design und Technik gleichermaßen.

Gleichzeitig erlauben es die engen Zeiträume von Versuch und Irrtum, von Test und Rückkopplung, sich bei der Umsetzung auch einmal an kleinen Experimenten zu versuchen und womöglich an diesen zu scheitern. Kleine Experimente führen auch nur zu kleinem Scheitern. Anders als bei „Wasserfall“-Projekten werden Fehlentwicklungen eben schnell sichtbar und können ohne ausufernde zusätzliche Aufwände auch wieder korrigiert werden.

Empirisch, inkrementell, iterativ

Für diese Eigenheiten des Scrum-Modells haben sich die Begriffe empirisch, inkrementell und iterativ durchgesetzt. Sie beschreiben den Kern dieses Verfahrens sehr gut: 

• Empirisch: Scrum arbeitet mit nachweislich funktionierenden Zwischenschritten, also mit Ergebnissen (und auch mit Methoden), die ihre Funktionsfähigkeit bereits erwiesen haben. So wird vermieden, dass erst am Ende eines langen Entwicklungszyklus‘ festgestellt wird, dass eine gewählte Technologie gar nicht brauchbar ist.
• Inkrementell: Am Ende jedes Schritts steht ein fertiges Teilprodukt oder Inkrement, das jeweils für sich funktionsfähig ist (oder, in der etwas komplexeren Praxis, zumindest sein sollte). So wird die Spannbreite der Teilprodukte nach und nach erweitert, bis das gewünschte Ziel erreicht ist.
• Iterativ: Nicht jedes Teilprodukt ist am Ende eines Sprints so, wie es schließlich sein soll. Verbesserungen werden in einem iterativen Prozess schrittweise durchgeführt, auch hier wieder so, dass am Ende jedes Sprints ein funktionsfähiger Prototyp steht – bis schließlich alle notwendigen oder gewünschten Verbesserungen umgesetzt sind.

Der konkrete Prozess, in dem das umgesetzt wird, wirkt zwar auf den ersten Blick komplex, ist aber, wie schon beschrieben, hoch strukturiert und vor allem klar definiert.

Eines bleibt aber wichtig: Bei allem Klein-Klein in der Durchführung einzelner Sprints (wie sie weiter unten noch beschrieben werden) muss der klare Blick auf das große Ziel am Ende immer vorhanden sein. Und dafür braucht es eine Vision.

Von der Vision zum Projekt

Der entscheidende Perspektivwechsel liegt beim agilen Projektmanagement darin, das Projekt nicht schon am Anfang in seiner fertigen, finalen Form zu denken. Stattdessen steht am Anfang eines agilen Projektes eine „Vision“, manchmal auch „Big Picture“ genannt – eine klare, in wenigen Sätzen umrissene Vorstellung davon, was das Endprodukt, zum Beispiel Ihre neue Website, erreichen soll.

Die „Vision“ meint also nicht vage Hoffnungen oder blumige Formulierungen, sondern ganz im Gegenteil: eine stark komprimierte Beschreibung, die das zentrale Ziel des Projektes erfasst, um so eine Perspektive zu formulieren, an der sich das gesamte Projekt orientieren kann. 

Eine solche Vision wird erarbeitet, bevor mit der konkreten Arbeit am Projekt begonnen wird. Für den Relaunch Ihrer Website würde es sinnvollerweise zum Beispiel einen oder mehrere Workshops mit allen Stakeholdern in Ihrem Unternehmen geben.

Von einem konventionellen Briefing unterscheidet sich die Vision darin, dass sie wirklich nur den Kern der Zielsetzung beschreibt, aber nicht auf einzelne Anforderungen eingeht. Natürlich würden Anforderungen und Wünsche an die fertige Website in den Workshops schon zur Sprache kommen. Es wäre verfehlt, diese Wortmeldungen zu ignorieren! Stattdessen können sie bereits frühzeitig formuliert und in sogenannte User Stories überführt werden.

User Stories

User Stories sind die Basis für alle Arbeiten in einem Scrum-Projekt. Sie bestehen im Kern aus einem Satz, der sich auf folgendes Schema eindampfen lässt:

Person A möchte (auf der Website, mit der App…) Sache B machen, um Ding C zu erreichen.

Dabei kann A für ein Projekt eine „Buyer Persona“ sein, wie sie vom Marketing zuvor beschrieben wurde, und die auf der Website eine bestimmte Information sucht. A ist möglicherweise aber auch ein Mitglied Ihres Unternehmens, das zum Beispiel als Datenbank-Administrator eine bestimmte technische Anforderung hat – oder die Marketing-Mitarbeiterin, die eine bestimmte Funktion auf der neuen Website benötigt.
Entscheidend ist hierbei, dass die User Stories nur einen Anwendungsfall beschreiben, aber keine konkrete Lösungsweise vorgeben – diese wird später auf Basis der User Stories (und immer mit Blick auf sowohl die Vision als auch die anderen User Stories) vom Team selbst ausgearbeitet.

Product Backlog

Auf diese Weise entwickelt sich aus zahlreichen User Stories schließlich das sogenannte Product Backlog. Da diese Sammlung von User Stories (einzelne Elemente werden “Items” genannt) zunächst keine spezifische Ordnung hat, müssen diese bewertet und priorisiert werden. Das Product Backlog wird so letztlich zu dem Ort, an dem durch die Bedürfnisse der Nutzer indirekt die Eigenschaften des Produktes beschrieben werden.

Während der Umsetzung können sich Anforderungen und Bedürfnisse noch ändern, auch können Erfahrungen aus den Sprints zu Änderungen führen; das Product Backlog ist deshalb keineswegs statisch, sondern verändert sich fortwährend, wird ergänzt und weiter ausgearbeitet.

Die User Stories, die sich im Product Backlog befinden, haben idealerweise keine Abhängigkeiten voneinander, sollten sich also unabhängig voneinander realisieren lassen. In der Praxis gibt es natürlich immer wieder Schritte, die zuerst umgesetzt werden müssen, bevor dann bestimmte weitere Maßnahmen folgen können.

Aufgaben und Rollen

Damit ein Scrum-Projekt gut ablaufen kann, gibt es innerhalb des gesamten Scrum-Teams klar definierte Rollen. Zwei dieser Rollen, Product Owner und Scrum Master, sind über ganz bestimmte Aufgaben definiert. Sie sollten, das zeigt die Praxis, nicht von einer Person in Personalunion gefüllt werden, da es sonst schnell zu Interessenskonflikten kommt. Beide sollten außerdem nicht Teil des Umsetzungsteams sein.

Product Owner

Der Product Owner trägt Verantwortung für das Produkt. Er ist gewissermaßen der „Auftraggeber“ für das Team und vertritt in dieser Funktion alle Stakeholder im Alltagsgeschäft, etwa bei inhaltlichen Rückfragen des Teams. Für ein Scrum-Team in einer Agentur wäre der Product Owner aber auch Vertreterin nach außen, er wäre also zum Beispiel Ihre Ansprechpartnerin in der Agentur.

Hauptaufgaben des Product Owner sind es, auf der einen Seite die Qualität des Endprodukts zu sichern, auf der anderen Seite die Arbeit – und damit den Wert – des Teams zu maximieren. Er soll also die Arbeitskraft des Teams so einsetzen, dass das Endprodukt möglichst effektiv fertiggestellt wird. 

Um seine Ziele zu erreichen, pflegt er insbesondere das Backlog. Der Product Owner trägt deshalb die Verantwortung dafür,

• dass die User Stories im Backlog klar beschrieben und umsetzbar sind,
• dass in den User Stories die richtigen Anforderungen berücksichtigt werden und 
• dass die User Stories priorisiert und dann in einer sinnvollen Reihenfolge abgearbeitet werden.

Darüber hinaus stellt der Product Owner dem Team die Ziele des jeweils nächsten Sprints vor und wählt auch bereits dazu passende User Stories aus.

Um diesen Aufgaben nachzukommen, muss der Product Owner eng mit dem hauptsächlichen Ansprechpartner im Unternehmen zusammenarbeiten – idealerweise stehen die beiden Personen insbesondere in der Anfangsphase des Projekts, wenn der Product Owner aus der Agentur seinen Kunden noch nicht so gut kennt und „versteht“, in kontinuierlichem Austausch.

Umsetzungsteam

Das Umsetzungsteam (auch Development Team oder  Entwicklungsteam) oder einfach Team besteht aus den Mitarbeitern, die operativ an der Umsetzung eines Projektes beteiligt sind. Das Team umfasst also das gesamte sogenannte „Scrum-Team“ ohne Product Owner und Scrum Master.

Das Team besteht aus drei bis maximal neun Menschen und arbeitet interdisziplinär, selbstorganisiert und selbstverantwortlich. Insbesondere entscheidet es selbständig gemeinsam mit dem Product Owner, welche User Stories und Anforderungen es im kommenden Sprint umsetzen kann und will, bevor es diese in einzelne Aufgaben zerlegt und ihren Umfang abschätzt.

Scrum Master

Der Scrum Master hat mit dem eigentlichen Projekt inhaltlich nichts zu tun; seine Hauptaufgabe ist es, dafür zu sorgen, dass das Team ungestört arbeiten kann. Er organisiert, ermöglicht und moderiert die konkreten Abläufe während eines Sprints (die wir weiter unten noch erläutern), beseitigt Hindernisse und Probleme, die das Team am Arbeiten hindern und kümmert sich um viele weitere Details. Er ermöglicht damit reibungslose Kommunikation und möglichst effektives, störungsfreies Arbeiten.

Bei noch unerfahrenen Teams gehört es außerdem zu seinen Aufgaben, die Mitarbeiter in den Scrum-Prinzipien und -Abläufen zu schulen.

Ein Sprint in der Praxis

Ein Scrum-Sprint, egal ob er sieben Tage dauert oder vier Wochen, hat eine klare Struktur. Seine Form bekommt er im Wesentlichen durch eine Reihe von fest vereinbarten und klar strukturierten Meetings und Treffen, die für das Gelingen der Sprints unumgänglich sind. Einer der Hauptgründe für die Einführung agiler Verfahren war es ja, die Kommunikation zwischen den Beteiligten zu verbessern, die Teammitglieder miteinander ins Gespräch zu bringen, die Abstimmung zwischen allen zu verbessern.

So hoch die Zahl der Treffen auf den ersten Blick auch sein mag: Diese Termine haben das Ziel (und die Praxis erweist: auch den Effekt), dass das gesamte Team auch stets über den Status Quo des Projektes im Bilde ist und auf diese Weise gemeinsam optimale Lösungen entwickeln kann. Nur so kann das Team ja auch Verantwortung für das gesamte Projekt, für das gemeinsame Ziel übernehmen und annehmen.

Wichtige Termine im Sprint

Jeder einzelne Sprint beginnt mit einer Sprint-Planung, während der Umsetzung findet jeden Tag ein sogenannter Daily Scrum statt. Zum Ende der Arbeitsphase wird in der Sprint-Review das erarbeitete Produktinkrement begutachtet, zuletzt folgt die Sprint-Retrospektive, in der die Zusammenarbeit im Team und die Abläufe noch einmal kritisch betrachtet werden. Ergänzend sollte gelegentlich vor Beginn des nächsten Durchgangs noch ein Backlog Refinement stattfinden.

Sprint Planning

• Wer nimmt teil?
  Product Owner, Umsetzungsteam und Scrum Master als Moderator.

• Wann findet das statt?
  Zu Beginn jedes Sprints.

• Wie lange dauert es?
  Maximal acht Stunden (die Dauer orientiert sich an der Länge des Sprintintervalls – für vierwöchige Sprints rechnet man mit acht Stunden, für kürzere Sprints entsprechend weniger).

• Was passiert da?
  Sprintplanung: Der Product Owner erläutert zunächst dem Umsetzungsteam, was er mit dem kommenden Sprint erreichen möchte, und präsentiert dazu die Items aus dem Product Backlog mit der höchsten Priorität. Das Team entscheidet dann darüber, welcher Umfang konkret umgesetzt wird und übernimmt für diese Umsetzung auch die Verantwortung. Anschließend zerlegt das Team selbständig die User Stories und Anforderungen in die notwendigen Arbeitsschritte zur Bearbeitung und schätzt den zeitlichen Aufwand für diese Tasks gemeinsam ab (ein recht komplexer Vorgang, der hier beispielhaft beschrieben wird).

Daily Scrum

• Wer nimmt teil?
  Umsetzungsteam, Product Owner (rein passiv) nach Möglichkeit und Scrum Master als Moderator, falls nötig.

• Wann findet das statt?
  Zu Beginn jedes Arbeitstages im Sprint.

• Wie lange dauert es?
  15 Minuten.

• Was passiert da? 
  Alle Teammitglieder berichten – meist am Morgen eines jeden Arbeitstages und im Stehen, deshalb wird der Termin oft auch als „Stand-Up“ bezeichnet – von ihrer Arbeit, indem sie drei Fragen kurz beantworten: Was habe ich gestern getan? Was werde ich heute tun? Gibt es Hindernisse? Der Scrum Master ist dann aufgefordert, die Hindernisse („impediments“) möglichst zu beheben.

Sprint Review

• Wer nimmt teil?
  Product Owner, Umsetzungsteam und alle interessierten Stakeholder (z.B. Auftraggeber).

• Wann findet das statt?
  Zum Abschluss eines Sprints.

• Wie lange dauert es?
  Maximal vier Stunden, Dauer wird je nach Länge der Sprints angepasst.

• Was passiert da?
  Das Team präsentiert dem Product Owner und allen anderen, was es innerhalb des Sprints erreicht hat. Dabei werden nur Aufgaben vorgestellt, die nach einer vorher festgelegten „Definition of Done“ (also einer Definition, wann genau eine Aufgabe als abgeschlossen zu gelten habe) bereits abgeschlossen wurden. Dieses Produktinkrement kann getestet und begutachtet werden. Transparenz ist hier entscheidend, Feedback von den Anwesenden ist unbedingt erwünscht und wird dann für die Planung der folgenden Sprints berücksichtigt.

Sprint Retrospektive

• Wer nimmt teil?
  Product Owner, Umsetzungsteam und Scrum Master.

• Wann findet das statt?
  Zum Abschluss eines Sprints nach dem Sprint Review.

• Wie lange dauert es?
  Maximal 3 Stunden.

• Was passiert da?
  Das Team diskutiert den just abgeschlossenen Sprint und bespricht insbesondere, was aus welchen Gründen gut oder schlecht gelaufen ist – und was man ändern könnte, um dies in Zukunft zu vermeiden. Dabei zeigt die Erfahrung, dass eine „Las-Vegas-Regel“ für diese Treffen sinnvoll ist („What happens in the Retrospective, stays in the Retrospective“), um offene und zugleich konstruktive Kritik zu ermöglichen. Die Retrospektive dient primär dem Zweck, die Zusammenarbeit im Team zu verbessern, also die Abläufe während des Sprints – ganz im Sinne der Idee, die Arbeit in agilen Projekten kontinuierlich zu verbessern.

Backlog Refinement

• Wer nimmt teil?
  Product Owner und Umsetzungsteam.

• Wann findet das statt?
  In regelmäßigen Abständen.

• Wie lange dauert es?
  Je nach Bedarf, Zeitrahmen sollte vorab abgesteckt werden.

• Was passiert da?
  Ziel des Backlog Refinement ist es, dafür zu sorgen, dass das Backlog immer in einem Zustand ist, der beim Sprint Planning eine leichte und reibungslose Planung möglich macht. Deshalb wird zum Beispiel geprüft
  • ob das Backlog noch aktuell ist und eventuell ergänzt werden muss
  • ob User Stories zusammengefasst werden können, neu sortiert und priorisiert werden müssen,
  • ob Abhängigkeiten zwischen User Stories bestehen, die aufgelöst werden müssen oder
  • ob User Stories oder Anforderungen verfeinert und womöglich aufgeteilt werden müssen.

Tatsächlich finden, wie diese Zusammenstellung zeigt, nur zu Beginn und Ende jedes Sprints längere Meetings statt. Während des Sprints hingegen sorgen die Daily Scrums dafür, dass alle Teammitglieder über den aktuellen Stand informiert sind – und dann den Rest ihres Tages ungestört arbeiten können. Natürlich sind dennoch weitere Besprechungen nach Bedarf möglich, werden akute Probleme gemeinsam diskutiert oder wird gemeinsam und in kontinuierlichem Austausch an bestimmten Aufgaben gearbeitet.

Inkremente schön und gut, aber wann wird das Projekt jemals fertig?

Am Ende jedes Sprints steht, wie bereits beschrieben, ein Inkrement (oder Produktinkrement), eine auf den bereits erfolgten Schritten aufbauende Weiterentwicklung des Produkts.

Während des Sprint Reviews gibt es immer die Möglichkeit, das Inkrement zu testen, insbesondere also zu prüfen, ob die entsprechende User Story als erfüllt gilt. Falls die Umsetzung noch nicht zufriedenstellend ist, kann im nächsten oder einem späteren Sprint (je nach Priorisierung) eine neue User Story bearbeitet werden, die die notwendigen Anpassungen beschreibt.

Zugleich werden in jedem Sprint neue User Stories abgearbeitet; an irgendeinem Punkt kann dann entschieden werden, das Digitalprojekt live zu stellen, zu veröffentlichen – von einem fertigen, abgeschlossenen Projekt kann man aber eigentlich nicht sprechen.

Das Product Backlog ist eigentlich nie ganz abgearbeitet, es wird darin immer noch User Stories geben, die mögliche weitere Entwicklungsschritte enthalten oder aus unterschiedlichen Gründen noch nicht umgesetzt werden konnten oder sollten. Insofern ist das „Ende“ eines agilen Projektes, zum Beispiel im Falle eines Relaunch, ein guter Anlass, sich einmal über das Konzept „Continuous Relaunch“ Gedanken zu machen.

Die Erfahrung zeigt: Agil dauern Projekte nicht länger als im „Wasserfall“ – nicht zuletzt, weil es keine langwierigen Abstimmungsphasen gibt und durch die kontinuierliche Abstimmung vermieden wird, dass das Team an den Bedürfnissen der Nutzer und den Anforderungen der Auftraggeber vorbei arbeitet.

Und was bedeutet das für mich, wenn ich ein agiles Projekt beauftrage?

Agiles Projektmanagement ist gewöhnungsbedürftig, wenn man bisher nur „Wasserfall“-Projekte kennt. Das gilt schon für Projekte im eigenen Haus. Wollen Sie, will Ihr Unternehmen gemeinsam mit einer Agentur ein Projekt mit Scrum in die Wege leiten, gibt es da durchaus zahlreiche Herausforderungen.

Aber keine Sorge: Die Vorteile überwiegen die Anstrengungen bei weitem. In einem agilen Projekt übernehmen Sie als Kunde eine sehr aktive, lebendige Rolle. Wie genau diese Rolle aussieht und wie eine Zusammenarbeit gelingen wird, darüber erfahren Sie mehr in unserem nächsten Artikel zum Thema Scrum in der Zusammenarbeit mit einer Agentur.