Projektmanagement und Scrum

Die Stärken von klassischem und agilem Projektmanagement

Projekte sind kreative und in der Regel recht komplexe Vorhaben. Kreativ, weil sie etwas Neues schaffen, das vorher noch nicht existierte. Sei es ein neues Produkt, ein neues Verfahren oder eine neue Organisation. Komplex, weil unterschiedlichste Aufgaben zu bewältigen sind und verschiedenste Menschen und Systeme zusammenarbeiten müssen, die so vielleicht noch nie zusammengearbeitet haben.

Derzeit gibt es zwei vorherrschende Vorgehensweisen für das Projektmanagement, die klassische und die agile. Eine verbreitete klassische Projektmanagementmethode ist z. B. das Vorgehen nach dem Project Management Body of Knowledge (PMBOK) des PMI. Eine typische agile Methode ist z. B. Scrum, wie es u. a. von der ScrumAlliance propagiert wird. Grundsätzlich sind beides erfolgreiche und in zahllosen Projekten bewährte Methoden. Entsprechende Zertifizierungen sind der Project Management Professional (PMP) des PMI und der Certified ScrumMaster der ScrumAlliance.

Welches die richtige oder bessere Vorgehensweise für ein bestimmtes Projekt ist, lässt sich nur von Fall zu Fall entscheiden.

Wenn Sie sich die Frage stellen, ob Sie Ihr nächstes Projekt klassisch oder agil durchführen sollen, dann hilft es Ihnen vielleicht, sich den wesentlichen Unterschied der beiden Vorgehensweisen vor Augen zu führen. Weil niemand in die Zukunft sehen kann, ist jedes Projekt mit Risiken verbunden. Klassische und agile Projektmanagementmethoden unterscheiden sich im Wesentlichen darin, wie sie mit Projektrisiken umgehen. Das will ich kurz erläutern.

Ziel

Mit einem Projekt soll in gegebener Zeit und mit endlichen Ressourcen ein bestimmtes Ziel erreicht werden. Z. B. den Umsatz eines Softwarehauses mittels der Entwicklung und Vermarktung einer neuen Software zu steigern. Oder die Produktivität eines Unternehmens mittels der Etablierung neuer Prozessabläufe zu verbessern. Das Projektziel (engl. Objective) ist der Grund, warum das Projekt durchgeführt wird.

Sponsor

Für jedes Projekt gibt es einen Auftraggeber oder Sponsor, der die Ziele des Projekts festlegt und die benötigten Ressourcen zur Verfügung stellt. Das können auch mehrere Personen gemeinsam sein. Der Sponsor ist die oberste Entscheidungsinstanz im Projekt.

Erfolg

Ein Projekt ist dann erfolgreich, wenn das vom Sponsor beabsichtigte Ziel erreicht wird.

Erwartete Ergebnisse

Das Ziel eines Projekts ist nicht identisch mit dem herzustellenden Ergebnis eines Projekts. Z. B. ist in obigem Beispiel die Umsatzsteigerung des Softwarehauses das Ziel, das Mittel dazu ist eine neue Software. Die Aufgabe des Projekts ist es, diese Software zu entwickeln, also die Mittel zu schaffen, mit denen das Projektziel erreicht werden kann. Diese Mittel, die Projektergebnisse (engl. Deliverables) können neue Produkte, Forschungserkenntnisse, Dienstleistungsangebote, Arbeitsabläufe oder Organisationsstrukturen sein, um nur einige Beispiele zu nennen. Der Unterschied zwischen Ziel und Ergebnissen eines Projekts ist wichtig, denn das gleiche Ziel kann oft mit unterschiedlichen Mitteln erreicht werden. Zu analysieren, mit welchen Mitteln das Ziel am besten erreicht wird, ist eine der Aufgaben des Projekts.

Der wesentliche Unterschied zwischen klassisch und agil

Per Definitionem unterliegen alle Projekte einem grundsätzlichen Problem. Einerseits schafft ein Projekt etwas Neues, noch Unbekanntes. Es gibt also noch keine exakten Erfahrungswerte, wie viel Zeit und Ressourcen tatsächlich für das Projekt benötigt werden und ob das Projektergebnis wirklich geeignet ist, das Projektziel zu erreichen. Andererseits soll das Projektziel aber zu einem festen Zeitpunkt in der Zukunft erreicht werden, und es stehen dazu nur begrenzte Ressourcen dafür zur Verfügung.

Daraus ergibt sich ein Widerspruch. Einerseits kann das Projektergebnis umso sicherer geliefert werden kann, umso mehr Zeit und Ressourcen man für seine Erstellung einplant. Andererseits wird das Projektziel aber umso wahrscheinlicher verfehlt, je später es erreicht wird und umso mehr Ressourcen es verschlingt, die möglicher Weise nicht mehr durch den erzielten Nutzen zu rechtfertigen sind. Projektergebnis und Projektziel stehen also in einem konflikthaften Verhältnis zueinander. Das eine absichern, heißt womöglich, das andere gefährden.

Der wesentliche Unterschied zwischen klassischem und agilem Projektmanagement liegt darin, wie sie mit diesem Widerspruch und damit mit den Projektrisiken umgehen.

