Agiles Projektmanagement mit Scrum verspricht das Erreichen der Projektziele mit einer flexibleen und effizienten Herangehensweise. Die Idee, Projektabläufe aus ihren starren Strukturen des klassischen Projektmanagements herauszuheben, hatten Jeff Sutherland und Ken Schwaber schon in den frühen 90er Jahren. Die Entwicklung eines Produkts sollte durch agiles Projektmanagement in Zwischenschritten über mehrere Phasen aufgeteilt werden. Ihr daraus resultiertes Framework für agiles Projektmanagement nannten sie Scrum. Grundsätzliches zu diesem Framework finden Sie in dem ausführlichen Deep-Dive-Artikel. In diesem Artikel geht es darum, agiles Projektmanagement mit Scrum effektiv anzuwenden. Was sind Best Practises, die Sie in Ihrem Unternehmen berücksichtigen können? Welche Fehler sollten Sie vermeiden, die insbesondere zu Beginn warten?

Dieser Artikel ist geeignet für: Jeden, der mit der Durchführung von Scrum-Projekten beauftragt oder an dessen Durchführung beteiligt ist.

Schwierigkeitsgrad:*1234

*Vorausgesetzt werden Kenntnisse im Projektmanagement und dessen praktischer Anwendung, außerdem ist ein Grundwissen bezüglich des Scrum-Frameworks zu empfehlen. Möchten Sie sich die Deep-Dive-Lektüre nicht extra durchlesen, folgt zu Beginn des Artikels eine Kurzzusammenfassung dessen.

Agiles Projektmanagement mit Scrum in Kürze

 

  • Scrum ist das weitverbreitetste Framework für agiles Projektmanagement weltweit und wurde in den frühen 90er Jahren entwickelt.
  • Für agiles Projektmanagement mit Scrum müssen die Rollen des Product Owners, Scrum Masters und maximal neunköpfigen Entwicklungsteams verteilt werden. In diese Rollen sollten Leute schlüpfen, die sich für das Projekt begeistern können und Verantwortung übernehmen möchten.
  • Auch wenn Scrum agiles Projektmanagement bedeutet, braucht es eine professionelle und umfangreiche Projektvorbereitung in Form eines freizugebenden Projektaufsatzes – fehlende Konkretisierung oder gar fehlende Vorbereitung führt bei den meisten Projekten zum Scheitern.
  • Für agiles Projektmanagement mit Scrum sind stets die Regeln des Frameworks hinsichtlich der Meetings und Abläufe einzuhalten – Regeln für die Arbeit des Teams existieren nur wenige. Es ist in seinen Entscheidungen frei und kann auch die einzusetzenden Tools und Werkzeuge selbst bestimmen.
  • Die genaue Festlegung von einzusetzenden Werkzeugen, Vorlagen und Regeln für das Scrum-Projekt mit einem Projektmanagement-Experten ist zu empfehlen. Ansonsten schleichen sich häufig ineffiziente Arbeitsweisen ein.
  • Ein Scrum-Projekt wird im Wesentlichen durch die originären Scrum-Aktivitäten, wie Sprints, Daily-Meetings und Reviews, geprägt. Betrachtet man zusätzlich die absolut notwendige Projektvorbereitung und einen (zu empfehlenden) sauberen Projektabschluss, besteht ein Scrum-Projekt insgesamt aus drei Phasen.
  • Das Scrum-Team wird bei der Kick-off-Veranstaltung ins Projekt eingeführt, danach bewegt es sich stets im Scrum-Kreislauf (Sprint-Planning-Meeting, Sprint mit Daily Scrums, Sprint-Review, Retrospektive und von vorn)
  • Sprints können abgebrochen werden, sofern ihre Ziele durch unvorhergesehene Hindernisse oder Probleme nicht mehr erreicht werden können, sollten die Aufgaben schneller umgesetzt worden sein, ist eine Verkürzung des Sprints denkbar, eine Verlängerung sollte aber nicht stattfinden. Der Abbruch oder die Verkürzung von Sprints stellen eine Ausnahme dar.
  • Sofern ein ganzes Projekt abgebrochen werden muss, ist zu überlegen, weshalb – meist liegt es nicht am Scrum-Team, sondern wie oben im Artikel erwähnt, an einer unzureichenden Projektvorbereitung.

Scrum – Wesentliche Prinzipien und Begriffe

Agiles Projektmanagement Scrum PuzzleteileScrum lässt sich kurz und knapp als exzellentes Framework für agiles Projektmanagement bezeichnen. Das heißt, es geht um Projekte, die nicht vorab in einer hohen Detailtiefe durchgeplant werden, sondern die von Phase zu Phase weiterlaufen und immer nur für eine Phase im Voraus geplant werden. In der Sprache von Scrum nennt man diese Phasen „Sprint“. In den agilen Sprints wird über mindestens zwei bis maximal vier Wochen hinweg ein alleinstehendes Produkt-Inkrement entwickelt. Man arbeitet also nie direkt an der Endausbaustufe eines Produkts, sondern immer an einzelnen Teilen, die nach einer Sequenz von Sprints in der Endausbaustufe münden. Welche Inkremente zuerst und als letztes entwickelt werden, bestimmt der Product Owner. Er ist am ehesten mit dem Projektmanager im klassischen Projektmanagement zu vergleichen, auch wenn es in Scrum offiziell keinen gibt. Das heißt, der Product Owner definiert und priorisiert den Anforderungsrahmen des Produkts. Damit entscheidet er über die Reihenfolge, in der die MVPs entwickelt werden. Hierdurch  bestimmt er auch die Laufrichtung für den jeweils nächsten Sprint. Im Sprint selbst hat der Product Owner allerdings keinerlei Einfluss mehr auf die Arbeit des Teams.

Das Team arbeitet autark an dem jeweils nächsten Inkrement. Damit es weiß, was es zu tun hat, findet vor dem Sprint das Sprint-Planning-Meeting statt. Hier kommt das gesamte Scrum-Team zusammen und die Produktanforderungen aus dem sogenannten Product Backlog des Product Owners werden in die Aufgaben aus dem Sprint Backlog des Entwicklungsteams übersetzt. Mit anwesend ist auch ein Scrum Master, der darauf achtet, dass die Regeln von Scrum eingehalten und Hindernisse bei der Produktentwicklung beiseite geräumt werden. Das alles sollten Sie grundlegend wissen, um agiles Projektmanagement mit Scrum bei sich einführen zu können. Deutlich mehr dazu können Sie in der Scrum-Deep-Dive-Lektüre lesen.

Fehlende Konkretisierung als Hauptfehlerquelle in Scrum-Projekten

Grundsätzlich ist das universelle Framework von Scrum exzellent und bietet vielen Unternehmen die Möglichkeit, ihre Projekte weitaus effizienter und flexibler umzusetzen als bisher. Gleichwohl kann Scrum Risiken bergen, wenn man es nicht richtig einsetzt. Eine große Fehler- und somit Risikoquelle ist eine ausbleibende Konkretisierung. In Scrum gibt es keine festen Methodiken, sondern nur wenige Regeln, die einen Rahmen für die Projektdurchführung ergeben. Den Rest übernimmt das Scrum-Team eigenverantwortlich und autark. Genau das kann im Chaos enden, wenn vorab keine Konkretisierungen seitens des Managements vorgenommen werden. Erfahrungen zeigen, dass dieser Fehler tatsächlich zum Scheitern der meisten Scrum-Projekte führt.

Was bedeutet Konkretisierung in diesem Zusammenhang?

Auch wenn Sie sich mit Scrum eigentlich von den starren Strukturen des klassischen Projektmanagements loslösen, werden Komponenten des Projektmanagements zu Beginn noch gebraucht (Stichwort Initialisierungsphase). Das Argument, dass man „doch in einem agilen Projekt arbeitet und keine Vorausplanungen mehr macht“, ist recht häufig zu hören aber schlichtweg falsch. Denn der Mantel des Projektmanagements ist noch immer vorhanden, nur im Kern wird es flexibel. Somit sollten Entscheider ihre Erwartungshaltung an das Projekt klar und präzise definieren sowie monetäre und personelle Ressourcen entsprechend übergreifender Unternehmensziele festlegen.

Damit Ihre Scrum-Projekte nicht scheitern, beschreibt dieser How-to-Guide die wichtigsten Aufgaben im Zeitablauf. Setzen Sie diesen Ablaufplan strukturiert um und Ihr Scrum-Projekt ist gut vorbereitet und durchgeführt. Achten Sie auf die beschriebenen typischen  Fehler und Best-Practise-Beispiele.

Phase 1 – Planung & Projektvorbereitung

Aufbauend auf der soeben beschrieben Konkretisierung, braucht es zum Start eines Scrum Projektes einen analytisch starken Initiator, der mindestens über Grundkenntnisse im Projektmanagement verfügt. Das kann entweder der Auftraggeber des Projekts oder auch der im Scrum-Team ernannte Product Owner sein. In keinem Fall ist es allerdings der Scrum Master und hier wartet auch schon der erste Fehler. Viele Unternehmen setzen den Scrum Master auf die Erarbeitung inhaltlicher Eckpfeiler ein. „Der Scrum Master weiß ja, wie das mit Scrum geht, also lassen wir ihn das Projekt auch vorbereiten.“ Dazu ist anzumerken, dass die Rolle des Masters wichtig für die Initialisierung und die funktionierende Umsetzung des Projekts ist. Der Master ist jedoch ein Methodenexperte und kein Manager. Seine Gedanken drehen sich um den Daily Scrum sowie die Sprints, Retrospektiven und Backlogs – aber nicht um Wertschöpfung, strategische Wertbeiträge, elementare Risiken und konkrete Ergebnisse. Das ist die Perspektive des Initiators, nicht des Scrum Masters. Im weitesten Sinne könnte man den Initiator als Projektmanager bezeichnen und ihm dessen Aufgaben zuweisen.

Erstellung des Projektaufsatzes durch den Initiator

Agiles Projektmanagement Scrum ProjektaufsatzDer Initiator nimmt das Wissen und die Grundelemente des Projektmanagements heran und formt aus ihnen die Eckpfeiler des bevorstehenden Scrum-Projekts. Das heißt, er kümmert sich um die Ziele, Vision und den Gegenstand des Projekts. In der Projektmanagement-Sprache werden sie auch unter dem Begriff „Scope“ zusammengefasst. Danach definiert er die zu erarbeitenden Ergebnisse, setzt Obergrenzen für das externe Budget und die internen Ressourcen und macht sich ein Bild von den Projektrisiken. Außerdem arbeitet der Initiator einen groben Meilensteinplan und ein grobes Organigramm aus. Er hat dazu einen Blick auf die Stakeholder, den Auftraggeber und sonstigen wesentlichen Personen um das Scrum-Team herum sowie auf weitere zu berücksichtigende Richtlinien des Unternehmens. Aus diesen Aufzeichnungen entsteht der sogenannte Projektaufsatz, eine PowerPoint-Präsentation mit etwa 15 Seiten, auf denen diese Analyseergebnisse festgehalten werden.

BEST PRACTISE NR. 1

Nehmen Sie sich die Zeit und erstellen Sie einen Projektaufsatz von hoher Qualität. Je besser Sie an dieser Stelle vorarbeiten, desto einfacher kann das Scrum-Team Ihre Erwartungshaltung in die Projektdurchführung einfließen lassen. Der Projektaufsatz ist ein exzellentes Medium, um die Erwartungshaltung an alle Beteiligten zu kommunizieren. Zudem sind die enthaltenen Ziele ein Wertmaßstab für das Projekt während seiner gesamten Laufzeit.

Was ist beim Projektaufsatz zu beachten?

Je besser der Initiator ist, desto besser ist der Projektaufsatz. Je besser der Projektaufsatz ist, desto besser eignet er sich als Vorlage für das anstehende Projekt. Das heißt, der Initiator sollte über die Fähigkeit und die Erfahrung verfügen, komplexe Aufgaben zu strukturieren und umzusetzen. Ein gutes Projektmanagement-Wissen kann nicht schaden. Ab einem Projektaufwand von mehr als 200.000 Euro sollten nur noch Projektmanagement-Profis die Erstellung des Projektaufsatzes übernehmen oder den Initiator hierin unterstüzen. Auch wenn  dies hohe monetäre Ressourcen erfordert, ist der Return on Invest den Erfahrungen nach hoch. Nach Fertigstellung muss der Projektaufsatz zunächst durch die originäre Organisation des Unternehmens autorisiert und freigegeben werden.

Das ist ein formeller Schritt, der bedeutet, dass das Projekt-Team zum Erreichen der angestrebten Ziele die spezifischen Mittel (Budget/Ressourcen) aufwenden darf. Typischerweise erfolgt die Autorisierung durch einen Lenkungsausschuss, also das höchste Entscheidungsgremium des Projekts. Der Auftraggeber oder der zuständige Entscheider der ersten Führungsebene spielen die wesentliche Rolle in ihm. Mit der Autorisierung wird das Projekt nicht nur offiziell zum Start freigegeben, sondern es werden auch die Kompetenzen des Projektes geregelt. Beispielsweise in Form von Weisungsbefugnissen gegenüber Führungskräften und Mitarbeitern des Unternehmens.

Gibt es eine Alternative zum Projektaufsatz?

Auch an dieser Stelle soll die Aussage, dass „eine große Vorausplanung nicht braucht, weil man agiles Projektmanagement macht“ noch einmal aufgegriffen werden. Gewiss ist die Erstellung und Autorisierung eines Projektaufsatzes mit einem erhöhten Aufwand verbunden. Man möchte sich am liebsten sofort mit den Daily Scrums, Sprints und Klebezetteln beschäftigen. Das ist ohne eine Zielsetzung grob fahrlässig – denn insbesondere bei Projekten ohne vorher definierte Ziele ist regelmäßig ein Scheitern zu beobachten. Agiles Projektmanagement lebt von der Selbstorganisation, aber ohne ein angestrebtes Ziel funktioniert sie nicht. Darüber hinaus widerspricht der Ansatz, ohne Planungen in das Projekt einzusteigen, gänzlich dem Grundprinzip unternehmerischen Handelns. Kein Unternehmen sollte die ohnehin immer knappen Ressourcen für ziellose Projekte aufwenden.

Um die profunde Erarbeitung der inhaltlichen Eckpfeiler kommt man also nie herum, aber gewiss wird im agilen Projektmanagement deutlich mehr Spielraum für die Adaption der Projektergebnisse und des Vorgehens gelassen. Der agile Projektaufsatz ist eine Meilenstein-Planung, in der für jeden Meilenstein auch ein Budget kalkuliert wird. Zu beachten ist, dass die Meilensteinplanung nichts mit den Sprints des agilen Projektmanagements zu tun hat. Es geht dabei um wesentliche Meilensteine, die die grundsätzlichen Entwicklungsstufen des Produkts festlegen. Typischerweise werden einige Sprints absolviert, um den nächsten Meilenstein zu erreichen.

Nach der Freigabe des Projektaufsatzes inkl. der Meilensteinplanung wird die Vorbereitung mit dem Ernennen der Mitglieder des Entwicklungsteams abgeschlossen. Das Entwicklungsteam darf aus höchstens neun Leuten bestehen, ideal sind drei bis sechs Leute.

 

Agiles Projektmanagement Scrum Launch Sprint

Phase 2 – Projektstart & laufendes Projekt

Der Startschuss für das Projekt fällt in einem speziellen Kick-off-Meeting. Hier ist das gesamte Scrum-Team (Übersicht der Akteure) anwesend und auch Auftraggeber, Geschäftsführer sowie sonstige Stakeholder sind gegebenenfalls dabei. Das Kick-off-Meeting dauert etwa ein bis zwei Stunden und es geht hauptsächlich darum, das Team mit dem Projektaufsatz zu konfrontieren und es mit den Rahmenbedingungen und Grundanforderungen vertraut zu machen. Im folgenden langen Kapitel erhalten Sie Einblick in die genauen Abläufe eines Scrum-Projekts und in die Details der einzelnen Meetings und Sprints. Lassen Sie uns einsteigen mit einem weiteren Best Practise-Tipp unserer Experten.

BEST PRACTISE NR. 2

Sie reden von Zielen, Visionen, zu erarbeitenden Ergebnissen und vielem mehr. Aber kann das zuvor ernannte Team sofort etwas damit anfangen? Am besten ist es, wenn Sie all die Details möglichst einfach und nachvollziehbar erklären. Jeder muss die elementaren Grundsätze des Projekts verstehen. Jedoch machen viele Projektmanager den Fehler, viel zu sehr aus ihrer Sicht zu denken und zu erzählen. So kann es leicht zu Missverständnissen kommen und zu Spannungen im Team, weil die einen etwas anders aufgefasst haben als die anderen.

Erstellung eines Product Backlogs für sämtliche Produktanforderungen

