Agile Vorgehensmodelle (allen voran Scrum) gehören mittlerweile eigentlich zum Standardrepertoire von Entwicklungsteams und Projektleitern. Trotzdem treten immer wieder (meist leitende) Angestellte auf den Plan und postulieren, dass man dringend dem neuen Trend folgen müsse agil vorzugehen, da das „einfach besser“ sei. Interessant bei dieser Beobachtung ist, dass es dabei egal ist, ob es sich um konzernartige oder eher mittelständische Unternehmen handelt. Der „agile Frühling“ scheint alle gleichermaßen aus dem Winterschlaf zu holen. Doch was heißt das für klassische Projektleiter?

Agilität missverstanden

An sich ja eine positive Entwicklung! Getreu nach dem Motto „lieber spät als gar nicht“ könnte man sich ja freuen, dass jetzt auch die länger schlafenden aufgewacht sind. Gruselig wird es allerdings dann, wenn auf einmal Schlüsse daraus abgeleitet werden, die nur zeigen, dass die Leute nicht tiefer als auf Stammtischniveau in die Materie eingedrungen sind. Ich liste hier mal ein paar Irrungen auf:

  • „Projektleiter gibt es in Scrum nicht.“
  • „Klassische Projektleiter und ScrumMaster (wahlweise auch ProductOwner) sind das gleiche und werden deshalb vom gleichen Mitarbeiter ausgeübt.“
  • „Agiles vorgehen heißt, wir brauchen nicht mehr planen.“

Und sobald diese (oder ähnliche) Gassenhauer zu hören sind, treten als nächstes die BWLer (allen voran die Controller) auf den Plan und überlegen offen, ob man dann nicht sogar die Rolle klassische Projektleiter komplett einsparen könnte, wenn das ja mit Scrum nicht mehr nötig ist. Nachdem mich im Laufe der Zeit viele jüngere Kollegen, die gerade (klassische) Projektleiter geworden sind oder es noch werden wollen, verunsichert angesprochen haben, wie sich unsere Arbeit entwickeln wird, möchte ich meine Sicht der Dinge in diesem Kommentar darstellen in der Hoffnung den immer wieder aufkommenden (und viele Kollegen verunsichernden) Diskussionen vorzubeugen.

Um die Pointe vorweg zu nehmen: Ja, es gibt gewisse Überschneidungen mit den Rollen im Scrum und dem klassischen Projektleiter. Aber ich bin nicht der Meinung, dass klassische Projektleiter in der agilen Welt überflüssig sind oder die Projektleitung vom Scrum-Team (egal ob ScrumMaster oder ProductOwner) nebenbei erledigt werden sollte, denn es bleiben noch mehr als genug Aufgaben übrig, die in Scrum nicht berücksichtigt werden. Im optimalen Fall erreicht man einen Jobsplit mit dem Team, bei dem der Projektleiter die Freiräume erhält sich um die von Scrum nicht behandelten Projektaufgaben zu kümmern.

Die Umsetzung (Entwicklung) ist nur eine Projektphase. Wer macht den Rest?

In unserem Artikel „Was macht ein Projektleiter eigentlich den ganzen Tag?“ haben wir den Arbeitsalltag eines Projektleiters in den verschiedenen Projektphasen vorgestellt. Insgesamt werden im Projektmanagement 5 Phasen unterschieden.

  1. Initialisierungsphase – Übernahme der Verantwortung für das Projekt durch den Projektleiter. Klärung des Projektauftrags generell. Ggf. Angebotserstellung
  2. Definitionsphase – „Wer möchte was?“ Erfolgsfaktoren, Ziele und Business Cases ermitteln. Das Projektteam zusammenstellen.
  3. Planungsphase – „Wie erfüllen wir den Auftrag?“ Releaseplanung, Meilensteinplanung, Projektstrukturplan, Terminplanung, Umfeldanalyse
  4. Steuerungsphase – „Durchführen der eigentlichen Projektarbeit, z.B. Software programmieren“ Controlling, Reporting, Projektmarketing, Eskalationsbehandlung
  5. Abschlussphase – „Aufräumen, nach getaner Arbeit“ Übergabe der Ergebnisse, Zurückgeben der Projektberechtigungen, Abschlussworkshop (Lessons Learned)

