Claus Kolb

IT Projektmanagement


Auf meinem Blog berichte ich regelmäßig von meinen Erfahrungen aus Kundenprojekten. Folgen Sie mir auf Twitter, um über neue Artikel informiert zu werden.

Projektmanagement 2.0 (Teil 3): Vom klassischen zum agilen Projektleiter

Juli 8, 2014Claus Kolb0 Kommentare

Im letzten Artikel habe ich angefangen, eine Projektorganisation zu beschreiben, in der die Projektmanagementaufgaben zwischen den Rollen des Product Owners, Scrum Masters, des Teams und des agilen Projektleiters aufgeteilt werden. Diese Beschreibung vervollständige ich in diesem Artikel.

Projektcontrolling

Das Controlling des Projekts hinsichtlich Kosten, Leistung, Qualität und Zeit ist eine Aufgabe, die sehr gut vom agilen Projektleiter übernommen werden kann. Wie im letzten Artikel beschrieben, hat der Product Owner eine Produkt- und keine Projektperspektive, so dass der agile Projektleiter prädestiniert für diese Aufgabe ist.

Kosten

Die Kostenplanung muss bereits in der Projektinitiierung betrachtet und fortlaufend aktualisiert werden. Wenn in vielen nicht-agilen Abteilungen (hohe) Kosten anfallen (z. B. für Hardware oder Lizenzen, Dienstleister), bedarf es einer koordinierenden Instanz in Form des agilen Projektleiters.

Leistung und Qualität

Die Sprint- und Releaseplanung und die damit verbundene Leistungskontrolle obliegen dem Product Owner. Die Qualität des erstellten Systems wird vom Development Team verantwortet. Lediglich die Leistungs- und Qualitätskontrolle in nicht-agilen Bereichen verbleibt beim Projektleiter.

Zeit

Das Controlling der Termine ist auf drei Rollen verteilt. Der Product Owner ist für die Sprint- und Releaseplanung und deren Kontrolle und Aktualisierung verantwortlich (s. Teil 2). Der Scrum Master und das Development Team sind verantwortlich, dass die Sprintanfangs- und -endtermine eingehalten werden. Der agile Projektleiter erstellt und kontrolliert die Projektphasen- und Meilensteinplanung.

Kommunikations- und Berichtswesen

Meetings

Scrum gibt mit dem Sprint Planning, Sprint Review, der Sprint Retrospective und dem Daily Scrum eine Reihe von Meetings bereits vor. Diese Meetings dienen der Abstimmung innerhalb des Scrum Teams. Eine Projektsicht existiert in diesen Meetings nicht, so dass ggf. weitere Meetings notwendig sind, um die Projektteilnehmer aus nicht-agilen Abteilungen einzubinden. Diese Meetings zu organisieren und durchzuführen, liegt in der Verantwortung des agilen Projektleiters.

Reporting

Das Reporting des Fortschritts in der Entwicklung obliegt dem Scrum Master. Darüber hinaus gibt es in Unternehmen oftmals vielfältige Anforderungen hinsichtlich des Projektstatusreportings. Das Sprint-Reporting wird vom agilen Projektleiter aggregiert, um den Status anderer nicht-agiler Abteilungen ergänzt und in entsprechenden Statusmeetings präsentiert.

Lenkungsausschuss

Ein Lenkungsausschuss überwacht i.d.R. den Fortschritt eines Projektes und wird in regelmäßigen Meetings über den aktuellen Stand informiert. Auch diese Meetings werden vom agilen Projektleiter vorbereitet und durchgeführt. Der Lenkungsausschuss entscheidet u.a. über Budgetänderungen (s. u.).

Änderungsmanagement

Traditionelle Change Requests in Bezug auf die zu entwickelnde Software gibt es in Scrum-Projekten nicht mehr. Change Requests in Bezug auf das gesamte Projekt sind aber nach wie vor existent und werden vom agilen Projektleiter verwaltet. Führen (gänzlich) neue Anforderungen dazu, dass das Projektbudget erweitert werden muss, können diese sehr wohl in Form von Change Requests auf Projektebene definiert werden. Diese haben Auswirkungen auf das Budget, die Projektdauer und/oder den Leistungsumfang des Projekts. Über Change Requests entscheidet i.d.R. der Lenkungsausschuss (s. o.).