Zum Ende des Kick-off-Meetings übernimmt der Scrum Master das Wort und beschreibt den weiteren Verlauf sowie die Regeln, die ihm durch das Scrum-Framework zugrunde liegen. Hier erfährt das Team, dass sofort der erste Sprint startet und der Product Owner das hierfür notwendige Product Backlog bereits ausarbeitet hat. Im Product Backlog werden fortlaufend die wesentlichen Produkteigenschaften und deren Prioritäten festgehalten. Es ist niemals fertig, sondern wird über die gesamte Projektlaufzeit hinweg gepflegt. Bei kleinen Projekten stehen die gewünschten Produkteigenschaften und Anforderungen feldübergreifend untereinander. Bei größeren Projekten werden sie in die einzelnen Zuständigkeitsbereiche unterteilt. Im Product Backlog eines großen Internetportals würden die Anforderungen beispielsweise in die Kategorien „technische Entwicklung“, „Content“, „Design“ und „Benutzererfahrung“ verteilt werden. Daneben braucht das Product Backlog noch die Ebene des Minimum Viable Products. Hier werden die Anforderungen einem konkreten MVP zugeordnet und so entsteht das Aufgabenspektrum des ersten Sprints.

Nachdem alles besprochen ist, vereinbart der Scrum Master direkt einen Termin für das erste Sprint-Planning-Meeting, bei dem das Scrum-Team erneut zusammenkommt.

Besprechung des Backlogs im Sprint-Planning-Meeting

Im Sprint-Planning-Meeting wird das im Rahmen des Sprints zu entwickelnde Produktinkrement (Minimum Viable Product) besprochen, bevor der erste Sprint startet. Dieses Meeting dauert maximal fünf Prozent der gesamten Sprint-Zeit. Sofern der bevorstehende Sprint also für einen Monat angesetzt ist, darf das Sprint-Planning-Meeting bis zu einen Arbeitstag in Anspruch nehmen. Der Product Owner steht hier im Mittelpunkt und stellt beim ersten Sprint-Planning zunächst die Vision des Projekts vor. Sie ist wie ein Stern, der das selbstorganisierende Team leitet – ohne die Vision und die dazugehörigen Ziele gibt es auch keine Selbstorganisation. Bei dem Kick-off-Meeting ging es noch um die globalen Visionen und Ziele des Unternehmens. Beim Planning-Meeting steht dagegen das konkrete Produkt im Zentrum. Der Product Owner präsentiert die Inhalte und Prioritäten des Product Backlogs vor. Zusammen mit dem Entwicklungsteam wird herausgearbeitet, welche Prioritäten in diesem Sprint umgesetzt werden können und wie viel Zeit für jeden einzelnen Punkt aufzuwenden ist. In der originären Scrum-Denkweise ist es allein die Aufgabe des Teams, die Aufwände für einzelne Aufgaben zu schätzen. Analog hierzu obliegt dem Team die Verantwortung, die im jeweiligen Sprint umzusetzenden Sachumfänge festzulegen.

Eine Methode zum Herausfinden des Aufwands ist das sogenannte Planungspoker. Hier bekommen alle Mitglieder des Entwicklungsteams Karten mit verschiedenen Zahlenwerten, die einen jeweils kleinen oder großen Zeitaufwand symbolisieren. Der Product Owner stellt eine Aufgabe vor und jeder legt eine Zeitaufwandskarte verdeckt vor sich hin. Danach werden die Karten umgedreht. Sofern sich alle im selben Dreh befinden, übernimmt der Product Owner den Aufwand so. Sollte Uneinigkeit herrschen, rechtfertigen sich diejenigen mit den kleinsten und größten Zahlenwerten zu ihrer Entscheidung. Am Ende einigt man sich auf einen realisierbaren Mittelwert. Hinsichtlich der Zeitaufwände und Aufgaben treffen Product Owner und Entwicklungsteam eine verbindliche Vereinbarung. Das heißt, dass das Entwicklungsteam die Anforderungen definitiv im kommenden Sprint umzusetzen hat. Die Anforderungen werden aus dem Product Backlog ins Sprint Backlog übertragen. Meist kümmert sich darum ebenfalls der Product Owner. Diese Aufgabe kann alternativ der Scrum-Master übernehmen. Danach kann der Sprint losgehen.

 

Agiles Projektmanagement Scrum Sprint

Fertig für den ersten Sprint?

Vor allem dann, wenn Sie agiles Projektmanagement mit Scrum in Ihrem Unternehmen erstmals anwenden, muss sich das neue Scrum-Team zuerst finden und aufeinander einspielen. Aus diesem Grund ist es sinnvoll, die ersten Sprints nur zwei Wochen anstelle direkt vier Wochen dauern zu lassen. So kann das Team in kurzen Läufen erste Erfahrungen sammeln und seine Arbeit immer weiter optimieren, bevor ausgedehntere agile Sprints kommen. Für den Product Owner bedeutet diese Phase, sich mit den ganz großen und komplizierten Herausforderungen noch zurückzuhalten, aber das Team dennoch zu fordern. Er sollte für die ersten Sprints noch einfachere Produktinkremente ansetzen, an denen das Team zusammenwachsen und die ersten Erfahrungen sammeln kann. Ab dem dritten Sprint kann er die Schrauben dann fester anziehen.

