Agiles Projektmanagement

Erstellt: 07.02.2018

Darum geht’s: Viele klassische Projektmanagement-Methoden versuchen, ein Projekt im Detail vorzuplanen und bestimmte Ergebnisse zu bestimmten Zeitpunkten zu fixieren. Das klappt allerdings in vielen Fällen nicht so, wie es soll. Denn sonst würden nicht so viele Projekte aus dem Ruder laufen. Die Probleme sind dabei oft hausgemacht: Die Planung ist zu starr und kann nicht auf neue Anforderungen reagieren. Sehr viel flexibler sind agile Methoden wie Scrum. Sie gehen in kleinen Schritten vor und erlauben eine schnelle Anpassung. In diesem Beitrag erfahren Sie, welche Projekte sich für agile Methoden eignen und wie Sie eigene Projekte mit agilen Methoden durchführen.

Gratis-Download

Projekte, Projekte und noch mehr Projekte. Dass der Anteil der Projektarbeit an der Gesamtwertschöpfung weiter rasant zunehmen wird, erscheint...

Jetzt downloaden

Führen in und mit agilen Projekten

Das ist Ihre Ausgangssituation

Sie müssen immer schneller entscheiden, sich an veränderte Markt- oder Rahmenbedingungen anpassen. Da ist oft der Businessplan, den Sie geschrieben haben, schon überholt, wenn Sie die Startphase hinter sich haben. Hier schafft agiles Projektmanagement Abhilfe. Kleinschrittig werden die nächsten Phasen geplant – immer wieder bereit, die Richtung zu korrigieren. In welchen Projekten Sie die Methoden des agilen Projektmanagements anwenden können, erfahren Sie in diesem Beitrag.

So sieht der Lösungsweg aus

In agilen Projekten werden anstelle eines fertigen Endproduktes in mehreren Wiederholungen Zwischenprodukte entwickelt. Diese dienen als Basis für den nächsten Schritt. Damit sind agile Methoden in vielen Fällen nicht nur schneller, sondern auch deutlich flexibler. Denn Änderungen sind ausdrücklich vorgesehen und fester Bestandteil des Prozesses. Folgende Maßnahmen führen zum Ziel:

Schritt 1: Aufstellen des Teams
Besetzen Sie die 3 Rollen im Team: die des Scrum Masters, des Product Owners und des Scrum Teams.

Schritt 2: Beschreiben der Anforderung
Der Product Owner formuliert die Anforderungen an das neue Produkt.

Schritt 3: Planung des Sprints
Im sogenannten Sprint Planning erfolgt die Planung des Sprints, der Wiederholungen. Es wird festgelegt, was wie umgesetzt werden soll.

Schritt 4: Durchführung des Sprints
Die definierten Aufgaben werden abgearbeitet.

Schritt 5: Prüfen der Ergebnisse
Das Ergebnis wird geprüft. Der Product Owner sammelt die Rückmeldungen und fasst sie im Product Backlog zusammen.

Schritt 6: Planung des nächsten Sprints
Der nächste Sprint wird geplant und umgesetzt. Dabei müssen nicht nur offene Punkte aus dem vorigen Sprint berücksichtigt werden, sondern auch Änderungen, die im Product Backlog vorgenommen wurden. Überprüfen Sie die erfolgreiche Umsetzung. Nutzen Sie die Checkliste am Ende des Textes und überprüfen Sie, ob Sie bei der Führung in agilen Projekten an alles gedacht haben.

„Wir arbeiten nur noch agil“

Geht es Ihnen ähnlich wie Herrn Schidler? Haben Sie auch schon Projekte nur mit Ach und Krach fertiggestellt? Oder sind Projekte bei Ihnen sogar schon komplett gescheitert? Das liegt nicht selten an den eingesetzten Methoden. Denn klassische Projektmanagement-Methoden sind in vielen Fällen sehr aufwendig. Sie müssen

  • möglichst genau die Anforderungen definieren, z. B. in einem Lastenheft und einem Pflichtenheft.
  • Termine planen.
  • Ressourcen planen.
  • die Planungen im Projektplan festhalten.
  • den Projektplan überwachen und – wenn erforderlich – korrigierend eingreife.

Bei größeren Projekten erfolgen diese Planungen in der Regel auch über einen längeren Zeithorizont, z. B. über mehrere Monate. Und dann darf nichts dazwischenkommen. Wenn z. B. mehrere Mitarbeiter gleichzeitig längerfristig ausfallen oder ein Zulieferer sich nicht an die Vorgaben hält, gerät der Plan schnell ins Wanken. In der Regel müssen Sie in solchen Fällen die Planung neu machen. Noch kritischer wird es, wenn sich während des Projekts die Voraussetzungen verändern, z. B. weil sich technische Vorgaben oder Vorschriften verändern. Hier müssen auch das Lasten- und das Pflichtenheft angepasst werden. Und das führt im Extremfall dazu, dass Sie das Projekt abbrechen und noch einmal komplett neu planen müssen. Das kostet nicht nur viel Zeit, sondern auch viel Geld. An dieser Stelle wird das agile Projektmanagement interessant.

Was ist agiles Projektmanagement?

Agiles Projektmanagement verzichtet weitgehend auf Formalien und entwickelt anstelle eines fertigen Endproduktes in mehreren Wiederholungen Zwischenprodukte, die als Basis für den nächsten Schritt dienen können. Nach jedem Schritt wird das Zwischenprodukt geprüft und wenn erforderlich die Anforderungen angepasst. Damit sind agile Methoden in vielen Fällen nicht nur schneller, sondern auch deutlich flexibler. Denn Änderungen sind ausdrücklich vorgesehen und fester Bestandteil des Prozesses. Das agile Projektmanagement arbeitet dabei nicht nur mit anderen Techniken und Vorgehensweisen, sondern auch mit differenzierten Betrachtungsweisen. So haben funktionsfähige Produkte immer Vorrang vor einer umfangreichen Dokumentation und das Eingehen auf Änderungen steht vor dem strikten Verfolgen des Projektplan.

Agiles Projektmanagement funktioniert in der Regel aber nur dann, wenn das Team – also die Mitarbeiter – selbst Entscheidungen treffen und umsetzen kann. Eine Führungskraft, die auf der exakten Umsetzung des Projektplans besteht und den Mitarbeitern keine Freiheiten und Kompetenzen einräumt, schnell auf Änderungen zu reagieren, erstickt die Vorteile des agilen Projektmanagements im Keim. Außerdem muss das gesamte Team Verantwortung für das Projekt bzw. die Zwischenprodukte übernehmen, und zwar nicht nur für Erfolge, sondern auch für Misserfolge. Dazu ist es wichtig, dass dem Team der Raum für Fehler eingeräumt wird. Diese müssen als Gelegenheit zum Lernen betrachtet werden und nicht als Scheitern. Das Team muss ferner die Möglichkeit haben, Fehler selbst zu korrigieren. Aber auch das Projekt an sich muss passen. Ideal geeignet sind Projekte, bei denen mehrere Zwischenergebnisse möglich sind, z. B. verschiedene Ausbaustufen einer Software, einzelne Kapitel einer Dokumentation o. Ä. Projekte, die sich nicht auf einzelne Zwischenschritte mit klar definierten und prüfbaren Ergebnissen herunterbrechen lassen, sind dagegen nicht geeignet. Woher die verschiedenen Mitarbeiter im Projektteam stammen, darf keine Rolle spielen. Entscheidend sind allein die Qualifikation und die Bereitschaft, im Team mitzuarbeiten. Es muss also möglich sein, das Team abteilungsübergreifend zusammenzustellen und bei Bedarf auch externe Experten einzubinden.

Praxis-Tipp: Achten Sie auf die Teamgröße

Das Team sollte nicht zu groß, aber auch nicht zu klein sein. Die ideale Größe liegt zwischen 5 und 10 Personen. Bei weniger Mitarbeitern fehlt oft das nötige Fachwissen. Bei mehr Mitarbeitern dagegen ist der Abstimmungsaufwand zu hoch.

Selbst-Test: Sind Sie bereit für agiles Projektmanagement?

Mit dem folgenden Selbst-Test können Sie prüfen, ob sich das agile Projektmanagement für Ihr nächstes Projekt eignet.

Auswertung:
Zählen Sie Ihre Kreuze in der Spalte „Ja“ zusammen, und vergleichen Sie Ihr Ergebnis.

0-2Die Voraussetzungen für das agile Projektmanagement sind bei Ihnen noch nicht gegeben. Sie sollten sich nach einer Weiterbildung umsehen.
3-6Sie erfüllen schon eine ganze Reihe von Bedingungen, allerdings sind bei Ihnen noch nicht alle Voraussetzungen gegeben. Prüfen Sie, wo Sie noch Veränderungen durchführen müssen, und wiederholen Sie dann den Test.
mehr als 6Bei Ihnen stimmen die Voraussetzungen. Dem Einsatz des agilen Projektmanagements steht nichts im Wege.

