Viele „klassische“ Projektmanager stehen Scrum sehr reserviert oder gar ablehnend gegenüber. Einer der Gründe dafür ist, dass sie sich in Scrum nicht wiederfinden. Es gibt keine Rolle „Projektmanager“ in Scrum. Im Rahmen unseres Meet the Experts – Agilität hatte ich die Gelegenheit, mich mit Boris Gloger ein wenig über das Thema zu unterhalten.
Zuvor hatte Boris in einem OpenSpace einmal seine Sicht auf die Rolle Product Owner dargelegt. Bei dieser Darstellung ist mir klar geworden, dass die Rolle wesentlich mehr Elemente der klassischen Projektmanager-Rolle hat, als ich vorher wahrgenommen hatte. Ich hatte den Eindruck, dass die Aufgaben des klassischen Projektmanagers in gewisser Weise auf die Rollen Product Owner und Scrum Master verteilt worden sind. Mit diesem Eindruck habe ich Boris angesprochen und er hat mir diesen Eindruck bestätigt, genauer sogar noch etwas erweitert:
Nach seiner Einschätzung ist die klassische Projektmanager-Rolle eigentlich überfrachtet und es gibt kaum eine Person, die diese Rolle in allen geforderten Aspekten gut ausfüllen kann. In Scrum hingegen ist die Rolle folgendermaßen aufgeteilt worden:
- Der Product Owner ist für die Richtung (die Vision), die inhaltliche Steuerung (Product Backlog) und das Budget verantwortlich. Er ist derjenige, der die Richtung vorgibt und inhaltlich treibt. Ebenso versucht er, das meiste aus dem ihm zur Verfügung stehenden Budget herauszuholen. Da – egal wie das Vorhaben im Detail aussieht – für die Features, die den höchsten Geschäftswert versprechen, im Verhältnis auch das meiste Budget zur Verfügung steht, ergibt sich durch das Streben, das meiste aus dem Budget herauszuholen, automatisch eine Priorisierung der Features nach Geschäftswert. Das klingt zwar nicht so richtig „edel und rein“, funktioniert aber in der Praxis erstaunlich gut … 😉
- Das Team ist für die Planung der Umsetzung und die Einhaltung der Planung verantwortlich, d.h. den ganzen Detailplanungs- und Controlling-Anteil. Durch Sprint-Planung, Commitment auf die abgestimmten Sprint-Inhalte und Team-Verantwortung für die Umsetzung ist besser als in vielen klassisch aufgestellten Projekte gewährleistet, dass Erwartungshaltungen und Ergebnisse zueinander passen.
- Der Scrum Master letztlich ist der „Kümmerer“: Er holt die Pizza, wenn es spät wird, räumt die Hindernisse aus dem Weg … ist aber auch derjenige, der dem Team über die Schulter schaut und es bei Bedarf an seine Commitments erinnert. Er stellt sicher, dass alle ihrer jeweiligen Rolle gerecht werden und sorgt für die bestmöglichen Arbeitsbedingungen.
So verteilen sich die Aufgaben des klassischen Projektmanagers auf recht natürliche Weise auf die drei Scrum-Rollen. Wenn man nun als Projektmanager den Schritt Richtung Scrum wagen will (oder manchmal auch muss), so ist die Wahl einer Rolle eigentlich relativ einfach. Man sollte ehrlich in sich selber hereinhorchen, welchen Teil der Projektmanager-Rolle einem am besten liegt:
- Treibt man ein Projekt gerne inhaltlich und hat ein gutes Händchen für Budgets, dann sollte man die Product Owner-Rolle wählen.
- Ist man hingegen eher der „Kümmerer“ und hat Spaß daran, dafür zu sorgen, dass ein Projekt rund läuft, dann sollte man am besten die Scrum Master Rolle wählen.
- Wenn man aber nur Projektmanager geworden ist, weil man seinen früheren Entwicklerjob zu gut gemacht hat, darüber irgendwie in die Verantwortung hineingerutscht oder -gewachsen ist, dann sollte man am besten wieder Teil des Teams werden und Spaß daran haben, das Projekt durch seine eigene Leistung nach vorne zu bringen.
Insgesamt macht diese Darstellung von Boris für mich viel Sinn. Vor allem glaube ich, dass durch diese Art der Rollenaufteilung die für den Erfolg eines Projektes kritischen Anteile der klassischer Projektmanager-Rolle gut auf die drei Scrum-Rollen verteilt sind und durch die Aufteilung umfassender gelebt werden können als wenn sie von nur einer Person wahrgenommen werden sollen.
Einen Punkt hat Boris in seiner Darstellung allerdings nicht erwähnt: Es gibt eine häufig anzutreffende Art von klassischen Projektmanagern, die ich gerne „reine Projektmanager“ nenne. Diese zeichnen sich dadurch aus, dass sie auf rein formal Weise jede Art von Projekt managen, ohne genauere Kenntnis von den Projektinhalten zu haben. Sie beschränken sich darauf, Planungen (von wem auch immer erstellt) sowie Eskalationen zu verwalten und besitzen ausgeprägte Controlling-Kenntnisse, manchmal auch gute politische Kenntnisse. Sie machen in Anlehnung an das „Management by Spreadsheet“ (Management nur auf Basis von Kennzahlen unter Vernachlässigung der zugrundeliegenden Inhalte) ein „Project Management by Spreadsheet“ und manche dieser Projektmanager sind auch noch stolz darauf, dass sie nichts von den Inhalten verstehen, die sie verwalten („Ich kann jedes Projekt managen. Der Inhalt ist mir vollständig egal.“).
Nun, für diesen Typus Projektmanager gibt es in Scrum tatsächlich keine Verwendung. Getreu des Lean-Prinzipies „Eliminate Waste!“ vermeidet Scrum nämlich jede Art von Ballast und fokussiert sich ausschließlich auf die Aspekte der Projektmanager-Rolle, die Mehrwert bieten, d.h. zum Projekterfolg beitragen. Und da echter Erfolg letztlich nur auf Basis der produzierten Inhalte beurteilt werden kann, wird eine Person, die nichts zu den Inhalten, zum eigentlich Ergebnis beitragen kann, in Scrum nicht benötigt. Es bleibt nur die Frage, ob solche Personen außerhalb von Scrum benötigt werden …
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.