Daily Scrum zur morgendlichen Synchronisierung

Das Team trifft sich im laufenden Projekt jeden Morgen zum Daily Scrum. Dabei handelt es sich um ein 15-minütiges Meeting, bei dem das Team die Aufgaben des bevorstehenden Tages plant und strukturiert. Idealerweise arbeitet das Team hier mit Klebezetteln, um zuerst alles zu sammeln und es dann am Scrum-Board, einer großen freien Fläche, zu ordnen. Vertiefende Diskussionen zu Fachthemen bleiben gemäß der Regeln und Werte beim Daily Scrum außen vor und werden am besten auf separate Meetings vertagt. In dem Daily ist vorher genau abzusprechen, wer zu welchem Thema vertiefend spricht. Da es nicht gern gesehen ist, dass das Daily Scrum länger als 15 Minuten geht, finden erforderliche Diskussionsrunden normalerweise direkt im Anschluss an die Morgenbesprechung statt. Durch das Verwenden einer Stoppuhr (Timeboxing) wird die Dauer exakt gesteuert.

BEST PRACTISE NR. 3

Machen Sie es sich und dem Team einfach – treffen Sie sich jeden Tag zur selben Uhrzeit am selben Ort. Beginnen Sie stets pünktlich und lassen Sie das Daily Scrum nicht länger als die 15 Minuten gemäß Scrum-Regeln gehen. So entsteht eine für jeden einheitliche Morgenroutine, bevor man an die Arbeit geht.
Beim Daily Scrum gilt die Regel, dass jeder aus dem Team beteiligt ist und eingebunden werden muss. Denn im Sprint trägt jeder im Team einen wesentlichen Teil zu dem aktuell zu entwickelnden Produktinkrement bei. Im Idealfall braucht es beim Daily keiner elektronischen Medien, um die Themen, Aspekte und Aufgaben des Scrum-Boards zusätzlich zu erfassen. Zumindest solange alle Beteiligten physischen Zugriff auf das Scrum-Board und auch in der Nähe ihren Arbeitsplatz haben. Eine räumliche Nähe aller Kollegen des Scrum-Teams ist wesentlich für den Erfolg eines Scrum-Projekts. Versuchen Sie auch, in räumlich schwierigen Situationen das Scrum-Team möglichst nah beieinander unterzubringen. Eine zu starke räumliche Trennung des Teams kann zu einem echten Verhinderer des Erfolgs werden.

Welche Fragen stehen beim Daily Scrum im Fokus?

Auch der Scrum Master nimmt am Daily Scrum teil und achtet darauf, dass die Scrum-Methodik richtig eingesetzt und die Scrum-Grundwerte stets eingehalten werden. Jeder aus dem Entwicklungsteam hat eine Minute Redezeit, um auf die drei zentralen Fragen des Meetings einzugehen. Auch darauf hat der Scrum Master ein Auge.

  • Welchen Beitrag zum aktuellen MPV habe ich gestern geleistet?
  • Welchen Beitrag zum aktuellen MPV werde ich heute leisten?
  • Welche Hindernisse bestehen aktuell noch und was brauche ich vielleicht noch von anderen, um meine Aufgaben erfüllen zu können?

Da sich diese Fragen ausschließlich auf den Arbeitsprozess und Probleme in diesem beziehen, findet das Daily Scrum normalerweise ohne den Product Owner und weitere externen Personen statt. Insbesondere der Auftraggeber oder das Management sollten von dem Meeting ausgeschlossen werden, da sich deren Anwesenheit den Erfahrungen nach negativ auf die Produktivität während des Meetings auswirkt. Haben alle Mitglieder des Entwicklungsteams eine Minute lang gesprochen, wird die restliche Zeit dafür verwendet, die Konsequenzen abzuleiten und akute Hindernisse zu beseitigen.

Sprint-Review nach Abschluss des agilen Sprints

