Phase 1 – Planung & Vorbereitung

Email
Twitter
20
LinkedIn52
Share
Facebook30
Whatsapp

Aufbauend auf der soeben beschriebenen 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

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

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.

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.

Sprints bei Scrum

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.

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. 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. Im 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.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?

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

Email
Twitter
20
LinkedIn52
Share
Facebook30
Whatsapp

Weitere Inhalte: