Agile Project Management – Extending PMBOK

I have long held the belief that agile is only a part and a subset of the wider topic of project management.  I feel there are various aspects of project management that aren’t particularly covered by any of the most popular agile methods, or at least not by Scrum and XP (Extreme Programming).

Therefore I have always been keen to highlight the importance of project management beyond what is provided for by agile methods, and equally keen to help project managers understand where agile methods fit in to what they already know.

In the PMI’s PMBOK (Project Management Body of Knowledge), agile is not specifically mentioned, however PMBOK tends to describe what a project manager should be managing, and not much about how to manage it.  Arguably, agile methods tend to focus a little more on how.

Although agile and traditional project management methods place a completely different emphasis on different parts of the project lifecycle (eg waterfall/PRINCE2 puts a heavy emphasis on the planning phase, whereas agile does not), it is somewhat possible to augment PMBOK with agile methods, as they are largely complimentary.

I hope that one day this will actually happen as an official and global standard, but in the meantime I thought I’d have a go at expanding on PMBOK, and in the style of PMBOK, to give my view about where agile fits in with the wider discipline of project management as a whole.

PMBOK highlights 5 distinct phases that are typical in many projects:

• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing

I think the same phases can be and usually are applied to agile projects, but as I mentioned earlier, the emphasis and detail within the phases would change accordingly, and some of the language would also change too.

Because of the iterative nature of agile methods, all of these phases take place firstly at the project level, initially only at a high level, and then again in more detail within each iteration or ‘Sprint’ (Sprint is the name given to an iteration in the Scrum agile methodology).

In PMBOK, under the Executing phase of a project, there is one particular process labelled 3.5.1 ‘Direct and Manage Project Execution’.  PMBOK says this is the process of performing the work defined in the plan, but leaves more or less everything else to the project manager’s imagination.

Of course there are sections in PMBOK about managing scope, managing resources, managing finances, managing the schedule, etc, but PMBOK tends to cover what should be done and doesn’t usually explain how.

So the first extension to PMBOK that I would write for agile project management would be to drill down on 3.5.1 ‘Direct and Manage Project Execution’ to cover managing iterations within an agile project.  I have done that below, in the same style and using similar language to PMBOK, and also retaining the PMBOK numbering system.

Here it is…

3.5.1    Direct and Manage Project Execution

Direct and Manage Project Execution is the process of delivering the features defined in the ‘Product Backlog’.  In agile projects, the work is performed in short, fixed-length iterations.  Each iteration has 4 key processes, reflecting 4 of the phases of a typical project:

• Plan Iteration (Sprint Planning)
• Execute Iteration (Sprint)
• Monitor & Control Iteration (Manage Sprint)
• Close Iteration (Sprint Review)

3.5.1.1    Plan Iteration (Sprint Planning)

Plan Iteration (Sprint Planning) is the process of discussing what can be delivered in the next iteration, clarifying requirements for selected ‘User Stories’, identifying tasks and estimating the effort, and committing to the work.

3.5.1.2    Execute Iteration (Sprint)

Execute Iteration (Sprint) is the process of producing working software as planned for the current iteration.

3.5.1.3    Monitor and Control Iteration (Manage Sprint)

Monitor and Control Iteration (Manage Sprint) is the process of tracking work in progress and assisting successful delivery.

3.5.1.4    Close Iteration (Sprint Review)

Close Iteration (Sprint Review) is the process of reviewing work completed in the current iteration, reviewing progress against the overall plan, reflecting on how the iteration went, and deciding how to improve in the next iteration.

These processes are repeated for each iteration until the project’s objectives are achieved, or until it is decided that the objectives are no longer worth pursuing.

—

If you think I’ve missed anything important, have got anything in the wrong place, or just want to make comments, please do and I will refine this idea further and publish an update with your input.

Kelly.