Wenn alles glatt läuft, wächst das MVP immer weiter heran und der Sprint nähert sich dem Ende. Direkt im Anschluss an den Sprint findet das Sprint-Review-Meeting statt. Hier ist wieder das gesamte Team inklusive Product Owner anwesend und das Entwicklungsteam stellt sein Arbeitsergebnis aus dem Sprint vor. Der Product Owner gibt daraufhin Feedback, inwiefern die Vereinbarungen aus dem Sprint-Planning-Meeting eingehalten wurden. Außerdem, ob das entwickelte Produktinkrement seine Erwartungshaltung an die Produkteigenschaften erfüllt. Auch das Entwicklungsteam gibt Feedback. Das Sprint-Review-Meeting dauert zwischen zwei und vier Stunden. Die Einladung dazu erfolgt durch den Product Owner und der Scrum Master stellt die ordnungsgemäße Durchführung des Reviews sicher.

BEST PRACTISE NR. 4

Bitte keine PowerPoint-Präsentation. Das Arbeitsergebnis des Sprints wird live präsentiert, in der Art und Weise, wie auch ein Kunde mit dem MVP in Kontakt kommt. Geht es beispielsweise um eine Website für Fernreisen inklusive Buchungsfunktion, so würde man im Sprint-Review Testbuchungen auf dieser Website vornehmen und somit typische Buchungsanfragen von echten Kunden simulieren. Dabei spricht man auch über verschiedene Kundengruppen. Ein Unternehmer, der eine Luxusreise sucht, um seine Ehefrau zu überraschen, geht auf der Website wahrscheinlich anders vor, als eine vierköpfige Familie, die einen Familienurlaub buchen möchte.

Erneuter Lenkungsausschuss nach dem Review

Nach dem Sprint-Review innerhalb des Scrum-Teams, bei dem übrigens gern auch der Auftraggeber, das Management und weitere Stakeholder teilnehmen dürfen, findet noch ein Lenkungsausschuss statt. Hier sind dieselben Personen beteiligt, die zuvor das Projekt autorisiert haben. Sofern diese schon im Sprint-Review dabei waren, haben sie eine klare Vorstellung von dem Produkt, für das die zuvor freigegebenen Ressourcen eingesetzt werden. Ansonsten würde der Product Owner das Ergebnis noch einmal kurz präsentieren.

Agiles Projektmanagement mit Scrum PuzzleIm Mittelpunkt dieses erneuten Lenkungsausschusses stehen aber wieder mehr die inhaltlichen Aspekte (erzielte Ergebnisse, Budget, Risiken) im Zentrum. Das heißt, man gleicht die Inhalte des Projektaufsatzes mit dem aktuellen Zwischenstand ab und passt die Planungen gegebenenfalls noch einmal an. Es ist typischerweise die Aufgabe des Product Owners, den zweiten Lenkungsausschuss des Projekts vorzubereiten und eine Entscheidung zu initiieren. Wie oben beschrieben, kann diese Aufgabe auch durch eine Projektmanagement-Unterstützung übernommen werden. Haben die Sprints eine Dauer von nur zwei Wochen, findet nach jedem zweiten Sprint ein Lenkungsausschuss statt.

Bei resultierenden Planungsänderungen ist es grundsätzlich die Aufgabe des Product Owners, das Scrum-Team beim nächsten Sprint-Planning-Meeting in die neuen Gegebenheiten einzuweisen.

Retrospektive parallel zum Lenkungsausschuss

Gedanklich zeitgleich zum zweiten Lenkungsausschuss findet innerhalb des Entwicklungsteams eine Retrospektive statt. Bei der Retrospektive geht es darum, die Erfahrungen aus dem letzten Sprint Revue passieren zu lassen und darüber zu sprechen, wie sich aufgetretene Probleme und Hindernisse für zukünftige agile Sprints vermeiden lassen. Auch dieses Meeting dauert zwei bis vier Stunden, genau wie der Sprint-Review. Das Team soll sich Zeit dafür nehmen, die Erfahrungen so aufzubereiten und zu verarbeiten, dass die Effizienz der Arbeit zunimmt.

BEST PRACTISE NR. 5