In diesen 6 Schritten führen Sie ein agiles Projekt mit Scrum durch

Eine weitverbreitete agile Methode für das Projektmanagement ist Scrum (engl. Gedränge). Hier erfolgt die Entwicklung mit festgelegten Rollen in mehreren Wiederholungen – den Sprints. Zu Beginn jedes Sprints steht eine Planung. Am Ende jedes Sprints wird das Ergebnis geprüft. Wenn erforderlich, werden auch die Vorgaben für die nächste Wiederholung angepasst. Um ein agiles Projekt mit Scrum durchzuführen, haben sich die folgenden 6 Schritte bewährt: 

Schritt 1: Aufstellen des Teams

In einem Scrum-Projekt müssen immer verschiedene Rollen besetzt werden: der Scrum Master, der Product Owner und das Scrum Team. Der Scrum Master ist vor allem für die Organisation des Projekts verantwortlich. Er stellt sicher, dass Regeln eingehalten werden, und moderiert die Sitzungen des Teams.

Praxis-Tipp: Der Scrum Master ist kein Vorgesetzter

Der Scrum Master soll das Team unterstützen und nicht anleiten oder gar kontrollieren. Daher sollte auch nie ein direkter Vorgesetzter eines Teammitglieds diese Rolle übernehmen.

Der Product Owner steht für den Auftraggeber bzw. den Kunden. Er definiert die fachlichen Anforderungen und prüft, ob diese Anforderungen umgesetzt werden. Er darf dem Team aber keine direkten Anweisungen erteilen. Andernfalls muss der Scrum Master einschreiten.

Praxis-Tipp: Trennen Sie sauber zwischen Product Owner und Scrum Master

Die Rolle des Product Owners und des Scrum Masters sollten nicht von einer Person besetzt werden. Andernfalls drohen Interessenkonflikte, z. B. wenn der Product Owner direkt Einfluss nehmen möchte und kein Scrum Master korrigierend eingreift

Das Scrum Team schließlich kümmert sich um die Umset - zung der Vorgaben. Wie es dabei vorgeht, entscheidet es im Wesentlichen selbst.

Schritt 2: Beschreiben der Anforderung

Wenn das Team steht, definiert der Product Owner seine Anforderungen an die finale Leistung. Diese Anforderungen werden im Product Backlog festgehalten. Eine feste vorgeschriebene Form gibt es dabei nicht. Häufig werden aber User Stories eingesetzt. Sie beschreiben, was ein Kunde oder Klient von dem Projekt erwartet, um ein bestimmtes Ziel zu erreichen, z. B.: „Als Unterstützer des Hilfsprojekts möchte ich nachvollziehen können, wo meine Spendengelder hinfließen. Ich wünsche mir Transparenz und möchte konkrete Ergebnisse sehen.“

Praxis-Tipp: Die Anforderungen müssen nicht sofort vollständig und fehlerfrei sein

Eine Überarbeitung des Product Backlogs – das Product Backlog Refinement – ist ausdrücklich vorgesehen, z. B. wenn sich nach einer Wiederholung herausstellt, dass die Anforderungen nicht exakt passen. Daher müssen die Anforderungen auch nicht sofort perfekt beschrieben werden. Das heißt aber auch nicht, dass die Anforderungen nur vage oder gar unverständlich beschrieben werden dürfen.

Neben der reinen Beschreibung sollten im Product Backlog auch noch der geschätzte Aufwand für die Umsetzung eines Punktes und die Wichtigkeit für den Product Owner hinterlegt werden. Über den Aufwand und die Wichtigkeit können dann Prioritäten gesetzt werden. Ganz oben in die Liste kommen dabei die Einträge, die mit wenig Aufwand umzusetzen sind, aber gleichzeitig eine hohe Wichtigkeit für den Product Owner haben bzw. die Grundfunktionalitäten, die für die Umsetzung zwingend erforderlich sind. So ist es bei einer Schulungsunterlage z. B. wenig sinnvoll, sich mit dem Sachwortregister zu beschäftigen, wenn es noch keine Inhalte gibt.

Der Product Owner entscheidet dann, welche Einträge tatsächlich beim nächsten Sprint umgesetzt werden sollen. Diese Einträge überträgt er aus dem Product Backlog in das Selected Backlog.

