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.

[Jorge Alsina]

If Scrum or any other brand of Agile do not have anything to do with basic processes of project management, where are you led to, people? To burn the PMBoK? Do you people know PMBoK is only a project management guide? Do you any idea that agile is under the "project management" tutelage?

I have always thought of the principles and the way of work of Agile (or Scrum) as of high benefit for some industries or classes of business, but indeed not for all.

Agile/scrum are only methods of organizing the project trying to get incremental work done and proof, and was born because of vast failures in the software industries projects, due mainly to incapacity of organizing and getting the work done in waterfall life cycle management. So Agile was born.

Great! Now try to sprint in heavy construction, research & development or pharmaceutical projects. For the time being, Scrum will be just for software

But all projects, be "agile" or not, need of requirements/scope management, scheduling, budgeting, quality assurance, risk management, procurement processes. So if PMBoK processes are not necessary, how is this people doing?

PMBoK never says the processes have to be applied in the way they appear in the standard, or yes?

Do you need project managers? What for?

[Samuel Prasad]

Jorge Aisna,

Software development projects are creative endeavors. Any attempts to commodotize and fit it into a manufacturing paridigm will not work. PMI for many years has been successfully selling the PMBOK/PMP concept hammering home the fact that identifying requirements, creation of work-break-down sctructures, estimating time, cost and resourcse, and rigirous planning are critical to project success. THIS IS NOT TRUE, especially in software development where many of the tasks cannot be identified ahead of time. Innovative tasks evolve as more information about a project becomes available. It is impossible to plan ahead. We only can plan for things we know. Put plcaholders. DO NOT PLAN ON SEPCULATIVE THINGS.

PMI and PMBOK will loose it relevance on creative projects unless they make the appropriate changes to address the requirements of adaptive SDCLCs like Agile and Xtreme.

Sam