I was going to call this ‘Applying the Agile methodology and PMBOK for your projects’, but knew instinctively that two flexible and tailorable approaches could never have ONE right answer.
So I spent the best part of a day sketching out my thoughts, but swiftly came to the conclusion that there are a myriad of ‘the devil is in the detail’ aspects that could churn this article from pillar to post.
So before you make a decision to jump ship on this article, let me tell you that it is nothing more than the title says – an approach to the combination of the Agile methodology with PMBOK. I will sometimes refer to Agile as DSDM since that organisation has created the modern Agile standard.
If you have previously thought about the advantages of integrating a DSDM approach to your more traditional approach to project management, yet got drowned in the details, then this high-level view may encourage you to think again.
The more I think about it, the more I believe that what follows is nothing more than a ‘straw horse’ for you to think about, refine and take further, to disagree with at some level or another, but ultimately to get you ‘juiced up’ enough to harness the benefits of agile to one or more of your organization’s projects.
Let me start by being very contentious:
Having earned my project management stripes way back in the early nineties by managing Rapid Application Development and Joint Application Development (RAD/JAD) projects, and thereby giving me credibility in the ‘Ready-Fire-Aim’ uncontrolled world that would of eventually spawn Agile, I have to confess an empathy with the maturing agile approach.
So here is my point.
I’m also passionate about PMBOK and the value that it has brought to the world of project management.
But even the Project Management Institute and their Project Management Body of Knowledge, freely acknowledge that it is not a methodology; but rather a collection of 47 processes.
So if you, Dear Reader, are keen to amalgamate the best of PMBOK with the best of the Agile methodology, I would suggest that you start with the agile approach to project management, and both ‘cherry pick’ and tailor PMBOK to agile – rather than the other way around.
I did a little research on Google, and came to the conclusion that although there is already a wealth of information regarding the details of applying the Agile methodology with PMBOK, such information quickly dives into the detail and discusses the benefits or otherwise of both approaches – tending to drown the reader in information overload!
There is no getting away from the fact that DSDM emerged from the world of software development and IT projects.
But many organizations still believe that merging agile with their project approaches is a difficult marriage of cultures and specialism. Not True.
The latest refinement of agile is mature and flexible enough to be applied to any project with in any industry. Now let me contradict myself.
Take for example, managing a large construction project such as an office block or a bridge.
By their very nature, such projects need to nail down the requirements and specifications before mixing any concrete – as any changes would be catastrophic.
So such projects would seem to be poor candidates for the Agile methodology. At a high level I would agree. But that would be to miss the point. For example, the application of Timeboxes down at construction team level, the use of prioritization, facilitated workshops, and even the application of agile roles could still apply and aid project success.
But from the myriad of potential project types, take an example of installing a new facility or enhancing an existing one, or a relocation project, in fact any business change project will benefit from the inclusion of some or all Agile methodology attributes.
There are various terms that you will have come across, and the following graphic shows how they relate to each other within typical agile methodology phases.
It is clear that DSDM is the bedrock upon which the various methods and techniques sit. This article will focus mainly on the aspects of agile project management, while dipping into some of the key techniques contained within the DSDM method.
As a suggestion, you might start by looking at various agile documentation products created within each phase, and ask yourself what PMBOK management documentation products could be disregarded, or used/modified:
Now let’s check out the main product deliverables within each PMBOK process Group:
PMBOK is based around the ‘Plan – Do – Check – Act’ approach as laid out by Deming. But not surprisingly, when you view Agile methodology and PMBOK side by side, they have very similar characteristics:
So let us start by looking at the big picture – a start at overlaying the key phases and adding a selection of PMBOK process groups and key products. I have deliberately simplified the following diagram in order to suggest a first high-level step towards using both methodologies:
The first thing to notice here is that the agile methodology has three phases – pre project, feasibility and foundations which culminates in the creation of the high-level delivery plan. There is obviously a fairly strong correlation between those three phases and the PMBOK process groups of initiating and planning.
There is a clear method work flow from the terms of reference, leading to a high-level outline plan, and the production of the various key document products of business foundations, management foundations, and solution foundations.
With reference to PMBOK, the key documents are project charter, identification of stakeholders and the various processes that lead in an iterative manner to the creation of the project management plan. Other key aligned processes lead to the creation of identifying the human and non-human resources within the human resource management plan.
Let us stop for a minute and consider the main Agile methodology and PMBOK differences from the project manager’s perspective:
Project Management Styles and Responsibilities.
A traditional project positions the project manager to be fully responsible for creating the plans, marshaling the resources, giving out the work, and monitoring and controlling its effective implementation.
Compare and contrast this to the agile project manager who is there to motivate and support the empowered teams, where progress is demonstrated by the frequent delivery of products rather than progress reports. In addition the project manager is there to keep distractions away from the development team and to ensure that they have the right environment within which to create the various products.
The Team Leader role within the solution development team does the planning, monitoring and control.
This has several ramifications for PMBOK. The first is that the delivery plan is fairly high level with a high expectation of iteration and changes. Also, the processes within the planning process group will be shared between the team leader and the project manager.
PMBOK says that its project management plan is ‘progressively elaborated’, so in other words these fit nicely within the two Agile methodology principles of Develop iteratively and build incrementally.
In short, the PMBOK planning process group will be used at a very high level, and issue within the feasibility and foundations stages.
A quick look at the suggested contents of a typical agile delivery plan will quickly identify common ground between the various processes within the planning process group for a traditional project, albeit at a high-level.
Unlike a traditional project, the Agile methodology project fixes time and cost and quality, while allowing the prioritized features to vary, so that at the lowest level (a Development Timebox), the completion date is non-negotiable and must be met.
The methodology’s estimating, and hence project control, starts at the lowest level – the development Timebox. Since one or more Timeboxes occur within an increment, and one or more increments normally take place within a phase, and a project contains the seven agile phases, then estimating and control are both using the powerful ‘bottom-up’ approach.
Traditional projects would consist of the specialist team, the project manager, senior management, and supporting functions; all set within the framework of a customer and supplier environment.
A quick glimpse at the ‘alien baby’ diagram of a project using the Agile methodology should not cause any alarm when integrating this within a traditional project:
Of course, some role names, levels of responsibility, and skill sets may need to be modified. A facilitated workshop run during the early process groups of a PMBOK project could be easily used to refocus appropriate stakeholders as extended agile teams.
One fundamental difference and focus of this more flexible project, is the active involvement and both high and low level of business and customer representatives within the agile roles and responsibilities.
First a reminder that I’m suggesting we start with the Agile methodology and then adapt and tailor relevant PMBOK aspects.
When you look at the following graphic, you may be surprised to find how easy these techniques can replace traditional project thinking:
Just taking the first one, the use of facilitated workshops, here is a quick list of the potential areas where they could be used within an otherwise ‘traditional’ project:
I would like to discuss two more, as I know that they will open your eyes to potential partnership within a traditional PMBOK project:
Frankly, it is never too early within a project to discuss prioritization – even pre-project when using Agile methodology.
During the planning process group, the collect requirements process should adopt the use of ‘MoSCoW’ prioritization.
But prioritization does not start and end at requirements; it can be used at multiple points throughout the project. For example prioritizing risk responses.
These can occur at project, phase, increment, and of course solution development levels. They act as a powerful product development and control framework:
The most common use would be during the executing, and monitor and control process groups. But they can be used within the planning process group if that makes good sense to do so.
It is therefore natural to use Timeboxes to create any product type that would occur within a traditional project.
I am in danger of turning this article into a detailed training course on Agile methodology and PMBOK if I continue to dive any further into detail.
I started by stating that this was an attempt to give the reader further food for thought, and to see that there are many more doors that are already open to assist in the merging of PMBOK with Agile methodology than there are obstacles.
If you want to find out how to become an Agile Project Management professional, then CLICK for my forthcoming Agile Project Management Primer HERE!