The conventional project manager in Scrum

No Comments

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 …


Uwe Friedrichsen

Uwe Friedrichsen

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


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