Forget the Project Manager, we need competences!

Jarl Meijer

One of the basic ideas in Scrum is the backbone formed by Product Owner and the Agile Team, headed by their Scrum Master.
The Product Owner stands right in the middle of the business, knows every functional detail, is trusted and respected by his business colleagues. Furthermore he takes care of the acceptance and business implementation of products and features delivered by the Agile team.
The Scrum Master, with his team, takes care of the technical realization and delivery of new products and features.

Scrum advocates a very short, direct connection between the one who has a goal and the ones who deliver the solution to reach this goal. Scrum does not know a Projectmanager role. Traditional projectmanagement responsibilities are divided over the Product Owner and the Scrum Master roles.

Product Owner and Scrum Master manage the work
In Scrum the traditional projectmanagement responsibilities are divided over the Product Owner and the Scrum Master roles.The Product Owner
• Owns the product backlog and while doing so, report on status of individual and clusters of user stories to stakeholders.
• Is responsible for the business case of every user story on his backlog. For every user story the potential value is estimated and this value is the base for prioritizing. The team will help by estimating the cost and is transparent in status and progress.
• Will perform stakeholder management to keep all stakeholders informed and take care all stakeholders interests are considered seriously.
• Chases impediments within his range of influence (policy / decisions needed, availability of business resources), until they are resolved.

The Scrum Master
• Will perform stakeholder management with respect to the delivery process. He will take care that all contributors are aligned, and that the team will deliver a complete solution, something the business really can use.
• Will assure the processes are in place to give full and honest insight in estimations, impediments, quality, progress and planning from a technical point of view.
• Chases impediments within his range of influence (technical environment, technical choices, availability of technical resources) until they are resolved.

When the going gets tougher
In non-complex environments and smaller changes this will work perfectly well: Product Owner and Scrum Master will be able to fulfill all project management tasks, and happily deliver valuable solutions in the same time. However if the environment becomes more complex, the Product Owner and Scrum Master are stretched in amount of effort and in competences requested.

Complexity and required effort to manage it rise when:
• Changes are bigger and more complex,
• The number of stakeholders grows,
• Stakeholders are more demanding,
• More and more distant parties are needed to realize a solution,
• The number of dependencies between teams and external parties grows,
• The business is more diverse, the number of business owners grows,
• The business implementation is larger in terms of number of people involved or in gap between current and new way of working.

There will be a moment the Product Owner and Scrum Master spend most of their time on all kind of ‘management’ tasks, instead of their main responsibility: delivering high quality user stories and solutions for the business. Mostly the latter is also the field their passion and qualities are in.
At this moment it is time to bring in someone with project management competences. To support the Product Owner and Scrum Master, with planning, managing external partners, reporting, communication and planning trainings for end-users. To pave the way for the teams.
This role is a major difference compared to the traditional project manager role. A project manager would take the lead and position himself as superior of the PO and the SM. The person we look for in an Scrum context is someone we is more like an assistant, although in practice I see him more like a peer, forming a team of three with the PO and SM to get the work done together.

In Scrum theory there is no room reserved for project managers. Together the Product Owner and Scrum Master will take care of all typical project management responsibilities. But in our daily complexity these project management activities can distract the Product Owners and Scrum Masters attention away from their primary responsibility and passion: delivering solutions. Bringing in support with project management competences can relieve our key-players and bring their focus back where it belongs. This support will act as a peer to the PO and SM, not as a manager.

Comments (5)

  1. D Taylor - Reply

    April 27, 2012 at 3:16 pm

    Interesting analysis of how Scrum (and Agile in general) sort of changes the traditional roles in software projects. I'm not sure of about you, but I have spent most of my career in consulting. Do you generally try to draft someone from the client organization to be the product owner, or do you find that it is best that someone from the consulting organisation try to embed themselves into the business and become educated enough to be an effective product owner?

    • Jarl Meijer - Reply

      April 27, 2012 at 4:36 pm

      Hi D., thnx for your reply. The simple answer to this question is that the Product Owner comes per definition from within the (business part of the) client organization. The PO needs to have business knowledge, knowledge from the organization, needs authority, mandate and a network in the client organization. The PO is an entrepreneur. It is very hard for a external consultant to meet these requirements. As a client organization the question is if you want to fill in this role by a consultant anyway.

  2. Sander Nieuwenhuizen - Reply

    April 27, 2012 at 3:47 pm

    Hi Jarl,

    I'm afraid you sketch a too simplistic view of what Agile is about. You describe the ScrumMaster as being a team lead, managing the team and being responsible for stakeholder management and reporting to management. The team you say is responsible for delivering technical solutions.

    The beauty of Agile / Scrum is the whole team focuses on building solutions (not purely technical, per se) for people. In order to do this successfully, please let them talk to and discuss with stakeholders. As the Agile Manifesto describes, the primary measure of progress is working software. If a Scrum team (as such including PO/SM) delivers stuff that helps their users, what kind of reporting would you need besides focusing on the product backlog and the teams velocity (which is also often abused)?

    The advantage of letting team members work together with the users they're working for you gain:
    - A better understanding for what the actual benefits are, as opposed to being a hard working feature delivering machine. Which in turn lead to:
    - Better solutions that makes people happy

    If you'd put someone else - like a project manager - between the stakeholders and the Scrum team, what you'd create is extra fuzz. As it is harder to deliver actual results (as you have less understanding for what is really necessary to do before you're done), the tendency could be to focus more and more on the process, reporting and management.

    Also, in my opinion in Scrum the traditional project management tasks are not only divided among the PO and SM. You're forgetting about the team. Teams can manage themselves. Why would they need someone else to 'manage' their work? A ScrumMaster only kicks in if their are gaps in the process, if there are self-management issues in the team. As opposed to be responsible for making sure everyone does their job, the ScrumMaster should drive the team do make that happen themselves.

    If one thinks you'd need a project manager for control, I think you should focus on coaching the team to be proactive and deliver results. All in all, the best environments do not require a ScrumMaster to make Scrum a success. It's the Scrum team that is focused on creating solutions that matter. That's the development team hand in hand with the Product Owner and ScrumMaster.


    • Jarl Meijer - Reply

      April 27, 2012 at 5:26 pm

      Hi Sander, thanks a lot for your reply, it challenges me to make my point more clear.
      I was not aware of downgrading the role of the team and I agree on most of your description. The team is a self organizing unit, taking over the PM-role in that respect. My reference is Agile adoptions in big, complex organizations. Of course team members can talk to stakeholders. But if there are many many stakeholders, which all request time and information from the team, the Scrummaster is the role to shield the team from less relevant interruptions.
      I am not saying one should put a PM between stakeholders and the team. The PM supports. So if an organization requests a lot of paperwork to keep the team going, you might consider to get some support to help you with the paperwork. I am not saying this paperwork is a good thing, but sometimes it takes time to change an organization.
      The key point of my blog is that introducing Agile/Scrum does not eliminate project management tasks. In some, complex, circumstances they can request a lot of time and specific competences. If this is your case than it might be wise to support the Product Owner, Scrummaster and Team. But do this without breaking the values and principles of Scrum.

      • Geert Bossuyt - Reply

        April 28, 2012 at 1:16 pm

        Hi Jarl,

        Enlightning post. I agree with you that, given a certain complexity, you need someone to support PO and SM with a focus on managing the environment.

        @Sander, There is a big difference with 'talking to stakeholders' and 'managing stakeholders'. Most Teams are very capable of understanding their stakeholders but find it hard to make sure stakeholders show up or take decisions. That's a different skill. So add this skill to the system.

Add a Comment