Showing posts with label AgilePMP. Show all posts
Showing posts with label AgilePMP. Show all posts

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:






Wednesday, December 31, 2014

Year End Post: Approach to All PMP Preparation Programs Now Changed



Mid last year, I changed the coaching approach to PMP preparation. It is outlined here

Looking back, it has been a big success. There has not been a single instance in any workshop (many since the last one where I changed the approach), where the team could not remember all the 5 process groups, all the 10 knowledge areas and all the 47 process areas. 

Also, it has been a remarkable revelation what a team can collectively accomplish. In fact, in all the programs, the team members are themselves surprised that it is possible to remember them all - 62 in total.

Still, some issues were playing out in my mind when I coach the PMP aspirants. There are quite a few, but top of them are:
  1. How a person without any formal knowledge of Project Management can grasp the PM fundamentals easily?
  2. How to understand and remember the ITTOs? 
  3. How quickly one can become a Certified PMP?

1. Making a Layperson understand PMBOK:

There are many materials and/or books in the market to prepare for PMP Exam. But my emphasis has always on Project Management Body of Knowledge (PMBOK) Guide. I always say to the aspirants that in case of any conflict among your reference materials or books, PMBOK Guide is the final one. It must be your final reference source.

However, PMBOK Guide, as written, is in a Specification Format, which does not make an exciting read. Also, the coverage area of PMBOK is immense. For a first time learner on project management - even for an experienced project manager - the area of coverage is overwhelming. Very few read PMBOK end to end and those who do, are lost in the immense depth provided by PMBOK.

The new approach completely simplifies the process of learning PMBOK. When any participant asks what s/he should read before coming to the program - I say:"Do not read any material or book. No beforehand knowledge is needed. You need not read anything at all.Many of them are taken back with this statement - but I ask them to come with a completely free mind. 

So, if you want to learn PMP, you need not know anything at all about PMBOK - absolutely nothing at all.

2. Remembering Inputs, Tools and Techniques, and Outputs (ITTOs):

How many ITTOs are there in PMBOK Guide? Well, there are some 600+ ITTOs.  Below is a list across all the knowledge areas (Link - View Directly)

Now, that is quite a long list. Can you remember all of them? No! In fact, not needed.

The PMP exam rarely asks a direct ITTO question. It does not test your memorizing ability of ITTOs. Rather, it does test - what you as a project manager would do in a specific situation and which specific Tool and Technique you can apply? You need to know why these are taken as Inputs and why some of them are outputs? You need to now - how a Tool or Technique is helping to get a particular output?

However, you have to remember some of the key ones like various baselines, various estimation techniques, various quality tools so on. Also some of the processes are not very easy to remember - like "Direct and Manage Project Work" or "Perform Quantitative Risk Analysis" or "Perform Integrated Change Control".  Why they are named so? How to remember them?

In both the above aspects, the approach has been significantly changed.

3. Being a Certified PMP:

One can say "He (or she) has gone through 35 PDU Program for PMP" or can say "A Certified PMP". Which one sounds good? You know. It is like saying - "Have prepared for the Engineering Entrance Exam" Vs "An Engineer". You know which one sounds appropriate. Is not it?

Your success will be measured being a Certified PMP. That is the bottom-line. I have not come across a single candidate who went for the exam with the preparation that I asked him/her to do and have failed in the exam. It has NEVER happened. With the new approach, I believe the time to get certified becomes shorter.

***

Considering all above three,  I have applied the changed approach in last few sessions - for "PMP Prep" and "Practical PMP with MS Project". It also will be applicable for "Agile PMP - PMBOK and AgileBOK" where PMBOK is taught as in "Practical PMP" and candidates are prepared for the PMP Exam. 

The good news is - the new approach is working quite well. Hence decided to write this post. If you want to know PMBOK in a very simple way; to understand its intricacies, the needed ITTOs, the flow of ITTOs across the 47 processes, and want to get quickly certified on PMP - welcome to a new way of learning.


To All My Readers - Wish You a Very Happy New Year 2015.


Thursday, April 04, 2013

Agile PMP: PMBOK Vs Agile - Comparison and Convergence (Part - 2)


Did you read Part - 1 of this series? Would suggest that you do.

Now, let us proceed on this part. PMBOK has set the defining standard for Project Management and will continue to do so. There is no second opinion about. In this post, we will the check, comparison and convergence between PMBOK and Agile, at the process group level.

Comparison: PMBOK Vs Agile

5 Process Groups (Source - PMBOK, PMI)

PMBOK comes with 5 process groups (PG) - Initiating, Planning, Executing Monitoring and Controlling and Closing. Briefly - Initiating and Closing happens once, whereas Planning, Executing are repeatedly looked upon by Monitoring and Controlling.

Agile also has a framework with its is defined items - let us say phases! What are they? Jim Highsmith, in his book (Agile Project Management - Creating Innovative Products) puts it lucidly. There are 5 phases - Envision, Speculate, Explore, Adapt and Close. To keep it simple - Envision and Close happens once. 


