The “Project Manager” Title is Not a Triple Entendre

 

“I’m the boss and I delegate myself as the Scrum Master.  As the Scrum Master, I am going to tell you all what to do and when to do it.  Then we’ll talk about how we’ve done this correctly and what you guys didn’t do correctly.  This Agile thing is really just a shiny new label for what we already do.”

~Misinformed Managers

 

Have you heard similar messages working on an Agile project?   Do you have a manager who insists on being the Scrum Master?  Do you have a Scrum Master who insists she is the boss?  Oftentimes the roles of the Project Manager and Scrum Master get lost.  Despite both being leaders on a project, they have very distinct differences that can be detrimental to a project when the lines are not clearly drawn.  Let’s explore these differences in the table below:

 

Project Manager (PM)

  • Manages the Triple Constraint
  • Director: Directs Team/Project
  • Has Management Authority
  • Oversees the high-level vision
  • Plans for long-term
  • Manages Personnel

Scrum Master (SM)

  • Facilitates the Agile Scrum Process
  • Coach: Coaches team on Scrum
  • Has No Decision Making Authority
  • Facilitates sprint/release activities
  • Plans day-to-day Scrum activities
  • Coaches team on Agile process

Product Owner (PO)

  • Voice of the Customer
  • Understands the desired product
  • Understands the business need
  • Has Authority to determine priority and product outcome

All share a common goal of delivering high quality products on-time

 

 

On a project, the Project Manager, Scrum Master and Product Owner roles operate under very different expectations and have different objectives.  The project manager’s role promotes the traditional concepts of management, where the scrum master’s role, takes away some of the leadership responsibility, but not the decision making.  The Product Owner’s role is to ensure the product meets the customer’s expectations.  The Product Owner does this by prioritizing the backlog and clarifying the requirements for the team. 

A Project Manager

All projects, whether operating in Agile or not, experience schedule, scope, and cost constraints.  This means that when developing a software product, building a construction or infrastructure product, or running an innovation initiative, all projects have to meet a deadline, for a specified outcome, for a maximum amount of money.  In a perfect world, I would be a gajillionaire living on a private island.  In addition to my obscene wealth, project scope would be clearly identified from day one and would never change, there would be the exact amount of money to spend on that scope, and there would be plenty of time to get the work done by the original “yesterday” deadline.   Considering we live on Planet Earth, where things aren’t always perfect, most projects endure a balancing act of needing more time and more money, mostly because of changing scope.  This is not the domain for a Scrum Master.  A Project Manager’s job is dedicated to making smart decisions in order to maintain balance of the triple constraint, thus ensuring project success.  This is the pinnacle of the project manager’s role and is a time consuming feat.  All of the other differences outlined in the table above are elements of the PM’s duty to manage the triple constraint.

Let’s consider those secondary items in the list:

The Project Manager directs when and where to drive the project.  For example, on a software development effort, the customer may want to include a new module that is way out of the original scope.  The Project Manager can negotiate with the customer to determine if the added module can be developed within the current phase of the project, if at all.  If the PM and customer collaboratively decide to build the module, the PM can crash the project to meet the original deadline. Of course this impacts the cost and scope components of the triple constraint. As such, justifications must be made to Stakeholders who fund the project.  Additionally, the PM needs to hire staff to support the crash effort.

Scrum Master

A Scrum Master is not equipped to work in the manner of the Project Manager.   Why? Because the project manager’s duties are largely strategic and directorial.  A Scrum Master’s duties are tactical and driven by the Scrum Framework.  The Scrum Master instead serves as the team’s coach, keeping everyone focused on adhering to the Scrum framework, while also ensuring the team isn’t experiencing any barriers to productivity.  The SM lives up to this expectation primarily by grooming (prioritizing), the backlog (scope), removing impediments, and facilitating meetings.  Although this was a task formerly completed by the Project Manager, within an Agile framework, the SM serves as a conduit for protecting and promoting the team.  It’s very challenging to work with customers, manage project financials, risks, long-term planning and strategic efforts, AND to be heads-down with the team managing day-to-day operations. As such, the SM fulfills the day-to-day duties in conjunction with the Product Owner, thus leaving the management responsibilities to the PM.

…Which leads to the third comparison.  How does the Product Owner fit into all of this?

Product Owner

The Product Owner is loosely decoupled from the team.  A Product Owner may be assigned to work with a project, but is not a team member in the way the Project Manager and the Scrum Master are.  The PO is an external liaison who provides insight to the project team on what the customer wants.  The PO works with the Scrum Master to prioritize the customer’s requirements, also known as, grooming the backlog. This is an element of communication to help the project team to understand what needs to be worked on and when.  Through specific Scrum Ceremonies, the PO can answer questions to help refine the requirements (Epics and User Stories) ensuring the project team understands exactly what the outcome of the developed product should be. Although the Product Owner is not formally embedded within the team, his role is crucial to the success of an Agile project.  Without a knowledgeable PO, project teams will create products based on individual perceptions of the requirement, rather than based on customer expectations.  The PO ensures ambiguity is excluded from the process of building the product.

Where a Project Manager and Scrum Master are divided roles, the Project Manager and the Product Owner as a combined role can be more forgiving, largely because this singular person may already be interacting directly with customers.  In the Federal arena, Product Owners are generally federal FTEs who have a very close relationship with the customers in which they serve and project teams are often contractors. As such, contractors are not in the position to make decisions in the same way a Federal Product Owner can. In commercial industry, the Federal/Commercial relationship doesn’t exist, so the Product Owner role may be more closely involved with the team.  Neither is right nor wrong, but the implementation of these roles on the project are managed specifically by the needs of the project, within each organization.

In conclusion,  although neither the Project Manager, Scrum Master, or Product Owner are explicitly designed to solve world hunger, at least we can agree that they all serve very different functions.  Properly staffing these roles could mean the difference between a mediocre or failing project and a winning one.