· 

Wie ist die Zukunft eines traditionellen Projektleiter im agilen Umfeld?

Bei agilen Projekten wird nicht nur die Betrachtungsweise des magischen Dreiecks* auf den Kopf gestellt, sondern auch die Rollen und damit zusammenhängende Aufgabenverteilung.

 

Das agile Umfeld, das versucht komplexe Probleme zu lösen und Innovationen hervorzubringen, lebt von Mitarbeitern, die Lust haben sich einzubringen und miteinander Neues zu erschaffen. Da passt die Vorgehensweise eines klassischen Projektleiters, der von oben die klare Ansagen macht und die Entscheidungen vorgibt, nicht mehr dazu. 

 

* Durch das Umdrehen des magischen Dreieckes erfolgt der Wechsel von der Planorientierung zur Wertorientierung. Dabei sind Zeit und Kosten die fixen Bestandteile und der Inhalt ist der einzig variable Faktor, um keine Abstriche bei der Qualität zu haben. Eine Auswirkung ist, dass es kein Change Management für Anforderungsänderungen mehr notwendig ist, da sich der Inhalt explizit ändern darf.

 

Klassischer Projektleiter
Das Vorgehen eines klassische Projektleiters hat seine Stärken bei sequentiell ablaufenden Prozessen, wie es beim Wasserfall und V-Modell der Fall ist. Vom klassischen Projektleiter wird häufig fachliches Know-how in der Anwendungsdomäne und/oder technisches Wissen in den verwendeten Technologien erwartet. Der Schwerpunkt eines Projektleiters ist das managen es Projektes und das Übernehmen der Verantwortung für die Einhaltung des Projektplanens durch folgende Aufgabe: 
  • Verantwortet das Projektbudget.
  • Verantwortet den Zeitplan.
  • Kann entscheiden, wann was gemacht wird.
  • Verantwortet korrektes Reporting.
  • Verantwortet Risikomanagement.
Der Führungsstil ist dabei in der Regel eher autoritär mit Command & Control. Der Faktor Mensch und bestehende Team-Dynamiken spielen hier meistens eine untergeordnete Rolle. Je nach Umfeld hat der Projektleiter auch gar keine Zeit sich genau um solche Sachen zu kümmern.

Rollen in Scrum

Im agilen Framework Scrum werden die Aufgaben auf die Rollen Product Owner und Scrum Master aufgeteilt. Jede Rolle mit einem eigenen Fokus, aber gegenseitig ergänzend. Beide sind Teil des Scrum Teams und sind laterale Führungskräfte (Leader), d.h. sie haben keine Weisungsbefugnis und führen kooperativ mittels Mentoring und/oder Coaching. 

Scrum Master Product Owner

Fokus: Prozess und Mensch 

  • Verantwortlich für die korrekte Umsetzung und Einhaltung des Scrum Frameworks, Moderiert Meetings.
  • Vermittler und Unterstützer, ermöglicht Informationsfluss zwischen Team und Product Owner.
  • Beseitigt Hindernisse und schützt das Team vor unbefugten Eingriffen.

Fokus: Produkt und Markt

  • Business orientierte Person, die für die Wertmaximierung des Produktes verantwortlich ist.
  • Pflege und Periodisierung des Produkt Backlogs anhand einer Vision.
  • Vertritt Kundensicht und ist für Stakeholder Management.

 

Die Gegenüberstellung zeigt, das die Rolle des Projektleiters im Scrum Umfeld nicht mehr vorgesehen ist und sich seine Aufgaben auch dort nicht mehr direkt widerspiegeln, wie die nächste Auflistung ebenfalls veranschaulicht.

 

Scrum Master und PRODUCT OWNER vs. Projektleiter

Bei folgenden Zuständigkeiten unterscheiden sich Scrum Master und Product Owner vom Projektleiter:

  • Der klassische Projektleiter fungiert als Schnittstelle zwischen den Fachbereichen und dem Entwicklungsteam. Der Scrum Master hingegen hilft dem Product Owner durch Coaching in seiner Funktion als „Produktentwickler“, der auch im Rahmen des Stakeholder Management die Abstimmungen übernimmt.
  • Projektleiter müssen in der Regel Rechenschaft über die Leistungen des Teams abgeben. Der Scrum Master ist der nächsten Managementebene nur bezüglich Produktivität verpflichtet. Für die Qualität des Produkts und für die pünktliche Lieferung ist der Produkt Owner und das Entwicklungsteam verantwortlich. Ein Scrum Master erstellen keine Status-Reports für das Management.
  • Der Projektleiter ist meist der Mitarbeiter mit dem größten technischen Verständnis und dem umfangreichsten Produkt-Know-how. Dieses sogenannte Domänen Wissen ist auch für die Rolle des Product Owners wichtig, so dass diese Rolle dem Projektleiter am nächsten ist. Der Scrum Master hingegen muss dieses Wissen nicht mitbringen, sondern eher sogenannte Soft Skills wie beispielsweise Empathie besitzen.

