The conventional project manager in Scrum

Many “conventional” project manager are quite offish about Scrum or they even reject it completely. One of the reasons for this behaviour is that they cannot identify with Scrum since there isn’t a role “project manager” in Scrum. Throughout our Meet the Experts – Agility had the opportunity to talk a bit about this topic with Boris Gloger.

Before, within an open space session Boris had presented his point of view on the role Product Owner. Throughout this presentation I realised that this role has a lot more elements of the conventional project manager role than I thought before. I got the perception that the responsibilities of the conventional project manager became distributed across the roles Product Owner and Scrum Master in a certain way. Having this picture in mind I asked Boris about it and he confirmed my perception. To be exact, he even extended it a bit:

From his point of view the conventional project manager role is overloaded and there is hardly a person who is capable to fulfil all responsibilities of this role in a reasonable way. On the other hand in Scrum the role is split up the following way:

  • The Product Owner is responsible for direction (the vision), control with regard to content (Product Backlog) and the budget. He is the one who sets the direction and drives development with regards to content. He also tries to make the most of the available budget. No matter how the project looks in detail – since the features that promise the highest business value are relatively also the best funded features, the pursuit of making the most of the budget automatically leads to a priorisation of the features by their business value. Now, this might not sound “noble and pristine”, but in practise this works surprisingly well … ;-)
  • The team is responsible for planning the implementation and sticking to its plan, i.e. the whole detail planning and controlling tasks. Using concepts as sprint planning, commitment on the negotiated sprint contents and team responsibility for the implementation, it is much better guaranteed that expectations and results fit together than in conventional projects.
  • Finally the Scrum Master is the “care taker”: He takes care of the pizza if it becomes late and he smoothes the impediments out … but he is also the guy who looks over the teams shoulder and reminds it of its commitments if necessary. He makes sure that everybody fulfils his individual role and he cares for the best working conditions possible.

This way the responsibilities of a conventional project mangager are split across the three Scrum roles in a quite straightforward fashion. Thus, if a project manager wants (or sometimes is urged) to move into Scrum it is quite easy for him to select the appropriate role. He should figure out for himself honestly which part of the project manager role he likes the best:

  • If he likes most to drive a project with regard to contents and has a way with budgets, he should take the Product Owner role.
  • If he is more of a “care taker” and loves to make sure that a project is running smoothly, he should take the Scrum Master role.
  • If he became project manager in the first place because he was simply too good in his former developer role and somehow slipped or grew into the responsibility this way, he should become part of the team best and enjoy to push the project along with his own effort.

Alltogether Boris point of view makes a lot of sense to me. Especially I think that this way the critical responsibilites for project success of the conventional project manager role are split up well across the three Scrum roles. Also I think that these responsibilities are handled much better by three persons than by one person.

Anyway, one point Boris left out in his presentation: There is a kind of conventional project managers that can be met quite often. I like to call them “pure project managers”. They manage projects in a pure formal fashion without having a deeper insight of the project contents. They limit themselves to manage plans (whoever created them) as well as escalations. They posess distinct controlling knowledge, sometimes also good political skills. Following the “management by spreadsheet” metaphor (management on the basis of key figures only neglecting the underlying business contents) they do a “project management by spreadsheet” and some of them are even proud of the fact that they don’t know anything about the contents they manage (“I can manage any project no matter what it is about.”).

Now, for this kind of project managers Scrum actually has no usage. Following the lean principle “Eliminate waste!” Scrum avoids any kind of dead freight and focuses solely on those aspects of the project manager role that provide added value, i.e. add directly to project success. And since real success can be judged finally on the basis of the produced results only, a person that cannot contribute to the project contents, to the actual result is not needed in Scrum. The only question left is, if such a person is needed outside of Scrum …

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Uwe Friedrichsen

8 Responses to The conventional project manager in Scrum

  1. 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

  2. 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

  3. 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.

  4. 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

  5. Pingback: Drei kurze Lesetipps zum Wochenende » Von Dr. Eberhard Huber » Agile Projekte IT-Projekte Agiles Projektmanagement Agil Teamentwicklung Risikomanagement Teamuhrwerk PMRT Projektkultur Faktor Mensch Weiterbildung Seminare Coaching Scrum Tuckman Teamphase

  6. Dirk F5R says:

    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

  7. 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

  8. Pingback: Projektleiter geteilt durch drei - Inspect & Adapt

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>