Scrum hingegen läuft zu 95% in der Steuerungsphase ab. Die restlichen 5% sehe ich in der Planungsphase, wenn der ProductOwner noch ohne das Team die Erstbefüllung des Productbacklogs erarbeitet. Jetzt kann man natürlich sagen „der Productowner hat ja in den anderen Phasen nichts zu tun und kann die Arbeiten auch durchführen“. Klar kann er das! Das bedeutet jedoch nicht dass der klassische Projektleiter nicht gebraucht wird, sondern dass man einen Kollegen finden muss, der beide Jobs im Wechsel durchführt. Das macht zum einen den Kollegen deutlich teurer und zum anderen ist die Qualität bei Konzentration auf nur ein Thema (Arbeitsfeld) meistens höher.

Auch während der Entwicklungsphase gibt es Themen, die im Scrum nicht vorkommen

Scrum ist in meinen Augen ein sehr geeignetes Vorgehensmodell, wenn es darum geht, möglichst effizient (also mit geringem zeitlichen und personellen Aufwand) zum Beispiel Software zu entwickeln. Trotzdem kann man, wenn es um den Gesamterfolg eines Projektes geht, den reinen Entwicklungsprozess in der Praxis nicht isoliert betrachten. Das Projektumfeld hat einen nicht unerheblichen Einfluss, auf den Erfolg. Scrum bietet in meinen Augen dafür nur das aller nötigste. Der ScrumMaster kümmert sich, einfach ausgedrückt, um den Entwicklungsprozess und sorgt für die Beseitigung von Hindernissen (Impediments). Der ProductOwner bildet die Schnittstelle zum Kunden und kümmert sich ansonsten um die Konzeption des zu erstellenden Produkts/ Werkstückes.

Klassische Projektarbeit

Darüber hinaus gibt es in der Projektarbeit noch weitere Erfolgsfaktoren, um die sich klassischer Weise der Projektleiter kümmert:

  • Berichtswesen – Oft geben sich Auftrag- bzw. Geldgeber nicht nur mit einem Burndownchart zufrieden. Und dann muss es halt doch der gute, alte Statusbericht nach „Qualität, Zeit, Kosten“ sein.
  • Projektcontrolling – Wenn es um die Bewertung von Alternativen geht, wie ein Projektziel doch noch zu erreichen ist, ist ein fortgeschrittenes Projektcontrolling meistens unerlässlich.
  • Changemanagement – Sprengen die gewünschten Änderungen die Freiheitsgrade, die Scrum dem Kunden einräumt ist ein gutes Changemanagement das einzige Mittel, den Auftraggeber wieder einzufangen.
  • Erste Eskalationsstufe – Sollte der Auftraggeber sich nicht mit ProductOwner und/ oder ScrumMaster einigen können, bietet der Projektleiter eine erste Eskalationsstufe.
  • Projektmarketing & Ressourcen Fragen – In größeren Unternehmen ist es leider oft an der Tagesordnung, dass auf Grund mangelnder Ressourcen ständig versucht wird bestehende Projekte zu kannibalisieren, um noch mehr Kundenaufträge bearbeiten zu können. An dieser Stelle ist es sehr wichtig einen Projektvertreter in den richtigen Meetings sitzen zu haben, der die Fahne des Projekts hoch hält und für die nötige Rückendeckung sorgt.

Das sind nur ein paar der in meinen Augen wichtigsten Arbeiten, die parallel zur eigentlichen Entwicklung des Teams ablaufen müssen. Ja, der ProductOwner ist für die Stakeholder zuständig und gemäß der klassischen Definition geht es bei den oben genannten Punkten um Stakeholder-Management, aber bleiben wir doch mal realistisch: Je nach Komplexität ist das nichts, was man in der nötigen Qualität „nebenher“ erledigen kann, wenn man eigentlich als ProductOwner fachlich das Entwicklungsteam führen muss… Aus diesem Grund ist auch hier ein dedizierter Projektleiter in meinen Augen unverzichtbar.

