I am working with an organization which is using scrum (one of the agile methods) for their product development. One day, I requested one of the managers there to create a “work breakdown structure” for a new project that was recently initiated in the organization. And the moment I did that, I heard an expected (but weird) question – “so are we going to stop agile?” 🙂

Somehow, I have come across this question several times, where I felt that people have (strongly) tagged PMP (or PMBOK) with waterfall approach! I think that this is really unfortunate! What is even more surprising and unfortunate is that, along with people who are not PMP, even the PMP certified guys are also having this misconception (i.e. waterfall = PMP / PMBOK).

I personally disagree with this! And therefore, I thought of writing something about it. Hopefully this will help to clarify some of these misconceptions….

What is scrum (or any agile method)?

I consider agile as just one of the types of project life cycles. Any project, done using whichever approach, will have phases. When a project has phases which are time-boxed and short (1 to 4 weeks) and every phase will have same length and the project will approach to deliver as much scope as possible in give time-box (per phase), then this is one more type of a project life cycle. And an agile method follows this approach. Off course, agile has many other rules of the game but essentially it is one of the methods of doing projects and hence its a type of “project life cycle”. And this is exactly what is mentioned in PMBOK (refer section 2.4 – specifically 2.4.2.3 of PMBOK – 5^th edition).

What is PMBOK?

Take any project, it will have a set of phases, a way to arrange those phases and hence a life cycle. And while managing any project you will have to balance 9 different aspects – viz. scope, time, cost, quality, resources, risks, communication, vendors, and stakeholders. Also, any project and hence each phase of any project will go through 5 stages of how it will be managed – it is initiated, planned, executed, monitored and closed.

This is true for any project, irrespective of which approach (lifecycle) it follows, which method you follow, which industry it is, which geography it is, which domain it is. And it is very much true for agile approach also (e.g. sprint planning, execution, monitoring – DSM, closing – retrospective).

Take any project, any approach, any industry, there are common set of challenges, viz. customers change requirements, requirements are misinterpreted, technical solutions turn out to be more difficult than anticipated, estimates change, plans change, management generally commits more than what is possible, etc.

Since there are certain “generic” challenges, they compiled a “generic” framework – a set of practices, techniques, based on past experiences of doing thousands of different projects, to help learn from those. And this is PMBOK.

So, why there is the confusion?

Even I don’t understand this 🙂 You will never find anything like “frozen or locked scope or schedule” mentioned in PMBOK! In fact, at several places in PMBOK you will find that it acknowledges the fact of changes happening in almost everything (and not just requirements) and hence advocates “progressive elaboration”. Isn’t agile also advocating the same thing? Let’s see some examples. Following summary is from PMBOK guide’s latest, i.e. 5^th edition.

PMBOK Section	Topic in PMBOK	What is mentioned in PMBOK?	Contradict with agile?	Why?
1.3	What is Project Management	Due to potential for change, developing a plan is an iterative process and is progressively elaborated throughout the project. Progressive elaboration allows the PM team to define work and manage it to a greater level of detail as the project evolves…	No!!	Leaving high level scope as epics and refining scope as smaller stories – is advocating the same concept. High level release plan but detailed sprint plan and keep revising high level plan at end of each sprint, based on gained experience, is the same thing!
1.4 (Table 1.1)	Project, program, portfolio	Scope is progressively elaborated throughout the project life cycle	No!!	It nowhere mentions that requirements have to be frozen! In agile you will have a DEEP backlog, items at top are refined, items at bottom less refined and is emerging! PMBOK is stating the same thing…
1.4 (Table 1.1)	Project, program, portfolio	PM progressively elaborates high level information into detailed plans throughout the project life cycle	No!!	Plans are nothing but planning is everything – agilists say this – PMBOK is also saying the same thing!! And it has been saying this for more than last 2 decades!
5.2.3.1	Requirements documentation	Requirements may start out at a high level and become progressively more detailed as more about requirements is known.	No!!	Your backlog will have epics and some refined stories. This will keep getting refined as you progress – PMBOK is saying the same thing!Also, section 5.1.3.2 does talk about requirements prioritization process.
5.3.1.1	Scope statement	Product scope description: Progressively elaborates the characteristics of product described in project charter and requirements. Scope statement is progressively elaborated throughout the project	No!!	Your backlog will have epics and some refined stories. This will keep getting refined as you progress – PMBOK is saying the same thing!Nowhere has it talked about freezing scope….
5.4	Create WBS	This means subdividing project deliverables into smaller more manageable components. Decomposition may not be possible for a deliverable that will be accomplished far into the future. Team should wait until the deliverable is agreed on so that the details can be developed at appropriate time. This technique is referred to as “rolling wave planning”	No!!	Your backlog will have epics and some refined stories. Epics will keep getting broken into smaller stories (INVEST) as you progress through the backlog.This will keep getting refined as you progres – PMBOK is saying the same thing!Why people tag it to waterfall approach?? 🙂
6.5	Estimate durations	Inputs of estimates of activity originate from the persons or group who is more familiar with nature of work. The estimate is progressively elaborated and the process considers quality and availability of input data.	No!!	You do high level estimates and with every passing sprint, as scope and situation becomes more clear, revisit the estimates, refine it….basically keep estimating – PMBOK is saying the same thing!Nowhere in PMBOK is it mentioned that plans should be cast in stone!
9.1	HR Planning	Primary requirements regarding required project team members and their competencies are progressively elaborated	No!!	You start with a team, assume their velocity. As every sprint goes by, you are expected to inspect and adapt – teams adapt their behavior and improve over time!
5.6	Control Scope	Controlling a change doesn’t mean resisting a change. Controlling scope ensures that all requested changes are processed through “integrated change control process”. Uncontrolled expansion to scope without adjustment to time, cost or resources is scope creep. Change is inevitable. So some type of change control process is mandatory for every project.	No!!	Well, backlog of your project will change – either new items may get added or existing items may blow up / inflate. You MUST assess its impact on time, cost or resource and take appropriate action.This HAS TO BE AND IS DONE even in agile projects!PMBOK is stating the same fact! Change is inevitable – so some process is mandatory to deal with it for every project.Uncontrolled change is not acceptable even in agile 🙂

 

On same lines I can explain how different techniques practised with agile are already mentioned in PMBOK. We need to, however, understand that these are described in “generic” terms, because PMBOK is not meant only for software development projects, but practically any project!

For instance “planning poker” is mentioned as “group decision making” technique in PMBOK, backlog refinements are “facilitated workshops” or “brainstorming” and so on. I will probably write a separate blog on techniques part… 🙂

These are just some of the examples. As you can see, nowhere PMBOK advocates any specific approach, neither agile or waterfall. Because, even with waterfall approach, WBS should be created, scope, estimates should be progressively refined. In fact I think that agile methods compliment PMBOK philosophies. One step further, I think that agile methods force you to follow whatever is mentioned in PMBOK.

My experience is that, before agile methods, we were not using PMBOK in true spirit. PMBOK has the “best practices of project management” – generic enough – captured based on experience of thousands of projects. So, it can’t contradict a specific approach!

In summary, I think that PMBOK was always right. Our interpretation and application of its guidelines, till today, was probably wrong and now with newer approaches (agile methods) finally we have started following what is intended by PMBOK guidelines 🙂