Die Retrospektive sollte nach dem gleichen Prinzip wie das Daily Scrum funktionieren. Das heißt, dass jeder einen Redebeitrag haben sollte, in dem er über seine Erfahrungen spricht. Nicht immer müssen Probleme und Hindernisse global im gesamten Team aufgetreten sein, es können auch einzelne Mitglieder sein, die mit Problemen und Hindernissen zu kämpfen hatten. Der Redebeitrag sollte immer nach dem Motto „Wir steigern die Effizienz, indem wir Folgendes ändern…“ aufgebaut sein. Die Änderungen können beispielsweise in einer stärkeren Zusammenarbeit, im Einsatz neuer Tools und Werkzeuge oder in geänderten Arbeitszeitmodellen bestehen.
Ein „Ich fand den Sprint super, hatte keine Probleme“ sollte vor allem in den ersten Retrospektiven nicht an der Tagesordnung stehen. Gerade am Anfang gibt es überall noch etwas zu optimieren und ein Sprint wird nicht perfekt verlaufen. Die Mitglieder des Entwicklungsteams sind stets zu motivieren, auch über die kleinsten Stellschrauben nachzudenken. Es ist wichtig, auch diese zu besprechen und gegebenenfalls an ihnen zu drehen. Nur so kann die Zusammenarbeit im Team und können deren Ergebnisse nachhaltig verbessert werden.

Darf ein Sprint abgebrochen, verkürzt oder verlängert werden?

Agiles Projektmanagement Scrum AbbruchNormalerweise hält sich das Scrum-Team an den festen Ablauf und an die festen Regeln, die das Framework vorgibt. Es gibt aber auch Ausnahmen. Sofern sich im Sprint Probleme oder Hindernisse herausstellen, die das Erreichen des Ziels unmöglich machen, gilt es, den Sprint lieber abzubrechen und die Ressourcen nicht unnötig zu strapazieren. Sollte sich herausstellen, dass das MVP schon vor Ende des Sprints fertig entwickelt ist, kann der Sprint selbstverständlich verkürzt werden. Verlängerungen sind allerdings nicht vorgesehen und strikt verboten. Ein Sprint sollte nie länger als vier Wochen dauern. Sofern eine Verlängerung notwendig wäre, sind die betreffenden Aufgaben in den nächsten Sprint zu übertragen. Zusätzlich ist zu prüfen, was genau das Nichterreichen des Sprintziels verursacht hat und wie man damit umgeht, um derartige Gründe zukünftig zu vermeiden. Eher würde man den Sprint abbrechen und neu ansetzen, als dass man ihn verlängert. 

Kann das gesamte Projekt mittendrin abgebrochen werden?

In Ausnahmesituationen kann es auch passieren, dass ein ganzes Projekt abgebrochen wird. Auch hier ist aber sehr genau zu prüfen, ob ein Abbruch unbedingt erforderlich ist. Schließlich wurde vorab der Projektaufsatz ausgearbeitet und autorisiert, außerdem wurde im Kick-off-Event jeder so in das Projekt eingeführt, dass er eine optimale und zielgerichtete Leistung hätte erbringen können. Oder nicht? Meist liegt ein Projektabbruch daran, dass bei der Vorbereitung nicht sauber gearbeitet wurde. Agiles Projektmanagement mit Scrum geht nur dann auf, wenn der Prozess von Anfang an stimmt und nicht erst ab dort, wo das eigentliche Scrum-Framework einsetzt. Fehlende übergreifende Steuerungs-Kompetenzen gehören zu den typischen Fehlern und Risiken in Scrum-Projekten. Genau wie fehlende Ergebnisorientierungen, eine falsche Auswahl der Akteure und unklare methodische Festlegungen im Detail. Erst dann folgen Fehler, die im Scrum-Framework selbst auftreten können, indem man die Regeln nicht einhält oder in Meetings nicht genau genug arbeitet.

Fazit

Der Erfolg eines Scrum-Projekts hängt von zwei wichtigen Faktoren ab. Einmal von der Vorbereitung und einmal von den Herangehensweisen des Teams. Ist eine gute Vorbereitung nicht gegeben, weil es sich um agiles Projektmanagement handelt und man scheinbar keine Vorbereitung braucht, kann das Projekt scheitern. Genauso, wenn das Team nicht vernünftig eingewiesen wird und sich nicht für den Arbeitsprozess von Scrum begeistern kann. Jeder muss voll dabei sein, die Regeln kennen und beachten, sich über seine verantwortungsbewusste Rolle bewusstwerden und stets die eigene Arbeit hinterfragen. Dann entfaltet agiles Projektmanagement mit Scrum seine ganze Exzellenz. Mit diesem How-to-Guide sind Sie in der Lage, agiles Projektmanagement mit Scrum in Ihrem Unternehmen zu etablieren und Ihre Projekte zum Erfolg zu führen.