5 Phases - Agile Project Mgmt. Framework (Src - Jim Highsmith Book)
However, Speculate, Explore and Adapt happen repeatedly or in an iterative fashion, along with incremental delivery. This is known as Agile Project Management Framework or APM in short.

PMBOK has not only 5 process groups, it has 10 knowledge areas as well 47 process areas in its latest addition. PMI has added Stakeholder Management knowledge area in 5th edition. However, in Agile it is not detailed like that of PMBOK, rather they have kept it open to much process tailoring internally. 

Convergence: PMBOK And Agile

So, where do they converge?

In both Agile's APM and PMBOK PG, The fundamentals are inline with Demming's cycle - Plan,Do,Check and Act (or P-D-C-A) cycle. That binds both the concepts - 5 process groups for a project management plan (PMP) or 5 phases for APM. 
  • Plan - Planning in PMBOK; Envision in APM 
  • Do - Execution in PMBOK; Explore in APM 
  • Check & Act - Monitoring and Controlling in PMBOK; Adapt in APM
Execution, M&C and Closing happens repeatedly in PMBOK and in similar lines Speculate, Explore and Adapt happens frequently Initiating and Closing happens only once during the life cycle (considering one phase of a product life cycle). Similarly, Envision and Close happens once. . 

However, it must be noted that the process group in PMBOK and phases in APM are not direct matches. There is a lot of subtlety involved!

Also, there are questions on how you progress in groups, knowledge areas, process areas in PMBOK and corresponding in respective phases in APM - like say building user stories, preparing your plan, checking on progress and so on? It will be beyond the scope of this post. It needs in depth explanation and understanding - happens in my workshops and speaking engagements. 

In conclusion, as noted before PMBOK is very detailed where as Agile keeps it quite light. Nevertheless, someone who understands PMBOK transition to Agile is not that really difficult!

Next, we will cover on User Stories. Stay tuned.

This Series: Part -1

Thursday, January 03, 2013

Agile PMP: PMBOK Vs Agile - Comparison and Convergence (Part - 1)

The copy for 5th Edition of PMBOK has been made available last month to all PMI members. Thank you PMI. Copy for public distribution is expected be available in this month.

In this post, we will see how PMBOK guide, one of the most referred one worldwide in management practices, talks of Agile. I have been following PMBOK closely since its 3rd Edition on which I was certified. In 5th Edition, there has been significant changes as compared to 4th Edition. But, till 5th Edition, PMBOK, never mentioned the Agile word explicitly in its guide.

Before, we go into the Agile and PMBOK, let us take a look at how many times, PMBOK has mentioned of Agile. 

Number of times Agile word mentioned in PMBOK 3rd Edition - 0
Number of times Agile word mentioned in PMBOK 4th Edition - 0
Number of times Agile word mentioned in PMBOK 5th Edition - Around 5 to 7 times!

PMBOK 5TH EDITION


Now, does it mean that PMBOK suddenly woke up to Agile standards? No! For long, PMBOK has talked of Iterative approach with incremental delivery. PMBOK also talked of rolling wave planning, i.e., plan will be cleared as and when the project progresses. Complete Plan may not be clear in the beginning. 

However, for the 1st time Agile word has been mentioned in PMBOK guide, with the growing adoption of Agile and understanding that how volatile many project may become - especially in the software world, where requirements keep on changing all the time!

Comparison: PMBOK Vs Agile

True to its continuous saying, PMBOK says in its 5th Edtion that it is a Guide and NOT a methodology - like Agile, PRINCE2, Waterfall. So, if you want to take on comparison, PMBOK has been explicit - Its principles also can be applied to Agile and some of its heavy or light forms, but in no may it is saying you follow one in particular.  

Convergence: PMBOK And Agile

The 5th edition of PMBOK talks of 3 types of life cycles in a project. 

1. Predictive Life Cycle - Can be completely planned beforehand
2. Iterative and Incremental (I & I) Life Cycle - Was there also in earlier PMBOK guides, but has been more clearly defined. 
3. Adaptive Life Cycle - Here Agile is mentioned explicitly. 

AGILE CYCLE

But then how come it is different from Iterative and Increment development cycles. Good question! In Adaptive cycle, as compared to I & I cycle, the churn is high, the predictability is low and speed of execution is faster. Agile manifesto talks of 2 to 4 weeks of cycle and delivery at the end of each iteration. Please note that delivery does not mean it is to be shipped, but it is potentially shippable. The later part also falls into one of the 12 principles of Agile. 

Also, in PMBOK in certain sections Agile has been mentioned and how the plans to be treated in Agile mode is mentioned. 

But, having said that, does it mean that PMBOK has completely explained on how exactly Agile will be followed? I do not think so. There are many areas with confusions - such as WBS, Activities, Contracting methods, Estimation approaches, Baselining concepts (and hence EVM), Dependencies et al - which needs far better understanding for someone who follows Agile principles! We will check on in on later posts. 

This Series: Part - 2