Projektmarketing

Der Product Owner verantwortet die Produktvision und vertritt sie im Unternehmen. Dahingegen ist der agile Projektleiter für das Projekt zuständig. Dementsprechend obliegt dem agilen Projektleiter auch das Marketing in Bezug auf das Projekt.

Risikomanagement

Das Risikomanagement ist auch in sequentiellen Projekten eine oftmals vernachlässigte Disziplin. Gerade in komplexen Projekten besteht hier ein wichtiges Aufgabengebiet des agilen Projektleiters.

Mitarbeiterführung

Gerade in Bezug auf die Mitarbeiterführung ergeben sich bei der Einführung von Scrum große Veränderungen.

Arbeitspakete (direkt) zuweisen

Diese Aufgabe des klassischen Projektmanagements fällt in Scrum komplett weg. Der Product Owner verwaltet die Anforderungen und stellt dem Team einen Teil davon zum Sprint Planning vor. Das Team entscheidet selbst, welche User Stories es für die Sprints akzeptiert. Ggf. übernimmt der agile Projektleiter die Zuweisung von Arbeitspaketen zu Mitarbeitern, die in nicht-agilen Bereichen arbeiten.

Konfliktmanagement, Team- und Motivationsmanagement, Sicherstellung guter Arbeitsbedingungen

Der Scrum Master übernimmt die o.g. Aufgaben für das Scrum Team. Die Sicherstellung guter Arbeitsbedingungen (auch das „Beseitigen von Impediments“ genannt) ist eine Hauptaufgabe des Scrum Masters. Jenseits des Scrum Teams ist der agile Projektleiter für diese Aufgaben zuständig.

Projektabschluss/Review

Ein Review der eigenen Vorgehensweise erfolgt im Scrum Team in der Sprint Retrospective, die durch den Scrum Master organisiert wird. Allerdings bezieht sich dieses Review nicht auf das Projekt, in dem das Scrum Team eingebunden ist. Die regelmäßige Verbesserung des Projektvorgehens liegt im Verantwortungsbereich des agilen Projektleiters. Auch hier sollte der Projektleiter nicht erst am Ende des Projekts ein solches Review durchführen, sondern auf begleitende, regelmäßige Reviews setzen.

Zusammenfassung

Die folgende Tabelle fasst die Ausführungen dieses und des letzten Blogartikels in einer Übersicht zusammen.

Tabelle 1: Aufgabenverteilung

Tabelle 1: Aufgabenverteilung

Ich habe eine Projektorganisation beschrieben, in der auch der agile Projektleiter neben dem Scrum Master und Product Owner vertreten und mit sinnvollen Aufgaben betraut ist. Die Projektmanagementstandards müssen an diese Vorgehensweise angepasst werden und ingesamt leichtgewichtiger werden. Einen solchen Standard habe ich bswp. in diesem Projekt mitentwickelt und eingeführt.

Die Anzahl und der Umfang der Aufgaben des agilen Projektleiters sinken im Vergleich zur klassischen Vorgehensweise. Die Führungsspanne in Bezug auf Anzahl und Größe der Projekte von agilen Projektleitern kann dementsprechend steigen. Komplexitätssteigernd und arbeitsintensiver für den agilen Projektleiter wird es, wenn mehrere Entwicklungsteams beteiligt sind oder sogar mehrere IT-Systeme/-Produkte im Projekt geändert werden müssen. Auch Mischungen von agilen und klassischen Teilprojekten erhöhen den Arbeitsaufwand des Projektleiters.

Im nächsten Blogartikel werde ich beschreiben, wie eine Scrum-Projektorganisation ohne einen Projektleiter aussehen kann.

Weiterlesen


Eine Antwort eingeben