PMBOK and Scrum are like oil and water? I don't think so..

Project management methodologies based on PMBOK and Scrum have more in common than they are different, which is contradictory to the wide-spread belief that the two don't mix. They are very much the same except for one key difference. Well, both PMBOK and Scrum are controlled by the triple constraints of cost, schedule, and scope. So where’s the difference?
The difference is:  in PMBOK the scope is locked down so that the project schedule and cost can be estimated.
Scrum, on the other hand, embraces scope changes. So it only follows that no attempts are made to lock down scope. Instead Scrum promotes the approach where schedule or cost or both are locked down. This allows the scope or product feature set to be modified as necessary with a view to delivering maximum value to the user in a short period of time. This, of course, implies that Scrum projects, in most cases, are in a perpetual releasable state.

The traditional PMBOK plan-driven approach follows the PDCA (plan-do-check-act) cycle made popular by Dr. W. Edwards Deming, who is considered by many to be the father of modern quality control applies to both PMBOK and Scrum projects.
The following figure illustrates the PDCA cycle in a traditional PMBOK setting.

  

• Plan. Define the project objectives. Understand the requirements. Plan for implementation and delivery.
• Do. Execute the plan in incremental steps. A step may last a few weeks or months at the end of which there are artifacts, including partial system functions, that are made available for review.
• Check. Review the results of the plan execution. Test and analyze the results, identify what worked and what did not.
• Act. Modify the plan based on lessons learned in the "check" step: Go through the cycle again with the new plan to prevent defects in the previous iteration from occurring again.

The following figure illustrates the PDCA cycle in an Agile (Scrum) setting.

 
 

• Plan. Define the project objectives. Understand the requirements. Generate a list of product features called the product backlog. Prioritize the items in the product backlog in concert with users and business stakeholders taking into account the usefulness of a product feature and its associated cost. Create a plan for implementing the backlog items in order of priority. Break up the plan into incremental steps (or Scrums) and identify the backlog items to be implemented in every Scrum.
• Do. Execute the plan. Implement the items that are part of the Scrum.  A scrum typically lasts anywhere from 2-weeks to a month. At the end of the scrum, the product features are fully functional. They have been tested and the results validated as part of the Scrum.
• Check. Review the results of the plan (Scrum) execution. Test, analyze the results and identify what worked and what did not.
• Act. Take action based on lessons learned in the "check" step: Go through the cycle again with a modified plan. In other words, if the product backlog needs to be modified and the items re-prioritized, please go back to step 1 and do so.  Repeat the steps. 


Moving from PMBOK to Agile (or points in-between)
A PMBOK manager who is used to the traditional "command and control" approach must learn to lead from behind (see my blog on leadership styles).  Learn to hand control over to the team. Learn how to ask the right questions at the right time in order to provide guidance and direction to the team. Keep in mind that the manager (or Scrum Master) still makes the final decision and is responsible for the outcome of the decision, but this style recognizes the strength and knowledge of the team and is a sign that the manager is secure, confident and is not afraid to seek counsel from the team. This obviously is a style that most team members respect. One other thing: make sure that the manager knows, understands and believes in the Scrum process. This is important not only to motivate and mentor the team but also is critical to the successful completion of the project.

Good luck on your journey from PMBOK to Scrum or to any points in-between.

Comments

[Gary G.]

Excellent article. A comprehensive comparison between traditional project methodologies and Scrum. I agree there are more similarities than differences. It's all in the exceution.

[Laurent P.]

Great article!!!!! You know what? Traditional PMBOK and Agile have more in common than they have differences. Both require planning, without which the project will be in a mess. Both require identifying use cases (PMBOK) or user stories (Agile) to create the list of functions to be implemented (PMBOK)or the product backlog (Agile). Both require prioritization of functions based on resources and cost (PMBOK) or prioritization of user backlog based on value to the user (Agile).

I could go on and on...but you get the picture. If anyone thinks that Agile is a free-for-all methodology with no planning, discipline or structure you are in for a big surprise.

[John S.]

Product life cycles have shrunk dramatically since the dot com boom of the late 1990s. Neither traditional PMBOK nor Agile in their pure forms can support the need for fast turnaround times. We need a combination of traditional and Agile.