Schritt 3: Planung des Sprints

Die Vorbereitung eines Sprints – einer Wiederholung – erfolgt durch das Sprint Planning. Hier wird festgelegt, was wie umgesetzt werden soll. Dazu werden die Einträge aus dem Selected Backlog bei Bedarf weiter in kleinere Aufgaben unterteilt.

Außerdem wird im Sprint Planning ein Ziel für den Sprint festgelegt. Es besteht immer aus einem fertigen Teilergebnis, das auch eingesetzt werden könnte – dem Product Increment. Ob der Einsatz dann tatsächlich erfolgt, entscheidet der Product Owner.

Wie viele Aufgaben nun tatsächlich in einem Sprint angegangen werden, ist nicht festgelegt. Allerdings sollte ein Sprint nicht länger als maximal 30 Tage dauern. Denkbar sind aber auch kürzere Sprints, z. B. mit 7 oder 14 Tagen.

Praxis-Tipp: Planen Sie die Sprints mit einheitlicher Länge

Scrum gibt für die Sprints eine einheitliche Länge vor. Sie sollten also nicht einen Sprint mit 30 Tagen planen und den nächsten dann nur mit 14 Tagen. Auch eine nachträgliche Verkürzung oder Verlängerung ist ausdrücklich nicht vorgesehen. Der Product Owner kann aber einen Sprint abbrechen, z. B. wenn klar ist, dass das Ziel nicht mehr erreicht werden kann.

Die Planung wird im Sprint Backlog festgehalten. Über das Sprint Backlog sind damit auch Vorhersagen möglich, wann welche Zwischenergebnisse zur Verfügung stehen sollten.

Schritt 4: Durchführung des Sprints

Im nächsten Schritt werden die festgelegten Aufgaben abgearbeitet. Der aktuelle Stand wird dabei in der Praxis oft über ein Taskboard festgehalten. Dabei handelt es sich um eine Tafel mit Spalten wie „zu erledigen“, „wird gerade erledigt“, und „erledigt“. Für die einzelnen Aktivitäten werden beschriftete Zettel in die Spalte geklebt, in der sich die Aktivität gerade befindet. Auf diese Weise lässt sich mit einem Blick der aktuelle Bearbeitungsstand erkennen. Außerdem werden Verzögerungen schnell sichtbar, z. B. wenn sich Aktivitäten in der Spalte „wird gerade erledigt“ stauen.

Die Abstimmung während eines Sprints erfolgt über eine tägliche Besprechung – das Daily Scrum. Es findet jeden Tag am selben Termin statt und sollte nicht länger als 15 Minuten dauern.

Schritt 5: Prüfen der Ergebnisse

Nach einem Sprint wird das Ergebnis – das Product Increment – in dem Review geprüft. Die Bewertung erfolgt dabei aber nicht durch das Team, sondern durch den Kunden, dem Träger oder andere Dritte. Der Product Owner sammelt die Rückmeldungen und fasst sie im Product Backlog zusammen. Für die Dauer eines Review sollten Sie nicht mehr als eine Stunde pro Sprint-Woche ansetzen. Bei einer Sprint-Dauer von 14 Tagen ist die maximale Dauer z. B. 2 Stunden.

Das Team selbst prüft seine Arbeit in einer Retrospektive. Hier geht es aber nicht um das Projekt, sondern vor allem um Verbesserungen im Prozess selbst, also z. B. um eine bessere Zusammenarbeit und Organisation. Die Vorschläge werden in einer eigenen Liste dokumentiert – dem Impediment Backlog. Sie können aber auch im Sprint Backlog dokumentiert werden. Für die Dauer der Retrospektive sollten Sie pro Sprint-Woche maximal 45 Minuten ansetzen – bei einer Dauer von 14 Tagen also 1,5 Stunden.

Schritt 6: Planung des nächsten Sprints

Danach wird der nächste Sprint geplant und umgesetzt. Dabei müssen nicht nur offene Punkte aus dem vorigen Sprint berücksichtigt werden, sondern auch Änderungen, die im Product Backlog vorgenommen wurden. Auf diese Weise entsteht Schritt für Schritt ein Endergebnis, das den Anforderungen des Auftraggebers optimal gerecht wird. Da die ständige Neuplanung und auch Anpassung Teile des Prozesses sind, kann sehr schnell auf Änderungen reagiert werden, sei es, weil sie durch äußere Umstände erforderlich sind oder weil der Auftraggeber neue Wünsche äußert.

4 Fallstricke, an denen ein agiles Projekt scheitern kann

Auch wenn agile Methoden sehr viel flexibler sind als klassische Methoden zum Projektmanagement, sind sie keine Garantie für den Erfolg eines Projekts. Um Probleme bei einem agil geführten Projekt zu vermeiden, sollten Sie besonders auf die folgenden 4 Fallstricke achten:

Fallstrick 1: Ein nahezu gescheitertes Projekt wird zu einem agilen Projekt gemacht

Agiles Projektmanagement ist kein Allheilmittel, mit dem Sie jedes Problem in einem Projekt beheben können. Ein klassisch geführtes Projekt, das kurz vor dem Scheitern steht, kann nicht allein dadurch erfolgreich werden, dass Sie es zu einem agilen Projekt machen. Überlegen Sie sich, woher die Probleme kommen, und beheben Sie sie. Prüfen Sie dann, ob sich das Projekt für eine agile Vorgehensweise eignet, und setzen Sie es neu auf.

Fallstrick 2: Es gibt keine klar definierten Zwischenergebnisse

Agile Methoden wie Scrum arbeiten mit Wiederholungen. Für diese Wiederholungen brauchen Sie klare Ziele, die Sie prüfen können. Gibt es diese Ziele nicht, wissen Sie auch nicht, ob das Ergebnis richtig ist oder nicht. Und ohne solch eine Aussage ergibt es wenig Sinn, die nächste Wiederholung einzuleiten.

Fallstrick 3: Das Team hat zu wenig Freiheiten

Das Team muss selbst entscheiden können, wie es vorgeht. Diese Selbstbestimmung ist ein wesentlicher Bestandteil der agilen Methoden. Mischen Sie sich daher als Führungskraft nicht in die Arbeit des Teams ein – auch wenn Ihnen das vielleicht schwerfällt. Übernehmen Sie eine Rolle als Berater, der dem Team hilft und Unterstützung anbietet. Lösungen muss das Team aber selbst finden.

Fallstrick 4: Das Team kann sich nicht selbst organisieren

Die großen Freiheiten, die das Team bei agilen Methoden genießt, führen auch zu viel Verantwortung. Das Team muss sich selbst darum kümmern, dass die Arbeit erledigt wird, und auch interne Abläufe selbst organisieren. Wenn das nicht funktioniert oder ein Teammitglied nicht mitzieht, gerät die Arbeit schnell ins Stocken. Sie sollten daher immer vorher gründlich überlegen, wer in Ihr Scrum-Team passt und über die entsprechende Erfahrung und Persönlichkeit verfügt, die es für den erfolgreichen Einsatz agiler Methoden braucht. Natürlich lassen sich Mitarbeiter auch entsprechend entwickeln. Sie sollten allerdings in Ihrer Planung berücksichtigen, dass eine solche Mitarbeiterentwicklung Zeit braucht.

Wenn Sie die vorgenannten 8 Punkte berücksichtigen, können agile Methoden ihre Vorteile voll entfalten und bieten eine echte Alternative zu klassischen Methoden.

Organisation & Zeitmanagement

Erhalten Sie mit "Organisation & Zeitmanagement" Organisationstipps für ein effizientes Zeitmanagement im Beruf kostenlos per E-Mail.

Herausgeber: VNR Verlag für die Deutsche Wirtschaft AG
Sie können den kostenlosen E-Mail-Newsletter jederzeit wieder abbestellen.

Datenschutz
Ähnliche Beiträge

| Mark Schmolke - Sie kennen das? Ein Projekt läuft und läuft, und entweder dauert es viel länger, als alle gedacht haben, oder es wird teurer oder bringt am Ende gar... Artikel lesen

| Günter Stein - Sie brauchen sicher nicht bei jeder kleinen Meinungsverschiedenheit den Schlichter zu spielen. Doch bestimmte Verhaltensweisen sind symptomatisch für... Artikel lesen

| Dr. Matthias Pfeffer - Projekte, Projekte und noch mehr Projekte. Dass der Anteil der Projektarbeit an der Gesamtwertschöpfung weiter rasant zunehmen wird, erscheint... Artikel lesen

| Günter Stein - Delegieren oder lieber selbst tun? Diese Fragen haben Sie sich sicher schon häufiger gestellt. Und Sie wissen es selbst – als erfolgreiche... Artikel lesen