Klassisches Risikomanagement

Das klassische Projektmanagement plant Projekte von Anfang bis Ende detailliert durch. Das heißt, dass zu Projektbeginn Entscheidungen darüber getroffen werden, wie das Projektergebnis aussehen soll, um das Projektziel zu erreichen und wie viel Zeit und Ressourcen benötigt werden, um das Projektergebnis zu erstellen. Im Projektverlauf kann sich aber zeigen, dass diese Annahmen revidiert werden müssen:

In solchen Fällen müsste der Projektplan korrigiert werden. Um den Aufwand, der durch Korrekturen entsteht, zu minimieren, analysiert man im klassischen Projektmanagement die Unwägbarkeiten und Risiken des Projekts fortlaufend, plant Maßnahmen zur Risikominimierung ein und betreibt ein minutiöses Change-Management, damit Zeit und Ressourcen kostende Änderungen am ursprünglichen Plan nur vorgenommen werden, wenn sie unabdingbar sind.

Agiles Entwickeln in Sprints

Mit dem agilen Vorgehen wurde ein alternativer Weg gefunden, mit Projektrisiken und Unwägbarkeiten umzugehen. Man zerlegt das Projektergebnis in eine Anzahl aufeinander aufbauender Zwischenergebnisse, wovon jedes für sich bereits einen eigenständigen Nutzen erbringt, z. B. indem es als Produkt mit reduziertem Funktionsumfang auf den Markt gebracht werden kann. Jedes Zwischenergebnis wird in einem 3-4 Wochen dauernden Sprint erstellt. Statt eines Gesamtprojektplans wird ein Product Backlog erstellt, das den vollen Funktionsumfang des erwarteten Projektergebnisses beschreibt. Das Product Backlog kann sich während des Projekts fortlaufend ändern, wenn neue Erkenntnisse es erfordern und zu einer Modifikation des erwarteten Projektergebnisses führen. Für jeden Sprint wird aus dem Product Backlog ein Sprint Backlog extrahiert, das die Funktionen enthält, die in dem jeweiligen Sprint realisiert werden sollen.

Da beim agilen Vorgehen kein Gesamtprojektplan erstellt wird und obendrein sich das Product Backlog im Projektverlauf ändern kann, kommt es vor, dass Ergebnisse früherer Sprints sich nicht mehr optimal in späteren Sprints weiterverwenden lassen. In solch einem Fall müssen die früheren Ergebnisse entsprechend den neuen Anforderungen um- oder neugestaltet werden. Diese Umgestaltungen nennt man Refactoring. Refactoring ist ein wesentliches Korrekturinstrument eines jeden agilen Projekts und ein unverzichtbares Element agiler Methoden. Es setzt eine entsprechend flexible technische Architektur voraus.

So wie im klassischen Projektmanagement Änderungen am ursprünglichen Plan in der Regel zusätzliche Zeit und Ressourcen kosten, kostet auch im agilen Vorgehen das Refactoring zusätzlich Zeit und Ressourcen.

Vergleicht man klassisches und agiles Vorgehen, so zeigt sich also, dass beide dasselbe Problem auf unterschiedliche Weise lösen. Was für das klassische Projektmanagement das Risiko-Management ist, ist für die agile Vorgehensweise die Aufteilung in Sprints (frühes Erkennen von Abweichungen oder Risiken). Dem Change-Management im klassischen Projektmanagement entspricht das Refactoring der agilen Vorgehensweise (notwendige Änderungen durchführen).

Beides kostet in der Regel Zeit und Ressourcen und ist der kreativen Natur von Projekten geschuldet. Daran kann weder die klassische noch die agile Vorgehensweise etwas ändern. Sie unterscheiden sich nur in der Art, wie sie dem Problem begegnen. In manchen Fällen ist die eine Vorgehensweise effektiver, in anderen die andere. Welche Vorgehensweise für welches Projekt jeweils die beste ist, kann nur von Fall zu Fall aufgrund der jeweiligen Umstände entschieden werden. Dafür gibt es einige wichtige Kriterien, u. a. Time to Market und Skalierbarkeit.

Time to Market

Agile Verfahren sind der Traum aller Marketingabteilungen. Wenn es darum geht, ein Produkt möglichst schnell auf den Markt zu bringen, Bewertungen und Kommentare von Benutzern einzuholen, das Produkt entsprechend dieses Feedbacks weiterzuentwickeln und in schneller Folge verbesserte Produktmodelle auf den Markt zu bringen, sind agile Methoden wie Scrum in ihrem Element.

Das gilt besonders für ganz neue, innovative Produkte und Dienste, bei denen man nicht von vornherein weiß, welche Funktionen und welches Design bei den Kunden am besten ankommen oder wie die Kunden das Produkt genau benutzen werden. Und natürlich für Produkte, deren Anforderungen sich schnell verändern. Statt in langlaufenden Projekten am Kunden vorbei zu entwickeln ist es in diesen Fällen sinnvoller, kontinuierlich Feedback von den Benutzern einzuholen und sofort in die Weiterentwicklung des Produkts einfließen zu lassen.