Programmplanung ist kein Scrum Thema

Sobald der Umfang eines Projekts zu groß wird, um es mit nur einem Team zu bearbeiten, entwickelt sich das Projekt zum Programm mit einem Programmleiter und (Teil-) Projektleitern für die Teilprojekte, die jeweils einen beherrschbaren Umfang bearbeiten. In Scrum existiert zwar ein „Scrum of Scrums“ in dem es auch um die abgestimmte Arbeit in mehreren Scrum Teams geht, allerdings tauschen sich hier normalerweise nur die ScrumMaster der Teams untereinander zu Impediments aus. Viele Methoden des Projektmanagements zielen auf die Synchronisation von Teilergebnissen, Zeitplänen, Auslastungen usw. ab. Diese Elemente werden um so wichtiger, je größer ein Projekt (oder Programm) wird. Hier die Arbeit der Projektleiter von ScrumMastern oder ProductOwnern „nebenbei“ machen zu lassen ist an dieser Stelle ein echtes Projektrisiko.

Und wenn man dem Gedanken folgt, dass man für ein echtes Programm vielleicht doch einen echten Projekt- bzw. Programmleiter braucht, dann sollte man auch in Projekten Projektleiter einsetzen, denn Erfahrung bekommt man nur durch die praktische Arbeit und die kann man nicht bekommen, wenn ScrumMaster und ProductOwner sich als „Freizeit-Projektleiter“ versuchen müssen.

Was passiert, wenn agiles Vorgehen mal keine Option ist?

Der letzte Punkt sorgt wahrscheinlich für Herzrasen bei unseren agilen Evangelisten… Ja, es gibt wirklich noch Projekte für die Scrum nicht das beste Vorgehensmodell ist. Als Beispiel sei hier der klassische Werkvertrag genannt, bei dem die Abnahme auf im Vertrag referenzierten Features basiert. Das kann beliebig kompliziert werden, wenn die abnahmerelevanten Features im Verlaufe des Projekts, gemäß der Regeln von Scrum, nicht umgesetzt wurden. Weiter gibt es gerade in der Automobilindustrie die Unart noch nicht entwickelte Features der nächsten Fahrzeuggeneration sehr detailliert auf Messen als Prototypen oder sogar in bereits gedruckten Flyern der Öffentlichkeit vorzustellen. Solche Projekte werden zwar vom Kunden trotzdem gerne agil durchgeführt, wenn aber für die neu aufkommenden Wünsche nie etwas aus dem vereinbarten Umfang herausgenommen werden kann (da bereits kommuniziert) wird Scrum zu einer sehr einseitigen Angelegenheit. Hier hilft dann wieder nur konsequentes Changemanagement, um nicht in ein klassisches „moving target“ Dilemma zu laufen.

Wenn man sich also erstmal mit dem Gedanken angefreundet hat, dass es auch Projekte geben kann, die nicht mittels Scrum umgesetzt werden (sollten), dann sollte man auch den gedanklichen Schritt gehen, dass es nicht besonders pfiffig sein kann Projektleiter wegzurationalisieren und durch ScrumMaster und ProductOwner zu ersetzen.

Fazit:

Ich hoffe damit ausreichend Gründe für die Daseinsberechtigung von Projektleitern, auch im agilen Umfeld, geliefert zu haben, damit sich niemand bedroht fühlen muss, aber auch die ScrumMaster und ProductOwner aufhören können den Abgesang auf klassische Projektleiter zu singen. Habt ihr auch Erfahrungen mit dem Thema? Oder seht ihr es ganz anders und habt Blickwinkel, die ich nicht beleuchtet habe, dann wäre es super, wenn ihr euch meldet oder einen Kommentar unter dem Blogbeitrag verfassen könntet. Danke fürs Lesen!