Like the authors of the Capability Maturity Model (CMM), professionals at the Project Management Institute (PMI) state that the Project Management Body of Knowledge (PMBOK) is a guide to best practices and that organizations must use their own discretion when implementing the practices. This is important to note, because the association that many IT professionals have with the PMBOK is that it advocates the waterfall methodology, when in fact it does not. Years of traditional plan-driven software development using waterfall methodologies have created an assumption that a waterfall approach is the only way to adhere to the practices prescribed in the PMBOK.
But I've found that many of the PMBOK practices can be followed (albeit it sometimes quite differently) in other methodology models, including those of the agile family. And like the PMBOK guidelines, agile methodologies have their own invalid assumptions to overcome, the most common being that they promote "cowboy coding" and are just shy of total chaos. In fact, agile methodologies, if followed with discipline and rigor, are compliant with CMMI and PMBOK best practices, just as traditional waterfall is compliant. What's different--beyond the obvious command-and-control dictatorship vs. self-organizing teams--is when and how these practices are executed and the new lexicon used by agile practitioners.
The Project Management Process Groups
The first translation is from the PMBOK naming conventions for the project management process groups to Jim Highsmith's Agile Project Management framework is the project management life cycle (Figure 1). The PMBOK identifies initiating, planning, executing, controlling, and closing as the process phases within project management. Highsmith reconfigured these phases to better reflect the reality of how software is truly developed, and defined them as envision, speculate, explore, adapt, and close. The envision phase is where the product vision is defined enough to provide a bordered sandbox within which to work. During speculation, that vision is translated into a set of features and an expected timebox within which to deliver those features. The explore phase is the iterative and incremental development of potentially shippable code. Production transitions into the adapt phase by scheduling stopping points along the way to inspect and adapt both the process and the product. Finally, in the close phase, teams have the opportunity to reflect on their achievements and make decisions based on what they've learned.
Figure 1: PMBOK Project Management Process Groups mapped to Jim Highsmith's Agile Project Management framework
A further translation of some of the activities performed in each phase is also warranted. Six key knowledge management areas defined in the PMBOK and deserving special attention are Project Integration Management, Project Scope Management and Project Time Management, Project Quality Management and Project Risk Management, and Project Human Resource Management . For each of these areas, the practices advocated by the PMBOK have their cousins in agile, but they are significantly different in their implementation.
A key deliverable in integration management is the project plan document, prepared and owned by the project manager. In agile software development, with its emphasis on just-in-time design and participatory decision making, this activity translates into several different envisioning and planning exercises done on an iterative basis. Rather than defining all of the elements of a project plan at the beginning of the project--scope, work breakdown structure, schedule, assumptions, and controls--the agile project manager will focus on planning using a level of detail that's more appropriate and realistic for the time horizon.
Waterfall's big up-front planning translates into agile's continuous planning, where gross-level features and estimates are planned at the beginning of a release, and more detailed planning of tasks and effort is done at