Der klassische Projektmanager in Scrum

8 Kommentare

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 …

Autor

Uwe Friedrichsen

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Moin Uwe,

    vielen Dank für den interessanten Beitrag. Ich bin auch von Boris geprägt und kann der Verteilung einiger Verantwortungen des traditionellen PM auf die Scrum-Rollen nur zustimmen.

    Die Betonung liegt jedoch auf „einiger“. Denn in einem traditionellen Projekt, insbesondere Großprojekten und Programmen, hat der Projektmanager noch einige andere Aufgaben, die Scrum (und m.W. auch alle anderen agilen Methoden) komplett vernachlässigen. Als Beispiel seien hier Project Inititiaton, Project Closing und Risk Management genannt. Scrum bietet hier keinerlei Orientierung. Konkreteres Beispiel: Wenn Produktentwicklung, Marketingkampagnen, Buchungsläufe in Finance, zeitnahe Trainings des Customer Service u.ä. Dinge koordiniert werden müssen, wer kümmert sich drum? In der Regel nicht der Product Owner der Produktentwicklung. Wer hat die Verantwortung für die übergreifende Vertragsverwaltung?

    Meines Erachtens können gerade bei größeren Projekten traditionelle und agile Methoden sehr symbiotisch zusammenwirken.

    Just my two cents.

    Viele Grüße aus Hamburg,
    Sven

  • Hallo Sven,

    danke für den Kommentar. Ich sehe, dass Du Dich auch schon intensiver mit dem Thema auseinandergesetzt hast … 😉

    Ich gebe Dir auch recht, dass Scrum nicht alle Fragen adressiert, die im Umfeld eines Projekts oder einer Produktentwicklung entstehen und dass durch die „Erfindung“ von Scrum alles über die letzten 40 Jahre mühsam in der IT-Branche erworbenes Wissen deshalb hinfällig ist. Scrum hin oder her, bleiben da sicherlich noch einige Fragen und Aufgaben offen.

    Wenn man sich aber die Menge der Themen ansieht, die ein klassischer Projektmanager in einer Person vereinigen und gleichwertig vorantreiben soll (ich hatte in meiner Betrachtung ja noch nicht einmal die Themen aufgezählt, die Du noch erwähnt hast), dann denke ich, dass es auf jeden Fall Sinn macht, diese Themen gezielt auf mehrere Schultern zu verteilen, anstatt einer Person immer mehr aufzubürden.

    Ob man das dann genau so macht, wie Scrum oder Boris das vorschlagen, ist dann eine andere Diskussion, aber ich denke aus meiner Sicht, dass es ein guter Ansatzpunkt ist.

    Gruß in den Norden, Uwe

  • Zuerst mal „Hallo“ ist schließlich mein erster Kommentar hier. Ich würde mich dieser Rollen-Verteilung grundsätzlich anschließen.

    Ergänzend vielleicht … einen Teil des Risiko-Managements (genaugenommen die Risikoidentifikation) sehe durchaus ich beim Scrum-Master, er hat das Ohr am nächsten an den intrinischen Risiken dran. Die von meinem Vorredner genannten Punkte sehe ich auch, denke aber dass ggf. eine geeignete Kombination von Teilprojekten helfen kann – dabei muss nicht zwangsläufig jedes Teilprojekt nach Scrum arbeiten.

  • Erst einmal ein herzliches „Hallo“ zurück!

    Inhaltlich stimme ich Dir grundsätzlich zu. Ich denke, was diese (kurze) Diskussion zeigt ist, dass Scrum eine ganze Reihe guter Ideen und Impulse liefert, auf der anderen Seite aber auch eine Reihe Fragen offen lässt, die sich nicht dogmatisch wegdiskutieren lassen, sondern auf die man in der jeweiligen Projektsituation eine Antwort finden muss … bei Bedarf eben auch unter Rückgriff auf das unter Puristen verpönte „klassische“ Projektmanagement-Wissen … 😉

    Ich von meiner Seite habe das Gefühl, dass sich die Diskussion über Agilität mit der Bewegung in Richtung „Mainstream“ weg von „Glaubenskriegen“ bzgl. der „reinen Lehre“ hin zu ganzheitlichen Betrachtungen entwickelt, die auch die fehlenden (aber für eine erfolgreiche Projektumsetzung ebenfalls notwendigen) Aspekte mit berücksichtigt. Von meiner Seite aus bin ich daher sehr gespannt, in welche Richtung sich die Agilität in der kommenden Zeit entwickeln wird.

    PS: Ich habe eben einmal auf Euren Blog geschaut … finde ich sehr interessant. Da werde ich zukünftig wohl öfter einmal vorbeischauen. Auch in diesem Sinne vielen Dank für den Kommentar!

    Gruß nach Ludwigsburg, Uwe

  • April 27, 2011 von Dirk F5R

    Hallöchen!

    Zusätzlich zu den obigen Kommentaren noch zwei Einwände von mir:
    a) der PO verwaltet kein Budget und
    b) der SM holt keine Pizza, wenn’s mal später wird, da es grundsätzlich nicht später wird. :-)

    Gruß
    Dirk

  • Hallo Dirk,

    nimm’s mir bitte nicht übel, aber das klingt ein wenig sehr idealistisch … 😉

    Ja, Scrum schweigt sich (wie auch bei vielen anderen Dingen) darüber aus, wer denn die Budget-Verantwortung haben soll. In der Realität ist aber nun einmal so, dass es fast immer ganz massiv um das Thema Geld geht und man ist extrem gut beraten, wenn man das Thema nicht unter dem „Schöne-heile-Welt“-Deckchen versteckt, das Scrum einem durch die Auslassung vieler essentieller Projektaspekte anbietet. Und wer von den drei Scrum-Rollen soll den das Budget verwalten? Wenn Du einen Moment darüber nachdenkst, dann bleibt da letztlich nur der Product Owner.

    Auch die zweite Anmerkung klingt ein wenig wie aus dem Lehrbuch zitiert. Ja, das Ziel ist es, „sustainable pace“ zu erreichen und zu halten, d.h. Überstunden sowie eine übermäßige Belastung der Beteiligten zu vermeiden und eine dauerhaft gut durchhaltbare Arbeitsbelastung zu etablieren und ich freue mich über jedes Projekt, in dem das in der Form klappt. Aber dennoch gibt es trotz bester Absichten immer wieder mal Situationen, in denen dann doch mal die Arbeitslast steigt und es später wird … und dann erkennt man einen guten Scrum Master daran, dass er dann nicht Punkt 17 Uhr nach Hause geht, weil es gemäß Scrum ja keine Überstunden geben kann, sondern dass er sich auch dann um sein Team kümmert … und sei es dadurch, dass er die Pizza holt.

    Solltest Du jetzt einwenden, dass das nicht so schön und rein wie bei Ken, Jeff sowie einigen anderen Verfechtern der „reinen Lehre“ klingt … hmm … ja, da gebe ich Dir absolut recht … aber wann ist schon mal so einfach, wie es in den Büchern steht … 😉

    Gruß, Uwe

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *