Methoden des agilen Projektmanagements
Ausgehend von Modellen für die Softwareentwicklung macht seit Ende der 1990er-Jahre ein ganz neuer Ansatz im Projektmanagement die Runde, das agile Projektmanagement. Dabei erfolgt die Zusammenarbeit in kurzen Planungszyklen mit flachen Hierarchien und hoher Flexibilität. Anders als bei klassischem Projektmanagement wird der gewünschte Ausgang eines Projekts nicht vorab definiert, sondern laufend erarbeitet.
Agiles Projektmanagement hat sich innerhalb kurzer Zeit weit verbreitet, vor allem bei der Softwareentwicklung. Laut einer Umfrage des Marktforschungsinstituts Forrester Research griffen 2005 nur 14 Prozent aller Unternehmen auf agile Methoden bei der Erstellung von Software zurück. 2013 betrug diese Zahl laut einer Studie des Unternehmens VersionOne schon 84 Prozent. Aktuell (2018) nutzen 97 Prozent aller Unternehmen agile Methoden für die Softwareentwicklung. Zumindest im Software-Bereich führt heute also kaum ein Weg mehr an agilem Projektmanagement vorbei. Aber auch in anderen Unternehmensbereichen ist es inzwischen fest verankert, wie beim Lesen von Stellenanzeigen für Projektmanager schnell klar wird.
Einfache Spielregeln für agile Projekte: Scrum
Eine zentrale Rolle bei der Anwendung von agilem PM nimmt oft Scrum ein. Der englische Begriff bedeutet auf Deutsch „Gedränge“ und ist einer Spielsituation beim Rugby entnommen. Bei Scrum handelt es sich um eine Struktur, mit der das gesamte Team nach agilen Prinzipien arbeitet. Die Arbeit wird dabei in kurze Abschnitte eingeteilt, sogenannten Sprints. Ein Sprint dauert zwischen einer und vier Wochen. Vor jedem Sprint definiert das Projektteam ein Ziel, das es im laufenden Sprint nicht mehr ändern darf.
Jedes Mitglied eines Scrum-Teams hat eine von drei definierten Rollen. Der Product Owner hat die Verantwortung für die Gestaltung des Produkts und legt die Produkteigenschaften fest. Beim Product Owner handelt es sich immer um eine Einzelperson, nicht um eine Gruppe.
Statt eines klassischen Projektmanagers steht einem Scrum-Team ein Scrum Master zur Seite. Dieser agiert mehr wie ein Moderator als wie ein Manager. Seine Aufgabe ist es, Störungen aus dem Weg zu räumen, damit das Team ungehindert arbeiten kann. Er ist es auch, der die Scrum-Regeln einführt und ihre Einhaltung überwacht. Der Scrum-Master agiert lediglich als dienende Führungskraft und gibt den Teammitgliedern keine Arbeitsanweisungen.
Alle anderen Beteiligten an einem Scrum-Projekt gehören zum Team. Teammitglieder müssen sehr eigenverantwortlich und flexibel arbeiten. Sie müssen bereit sein, ihre gewohnten Rollen in der Unternehmenshierarchie zu verlassen und unabhängig davon ihre Arbeitskraft zur Erreichung des Sprint-Ziels einzusetzen. Die Zusammensetzung eines Sprint-Teams ist interdisziplinär, damit es möglichst unabhängig arbeiten kann.
Der Ablauf von Scrum gestaltet sich relativ simpel. Abgesehen von den drei Rollen Product Owner, Scrum Master und Entwickler gibt es nur wenige Fixpunkte. In einem Product Backlog werden die Anforderungen an das Endprodukt festgehalten. In Sprint Backlogs definiert das Team, was es in jedem einzelnen Sprint erreichen will. Am Ende jedes Sprints steht ein lieferfähiges Produkt, das Inkrement. Jedem Sprint geht eine Planungsphase voran, an seinem Ende steht eine Retrospektive. Zudem bespricht das Team in kurzen Stehmeetings, den Daily Scrums, täglich den aktuellen Projektfortschritt.
Nützliche Kärtchen: Kanban
Neben Scrum ist Kanban eines der wichtigsten Frameworks für das agile Projektmanagement. Die Methode stammt ursprünglich aus dem Ressourcen-Management für die Produktion. In den 1940er-Jahren wurde sie beim japanischen Automobilhersteller Toyota von Ōno Taiichi (大野 耐) entwickelt. Kanban im Projektmanagement übernimmt einige grundlegende Prinzipien daraus, stellt aber keine direkte Übertragung der Methode aus der Produktion in das Projektmanagement dar.
Das japanische Wort Kanban (看板) bedeutet „Karte“ beziehungsweise „Beleg“. Kleine Kärtchen beziehungsweise Tickets, oft Post-its, sind ein wesentliches Werkzeug der Kanban-Methode. Sie repräsentieren jeweils einen Arbeitsschritt. Auf einer Kanban-Tafel, üblicherweise einem Whiteboard, werden sie in verschieden Spalten angeordnet, die die einzelnen Produktionsstufen darstellen. Diese entsprechen häufig den Stufen des im traditionellen Projektmanagement beliebten Wasserfallmodells, jedoch unterscheiden sich die beiden Vorgehensweisen grundlegend.
Während im Wasserfallmodell eine Stufe vollständig abgeschlossen sein sollte, bevor die nächste beginnt, ist das Kanban-System darauf angelegt, dass jedes Ticket möglichst schnell alle Stufen durchläuft. Eine Begrenzung der Anzahl der aktuell bearbeiteten Tickets verhindert, dass sich das Team durch ineffizientes Multitasking ausbremst.
Ob Scrum oder Kanban eigesetzt wird, ist keine Entweder-oder-Frage. Viele Projektmanager betrachten Kanban als eine unter mehreren möglichen Umsetzungen von Scrum. Die beiden Methoden ergänzen sich und sind miteinander kombinierbar. Während bei Scrum das Hauptaugenmerk auf der Zusammenarbeit im Team liegt, geht es bei Kanban vor allem um die Wertschöpfungskette.
Burn-down-Charts messen den Projektfortschritt
Burn-down-Charts sind Diagramme, die das Verhältnis der noch zu erledigenden Arbeit zur verbleibenden Zeit zeigen. Im agilen Projektmanagement kommen sie häufig vor. Prinzipiell eigenen sie sich jedoch für jedes Projekt, in dem der Fortschritt im Zeitverlauf messbar ist.
Die X-Achse eines Burn-down-Charts ist die Zeitachse, die Y-Achse zeigt den verbleibenden Arbeitsaufwand. Dafür sind zwei verschiedene Methoden gängig: Entweder wird der Arbeitsaufwand als Summe des geschätzten Zeitaufwands der verbleibenden Aufgaben oder als Anzahl der verbleibenden Aufgaben vermerkt.
Vom Startpunkt des Burn-down-Charts links oben (keine Aufgabe ist erledigt, die gesamte Projektzeit steht noch zur Verfügung) bis zu seinem Endpunkt rechts unten (alle Aufgaben sind erledigt, die Projektzeit ist abgelaufen) führt eine Linie, die den idealen Burn-down darstellt. Liegt die tatsächliche Burn-down-Linie über dieser Ideallinie, ist mehr Arbeit übrig als veranschlagt. Dann hinkt das Projekt dem Zeitplan hinterher. Liegt die Burn-down-Line unter der Ideallinie, ist weniger Arbeit übrig als veranschlagt, und das Projekt macht schnellere Fortschritte als geplant.