Diese Thematik wurde auch schon mehrmals  während dem agilen Stammtischen in Lindau heiß diskutiert. Auch auf einschlägigen Seiten für agiles Projektmanagement wird die Rolle des agilen Projektleiters als ein passendes Bindeglied vorangetrieben und in vielen Fällen dem Scrum Master gleich gesetzt.

 

Ich persönlich empfinde diesen Diskussion als nicht zielführend. Wenn sich ein Unternehmen in einem VUCA Umfeld bewegt, sollte es den Mut haben sich mit allen Konsequenzen zur Agilität (als Haltung und Methode) zu bekennen und keine unnötigen Mischform zulassen. Ich habe bisher noch kein Umfeld erlebt, bei dem eine Mischung zu einem nachhaltigen Erfolg geführt hat. Es wird meiner Meinung nach viel zu viel Energie in die Kommunikation mit/zu einer Rolle gesteckt, die gar nicht vorgesehen ist. Es besteht auch viel zu sehr die Gefahr, dass man irgendwann wieder in alte Muster verfällt und doch wieder zu detailliert geplant wird sowie unnötige Status Reports erstellt werden müssen.

 

Dies möchte ich nun gerne konkret an einem Beispiel aus einem Unternehmen darstellen, dass Dienstleistungen an Kunden anbietet, die auf Basis hausinterneren Software-Produkten erfolgt. Die Software wurde mit der agilen Arbeitsweise erstellt, der Rest des Unternehmens war jedoch noch traditionell in Silos aufgeteilt, obwohl das Umfeld der VUCA Welt entsprach.

 

Folgende Rollen waren dabei beteiligt (Gruppen-, Abteilungs-, und Teamleiter nicht mitbrachtet):

  • Projektleiter #1 war nahe am Dienstleistungsteam angesiedelt und vorwiegend koordinierend tätig als Vermittler zwischen Team und Projektleiter #2. Projektleiter #1 besitzt das fachliche Wissen. Zusammen mit Projektleiter #2 werden die Angebote und das Reporting erstellt. 
  • Projektleiter #2 war aus der Projektmanagement Abteilung und agierte als Gesamtprojektleiter für die Projekte des Kunden. Diese Person war die Schnittstelle zum Kunden und somit hauptverantwortlich für die Kommunikation.
  • Im Bereich Software gab es Product Owner, die Anforderungen für Produktverbesserungen und -Erweiterungen von Projektleiter #1 entgegen nahmen.
  • Zusätzlich gab es noch in einer anderen Abteilung einen Produkt Manager, der für das gesamte Unternehmen den Markt untersucht hat.
  • Eine Marketing Abteilung versucht Produkt mit Dienstleistung mit entsprechenden bunten Flyern zu bewerben, der Vertrieb hingegen hatte meistens nur der Verkauf von Dienstleistungen im Fokus.

Was denkt ihr: Hat das Unternehmen langfristig Erfolg? War eine hohe Zufriedenheit spürbar? Sind die Mitarbeiter glücklich? Konnten die Kundenbedürfnisse befriedigt werden? Wieviel Energie und Kosten sind in die Kommunikationsstruktur eingeflossen?

Leider hat dieses Umfeld zu einer sehr großen Unzufriedenheit bis hin zu Burn-out Vorfällen geführt, da das Problem als solches nicht erkannt werden wollte. Allein die Diskussion Projekt vs. Produkt wurde nie wirklich abgeschlossen. In den Sprint-Review saßen immer die selben Personen, die nicht einmal 10% der notwendigen Personen entsprachen. Scrum kann unter diesen Voraussetzungen gar nicht sein Potential entfalten und hinterlässt eher negative Spuren.

 

Was ist aber, wenn die Größe des Produktes und die damit zusammenhängenden Dienstleistungen zu unüberschaubar für einen Product Owner ist?

An dieser Stelle sollte nicht gleich ein Skalierungsframework eingeführt werden, sondern zuerst die bestehenden Strukturen optimiert werden und/oder das Produkt skalierbar aufgestellt werden.

 

Als ich vor Jahren selber als Product Owner für ein modularer ERP-System gearbeitet habe, hat sich folgende Struktur über Jahre als funktionierend herausgestellt. 

  • Die Product Owner waren für die Standard-Produkt Entwicklung zuständig und stehen in engen Kontakt zum Marketing.
  • Für jeden Kunden gab es ein Consultant, der die Kundenanpassungen mittels der Workflow Engine erstellt und die allgemeinen Produkt Anforderungen an die Product Owner weitergab.
  • Während der Umsetzung gab es eine enge Abstimmung untereinander u.a. durch Integration in Scrum. Zusätzlich wurde ein globales Portfolio Management eingeführt.
  • Ein klassischer Projektleiter war hier nicht mehr notwendig.

Was sind eure Erfahrungen?

Kommentar schreiben

Kommentare: 0