Schnelles Ausprobieren-und-Verbessern mit kurzen Innovationszyklen ist in den genannten Fällen meist erfolgreicher als langwierige, vorab durchgeführte Markt- und Anforderungsanalysen.

Wegen des großen Gewichts umfangreicher Planungsunterlagen und technischer Konzepte führt das klassische Projektmanagement hier in der Regel zu längeren Vorlaufzeiten, bevor ein Produkt erprobt werden kann.

Skalierbarkeit

Projekte, die mehr als zwei, drei Dutzend Teammitglieder erfordern, können schnell sehr unübersichtlich werden und dazu führen, dass die rechte Hand nicht mehr weiß, was die linke tut. Hier schlägt die Stunde des klassischen Projektmanagements. Es lässt sich beliebig skalieren, ohne dadurch chaotisch zu werden oder den Kommunikations- und Koordinationsaufwand exponentiell anwachsen zu lassen. Sobald ein Team zu groß wird, um von einem Projektmanager geleitet zu werden, richtet man Teilprojekte mit Teilprojektleitern ein, die dann wiederum das Projektmanagementteam mit einem Gesamtprojektleiter bilden usw. Die Projektorganisation bleibt für alle Beteiligten verstehbar und die Methoden des Projektmanagements bleiben auf allen Ebenen die gleichen.

Nicht alle Produkte lassen sich in Iterationen von wenigen Wochen entwickeln und auf den Markt bringen. Mit klassischen Projektmanagementmethoden wurden erfolgreich Ölplattformen erstellt, umfangreiche Softwaresysteme für Mobilfunknetze entwickelt, neue Medikamente entwickelt und Menschen auf den Mond gebracht. Bei solchen Projekten geht es eher um Jahre als um Monate. Dafür ändern sich die Produktanforderungen auch nicht so schnell. Hier liegt die Stärke des klassischen Projektmanagements, trotz aller Unwägbarkeiten langfristig für die Zukunft zu planen und systematisch auf Risiken und Anforderungsänderungen zu reagieren.

Man darf sich durch die mediale Aufmerksamkeit, die Krisen in Großprojekten wie dem Berliner Flughafen hervorrufen, nicht täuschen lassen. Scheitern ist kein Privileg klassischer Projekte. Viele kleine Start-Ups und Mittelständler, die Produkte mit agilen Methoden am Markt vorbei entwickeln, gehen sang- und klanglos unter, auch wenn der ökonomische Verlust in der Summe nicht geringer ist.

Da agile Methoden mehr Wert auf funktionierenden Code als auf umfangreiche Dokumentationen legen, funktionieren sie mit festen Teams, die lange gemeinsame Entwicklungserfahrungen in ihrem Anwendungsgebiet haben, am besten. Sobald Projekte skaliert werden müssen, Dutzende oder Hunderte von Personen in einem Projekt zusammenarbeiten, kurzfristig neue Teams in großem Umfang in das Projekt eingebunden werden sollen, haben agile Projekte erhebliche Probleme, das System-Know-How und die angewendeten Entwicklungs-Methoden und Erfahrungen an neue Teammitglieder weiterzugeben.

Team-Management

Es soll nicht verschwiegen werden, dass das Team-Management der gemeinsame Schwachunkt des klassischen und des agilen Projektmanagements ist. Vielleicht liegt es daran, dass Projektmanager und ScrumMaster eher Techniker als Psychologen sind. Im klassischen Projektmanagement, z. B. nach PMI, beruft man sich noch immer auf psychologische Theorien der 1930er bis 50er Jahre, in denen Menschen mittels Motivationsstrategien zum Arbeiten angehalten werden sollen. Nur funktionieren Teams nicht nach diesem einfachen Der-Team-Leader-motiviert-sein-Team-Modell. Die agilen Methoden setzen dagegen auf sich selbst organisierende Teams, ohne aber genauer zu beschreiben, wie sie sich denn am besten organisieren sollen. Letztendlich bleibt damit in beiden Methoden das Teammanagement dem Geschick und der Persönlichkeit des Projektmanagers oder ScrumMasters und der Zusammensetzung des Teams überlassen, also - dem Zufall.

Team-Management bleibt ein Feld der Forschung und des Erfahrungsaustauschs in der Projektmanagement-Community. Als Informatiker und Psychologe berate ich Unternehmen zu den Themen Projektmanagent, Agile Methoden und Team-Management.

Was ich sonst noch mache

Neben meiner Arbeit als Projektmanager entwickle ich Software für mobile Endgeräte.

Meine Kunden sind Mobilfunknetzbetreiber, Diensteanbieter, Endgerätehersteller und Systemintegratoren.




Regierungsviertel in Berlin mit
Spree, Tiergarten, Bundeskanzleramt, Abgeordnetenbüros, Bundestag, Brandenburger Tor, Unter den Linden, Friedrichstraße und Museumsinsel

Ein Bild sagt mehr als tausend Worte. Sie können sich meine Beispielanwendung ansehen, mit der sich online Stadtpläne, Landkarten und Satellitenbilder (siehe oben) erstellen lassen.

Software-Systeme entwickle ich für die Platformen