Sunday, October 04, 2020

Agile Asanas: Mapping Traditional Project Roles (PMBOK) to Agile Frameworks


I get this question many times from management practitioners on how various roles in a project will translate to the roles in Agile frameworks. Let’s say your team is following the Scrum framework, where you have three roles: Scrum Master, Product Owner and Team Member. 

How will these roles map to the traditional project roles? 

[ To read all posts in Agile Asanas series, use this link. ]


For the mapping, I’ll take the reference of the PMBOK® guide, which is considered to be a leading  guide in project-program-portfolio (PPP) community . But that doesn’t help if you have some idea in Scrum. Also, because I mentioned in the post title how to map to the Agile frameworks - not in particular Scrum – you need to have an understanding in approches as well, e.g., XP, Kanban, among many others. 

To answer this question, you need to have these three:

  • Very good understanding on the role of a PPP Manager, the role of team members and stakeholders.
  • Sound understanding of the roles played in various Agile frameworks such as XP, Scrum, Kanban, Scrumban etc. 
  • A change in the mindset as you move to Agile.

For this Agile Asana article, I assume you have a sound understanding of the project team and roles and also a solid understanding of various Agile frameworks. 

With this assumption, let’s understand briefly the knowledge areas (KA) of the PMBOK guide.

Traditional Knowledge Areas 

The below table informs on the various knowledge areas applicable for a project, as noted in the PMBOK guide, 6th edition.


In the above table, do note that Resource Management entails:

  • Human resources such as team members, contract workers.
  • Non-human resources, which can have physical as well as non-physical resources.

Another tricky area is the Stakeholder Management

  • Your team members are also your stakeholders. 
  • There can be hidden stakeholders in your project or even completely unknown ones. Hence, stakeholder identification is an iterative process. 

Next Mapping the tables to the individual roles in Scrum/XP/Kanban etc. I’m not going to use any specific framework or method in Agile. Hence, I’ll keep the terms to be generic across the roles. 


Mapping Project Roles to Agile Frameworks

As you can see in the below table, I’ve mentioned varieties of roles such as Product Owner (PO) or Product Manager, Scrum Master (SM) or Agile Project Manager (APM). It can be also Kanban Flow Master in Scrumban approaches, and Team or Development Team. 


Considering the table, I’ve noted some key points below:

  • Quality is everyone’s responsibility. Hence, “Yes” has been put for all three roles: PO, SM/APM and Team.
  • Risk management and mitigation are also everyone’s responsibility. Hence, “Yes” has been put for all three roles.
  • Stakeholder Engagement: The Product Owner deals with the customer/sponsor and brings the customer and other needed stakeholders to reach an agreement on the features or functionalities to be taken up.
    The Scrum Master (or Agile Project Manager) main job is to protect the team from external interruptions and interventions. Hence, this role is significant in dealing with the stakeholders. 
  • Communication happens across all these roles and hence, “Yes” has been put for all of them. 
  • Resource management involves management of both human and non-human resources. As you would have noticed, I’ve put the TEAM as the owner of human resource management. This area is acted upon differently by other two roles in an Agile team. 

It’s also pertinent to note that there will be other managers, stakeholders such as partners, regulatory bodies that may be involved in a project. If such is the case for your project, you can decide on their roles in the project and with whom they can interact with. For example:

  • If regulatory bodies are there, then there will be compliance needs. In such cases, the Product Owner or Product Manager will be involved. 
  • If the project is part of a bigger program or portfolio, then during integration, other managers can play a role for integration.


Conclusion
As you can see, it’s not that difficult to map the responsibilities of the project manager to various roles. Of course, for that to happen, you need to have a sound understanding on what project management is about and roles being played by the team in an organization. 

However, the hardest part is usually the third part mentioned in the beginning:
A change in the mindset as you move to Agile.

To understand more on Agile Mindset, you can read the following piece:

If you can address it in your team, you are well set to move into Agile frameworks.


References:






No comments:

Post a Comment

Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.