22.03.2016  Verfasst von Lorenzo Peroni in Agile Methoden  

Es gibt keine agilen Projektmanager.

Oder doch?

Bevor ich auf die Frage eingehe, möchte ich zunächst etwas klarstellen: Agile ist keine Methode zur Steuerung eines Projekts, sondern ein Prozess zur Entwicklung eines Produkts. Die Frage nach einem Projektmanager ist somit gegenstandslos. Stattdessen brauchen wir zwei neue Rollen: einen Prozess-Manager und einen Produkt-Manager:

Der Prozessmanager (auch Prozesskoordinator, Process Owner oder Scrum Master genannt):

  • praktiziert „dienende Führung“ (Servant Leadership)
  • ist verantwortlich dafür, dass der Prozess verstanden und gelebt wird
  • coacht das Entwicklungsteam, selbstorganisiert und interdisziplinär zu handeln
  • behebt Hindernisse (Impediments), die dem Fortschritt im Wege stehen – oder unterstützt das Team dabei, diese selbst zu überwinden
  • treibt eine kontinuierliche Verbesserung über Inspect and Adapt-Schleifen voran
  • schafft eine motivierende Arbeitsumgebung und verteidigt diese insb. gegen Störungen von außen


Der Produktmanager (auch Produktverantwortlicher, Product Owner oder Product Manager genannt): 

  • verantwortet den finanziellen Erfolg des Produkts und misst dessen Akzeptanz beim Kunden
  • behält den Fokus stets auf dem Mehrwert für den Kunden und kommuniziert dazu eine klare Produktvision
  • leitet daraus Anforderungen ab und sortiert sie anhand transparenter Metriken
  • stellt sicher, dass das Entwicklungsteam alle zur Arbeit benötigten Informationen hat
  • validiert die vom Team erstellten Ergebnisse gegen vorab definierte Akzeptanzkriterien
  • stellt sicher, dass alle Beteiligten wissen, was die derzeitigen Prioritäten und der aktuelle Fortschritt sind


Die Antwort auf die Frage, ob es agile Projektmanager gibt, ist daher Nein.
Aber nicht, weil Projektmanager nicht agil sein könnten, sondern weil Agile ein fortlaufender Prozess ist.

„Aber was machen wir denn mit unseren ganzen hochprofessionellen Projektleitern, wenn wir ab jetzt agil entwickeln?“ Gegenfrage: Was gibt es denn noch zu managen, wenn ein agiles Team selbstorganisiert ein Produkt entwickelt? Antwort: Projektmanagement hat traditionell vielfältige Verantwortungsbereiche – Budget, Staffing und Verträge; Scope, Abhängigkeiten und Risiken; Kommunikation und Reporting. Diese liegen teilweise außerhalb des eigentlichen agilen Entwicklungsprozesses. Und genau an den Systemgrenzen kann ein Projektmanager einen Mehrwert erbringen.

Um transparent zu machen, welche Verantwortlichkeiten in welcher Form bei welcher Rolle liegen, bringe ich alle Personen, die etwas managen – den Prozess, das Produkt, das Budget, die Personen – an einen Tisch und gehe mit ihnen die folgenden Schritte durch:

  • Verantwortungsbereiche definieren – ohne Personen oder Rollen zuzuweisen. Beispiele für solche Verantwortungsbereiche sind: wirtschaftliche Ziele, Produktvision, Priorisierung, Budget, Staffing, Verträge, Qualität, Kommunikation u. v. m.
  • Eine sinnvolle Anzahl von Rollen benennen, z. B. Prozessmanager, Produktmanager und Projektmanager. Dabei das eigentliche Entwicklungsteam nicht vergessen.
  • Mögliche Arten der Verantwortlichkeit festlegen, klassischerweise nach dem RACI-Schema: Responsible (leitet die Durchführung oder führt selbst durch), Accountable (verantwortet das Ergebnis), Consulted (soll oder muss konsultiert werden), Informed (soll oder muss informiert werden). Ich bevorzuge die deutschsprachige Variante EDMI (Entscheiden, Durchführen, Mitwirken, Informieren), weil damit deutlich wird, dass Entscheiden (Accountable) auf einer vorgelagerten Ebene liegt als Durchführen (Responsible) und dass eine Verantwortung neben Rechten auch Pflichten mitbringt: Mitwirken bedeutet mehr, als nur konsultiert (Consulted) zu werden.
  • Für jeden Verantwortungsbereich schlägt ein Stakeholder eine Aufteilung der Verantwortlichkeiten auf die Rollen vor. Die anderen können zustimmen oder einen begründeten Gegenvorschlag einbringen. Dies kann auch jede Seite für sich offline vorbereiten, damit anschließend nur nur eventuelle Dissense gemeinsam zu besprechen sind.
  • Die Dissense so weit auflösen, bis man eine erste Version hat, auf deren Basis man anfangen kann zu arbeiten. Ich betone „anfangen“, denn diese Aufteilung braucht nicht in Stein gemeißelt zu werden, sondern sie ist ein lebendes Dokument. Daher braucht es einen Konsens nur soweit, dass der eigentliche Entwicklungsprozess beginnen kann und damit auch die tatsächliche Wertschöpfung.

Im Ergebnis entsteht eine Handlungsmaxime, auf die sich die Beteiligten geeinigt haben:

Abschließend frage ich mich, wie ich anstatt EDMI das Delegation Board aus Management 3.0 verwenden könnte. Da dieses nativ für zwei hierarchisch verbundene Parteien ausgelegt ist (Manager und Team), müsste ich es auf auf drei oder mehr gleichberechtigte Parteien erweitern. Bleiben Sie dran.

Der Autor

Lorenzo Peroni
Management Consultant