Agile under the PMI’s umbrealla

Posted on August 20, 2013 by ThePMJournal

Today I had an argument with one of the most fanatical supporters of “Agile”, I have ever encountered. It all started with two words: PMI and Agile. My colleague argued the traditional project management, as defined in the PMBoK by Project Management Institute (PMI) is totally different from project management from “Agile”. To prove this, he made ​​a presentation about “Agile” benefits compared to the traditional project management. I confess his presentation was exceptional, but despite his very well documented work, I couldn’t agree with his conclusions. This emerged into a scandal:

-How can you say Project Management defined by PMI is almost the same thing as project management from “Agile”? he asked me…

Despite my arguments, the discussion lasted for several hours. At one point, we became so passionate, we almost start fighting. My colleague’s conclusion was:

-Clear as mud: You don’t have Agile mindset! You need to read some books!

Although the discussion has been constructive, it let me a bitter taste. Overall impression I left behind was I really hate Agile, when actually I am a great supporter of Agile. I wondered: What precisely I said wrong? Why I made myself misunderstood?

After I reanalyzed key points of our argument, I concluded the main reason of misunderstanding was due to wrong use of technical terms: i.e. when we talked about the “PMI-PMBoK” we used the term “Waterfall” (development in “falls”) and we refer at “Agile” we used the term “Scrum”. Although is more than evident those words do not designate the same thing, in our daily life we used them improperly and we lost their true meaning.

Where misconception PMI=Waterfall come from?

In the book PMP Exam Prep de R.Mulcahy, when you reach chapter Project Life Cycle, a big and beautiful scheme is presented as below:

The image represents the cycle of a project from IT industry and reminiscent of phase’s sequence like in “Waterfall”. What it is been said between the lines, but is not underlined, is that Project Life Cycle is not always in cascade: Ideea, Planning, Execution, Testing, Release but can be a sum of mixed states(phases). What is to be noted: project management standard described by PMI in PMBoK is a framework and not a methodology. A framework is generic set of processes, tools, practices to serve to a particular problem (describes a model tell you what can be done, but not how). A methodology is set of methods, concepts, practices that produce concrete results in a repeatable way (tells you how to do it exactly and each time is the same). Starting from this definition, we could say also about Agile, is a framework, eventually composed by other sub-frameworks like Scrum, etc. and can be put in practice using several Agile methodologies (i.e: XP, Lean, Kanban, etc.). Because Agile is generally used in software industry (more details of software methodologies could be found here on wiki), while PMI-MBoK is a standard to all industries (not only IT), we could say PMI is the big brother of Agile.

Moreover, PMBoK is a framework can be put in practice on all types of methodologies: cascade, iterative, incremental, spiral, “prototype” or other combination of iterative and incremental methodologies such as XP (from Agile).

PMBoK “sees” a project as a sum of processes. A project, is an logical succession of 5 groups of processes (I, P, E, M & C, C) that can be represented ideally in the following way:

The order of the processes is depending on the Company and Project Manager who can decide if processes are applied in cascade, iterative or in other order. Although, in theory, the group order is: 1-Initiating (I), 2-Planning (P), 3-Execution (E), 4-Monitoring and Control (M & C), 5-Closure (C), if we want to display time allocated for each group in a common project, the image would look like:

What is important related to group processes:

• Monitoring and Controlling processes are present from the beginning of the project (starts from Initiating) until end of the project (it ends with the Closing)
• in time,  all the processes groups (I, P, E, M&C, C) are interleaved and/or overlapped.

During a complex process, the visualization (vs. time) of processes would look like a “texture” or “fabric” of processes:

Each project has such a “texture” of processes, which represents the project signature. A signature is a sequence of processes groups; i.e: (I, P, E, C) M&C, (I, P, I, C ) M&C. “Textures” and “signatures” types in a project, theoretically, are infinite, because the processes could overlap, interleave, could be eliminated (in this context, the term of “eliminated” should be interpreted as time spent on a process is “reduced to zero” ) or repeated as long as it needed. In above example, the signature is specific to a project developed with an iterative methodology. Here is how “signature” of an “Agile” project looks:

“Project cycle” and Processes

One of the concepts misunderstood is the processes are one and the same thing as phases of the Project Life Cycle. Because some groups can be eliminated (reduced to “zero”), projects phases could have the “reduced” signature (I, P, M&C): see example below.

In this case, it wasn’t no need for Execution(E) and neither of Closure(C), because in the process of Planning (P), after a risk assessment, it was decided (decisions, usually, are made during the process of Monitoring and Controlling – M&C) that the objectives defined in project charter cannot be achieved and it was needed to redefine the entire business case; the project was not Closed (C) or terminated, but was put “on hold” for a undefined period of time.

The name of the phases and the number of phases of a project cycle is sometimes dependent by domain/industry, while name of the phases and number of processes is independent by industry and is always the same (theoretically there are always 5 groups of processes present, but each organization could decide if some group of processes need to be “reduced to zero” or “eliminated”). A project cycle could have a large number of phases and only few phases could contain the groups of processes (in below example, organization decided to eliminate from “Design” phase, all the groups processes, because they consider them unnecessary):

Who says Waterfall should be a “cascade”?

Let’s say a project is developed using a methodology implementing Waterfall, but was planned to be delivered in multiple Releases. Lets suppose Releases are delivered one after another, like in a cascade. But this means the Release 2 could be increment of Release 1, in other words a project developed with Waterfall methodology, could be also incremental and iterative at release level (Iterative Waterfall). If above all, we planned the deliverable small enough (similar with work packages in PMI-PMBoK), then entire Waterfall development could be very similar with Agile development (which is iterative and incremental).

Agile under PMI umbrella

How can obtain from PMI framework a iterative methodology? Starting from the project “signature” (sequence of any group processes: I, P, E, M&C, C), through a proper sequence of processes (PMI processes) can be obtained a iterative methodology. Example: [(I, P, E, C) M&C], [(I, P, I, C ) M&C]. How can obtain from PMI framework an incremental methodology? In PMBoK it is been suggested you can obtain an incremental methodology using technique Role Wave Planning – project planning in waves as the project proceeds and the details become clearer).

PMI does not tell you how to manage a project, but rather a generic framework of what can you do. Project Manager decides what process will apply and in what order. We can conclude from a proper combination of project management processes, as defined in PMI, (interleaved, overlapped, iterated, in a specific order, etc) can be obtained any iterative and incremental development methodologies (any Agile methodologies). In a sense, Agile is under PMI‘s umbrella.

Following: How important are the diplomas and certifications?

Recommendation: Agile Earned Value Management