Enriching the PMBOK® by practices and techniques of agile project management of software development
Agile project management methods of software development have become very widespread in the recent decade. These methods appeared in response to an inability of a majority of software companies to deliver products on time, within budget and meeting customers' expectations. The question arises if agile project management practices and techniques may enrich the PMBOK® Guide. There is strong evidence that the answer to this question is “yes,” although agile principles and values may sound subversive.
This paper reviews agile project management values practices and assesses how they could be incorporated into A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
According to CHAOS 2004 survey results (Standish Group, 2006) most software development projects are still challenged or have even failed; more than that, the progress is still not very evident; see Exhibits 1–3 (Standish Group, 2006).
Exhibit 1 – Software Development Projects' Success Rates
Exhibit 2 – Average Percent of Cost Overrun in Software Development Projects
Exhibit 3 – Average Percent of Time Overrun in Software Development Projects
Although the report relates to “big” companies with huge projects, and there is an opinion that the situation is somewhat different in small software shops, it is quite clear that software development is a field where project management still needs considerable improvement. It is believed that agile methodology will help improve project management in software development.
The Agile Manifesto (Larman, 2004, p. 28) presents the main values of the new methodology:
- Individuals and interactions—over processes and tools
- Working software—over comprehensive documentation
- Customer collaboration—over contract negotiation
- Responding to change—over following a plan
The subversive message of the Agile Manifesto is shared by many project managers working in the software development field who regard the PMBOK® Guide as something bureaucratic that does not add much value to their work. “Too much structure not only kills initiative and innovation, it consumes enormous chunks of time. The fundamental issue is not that these initiatives are valueless, because they are not, but that they fundamentally value structure over individual knowledge and capability. And that's why they are so difficult to implement—people feel devalued” (Highsmith, 2004, p. 35). Although the main message of the Agile Manifesto is “People still matter,” each Agile method is, first of all, a very well-defined process, and there are several useful techniques that deserve at least to be considered as candidates for incorporation into the PMBOK® Guide. Let us not forget that “[t]he primary purpose of the PMBOK® Guide is to identify the subset of the Project Management Body of Knowledge that is generally recognized as good practice” (PMI, 2004, p. 3).
The main objective of this paper is to discuss which practices and values of agile community could be introduced as general ones and possibly incorporated into the PMBOK® Guide.
Agile Principles and PMBOK® Guide
In this section principles of the Agile movement are reviewed with an emphasis on their relationship with the PMBOK® Guide. Very good mapping of Agile to PMBOK® Guide practices were suggested by Sliger (2006). The comparison of Agile with traditional project management was provided by K. Hass (2007).
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” (Larman, 2004, p. 28). “Deliver customer value,” says Highsmith (2004, p. 27). “Fitness for business purpose is the essential criterion for acceptance of deliverables” (DSDM Consortium, 2007). All of these principles point out the well-known philosophy that project goals are achieved if the customer is satisfied.
“Requirements are baselined at a high level” (DSDM Consortium, 2007). “Welcome changing requirements, even late in development. Agile process harness[es] change for the customer's competitive advantage” (Larman, 2004, p. 28). “Encourage exploration” (Highsmith, 2004, p. 27). “All changes during development are reversible” (DSDM Consortium, 2007). These principles show a quite different approach to project scope from the PMBOK® Guide, which reads, “The approved detailed project scope statement and its associated WBS and WBS dictionary are the scope baseline for the project” (PMI, 2004, p. 104). This could be interpreted as if the scope is frozen. The scope in Agile projects is very often defined as Feature Breakdown Structure where the WBS is defined only for the next iteration at a WBS level, which is fairly fine grained. The suggestion here is to emphasize that the scope can be defined on a high level in order to embrace and not prevent future changes.
“An iterative and incremental approach is necessary to converge on an accurate business solution” (DSDM Consortium, 2007). “Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter time scale” (Larman, 2004, p. 28). “Employ iterative, feature based delivery” (Highsmith, 2004, p. 27). “The focus is on frequent delivery of products” (DSDM Consortium, 2007). These principles are well in sync with the PMBOK® Guide and point to practices that are crucial to project success.
“Business people and developers must work together daily throughout the project” (Larman, 2004, p. 28). “Active user involvement is imperative…. A collaborative and co-operative approach between all stakeholders is essential” (DSDM Consortium, 2007). This principle is, of course, about project philosophy. Compare these statements with the following: “The project management team must identify the stakeholders, determine their requirements and expectations, and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project” (PMI, 2004, p. 24) Agile principles are about trust, shared vision and shared responsibility, while the PMBOK® Guide suggests a more formal style where the contract is a basis for relationships with stakeholders. It is well known than an Agile project is successful when the customer actively participates in it and, in fact, becomes part of a team. Maybe it is worthwhile to discuss this major shift in project philosophy toward a more cooperative and trustful model.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” (Larman, 2004, p. 28). This is a well-known practice from the PMBOK® Guide. The following also is a well-known practice: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” (Larman, 2004, p. 28).
“Working software is the primary measure of progress” (Larman, 2004, p. 28). This is self-evident.
“Agile processes promote sustainable development” (Larman, 2004, p. 28).
“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” (Larman, 2004, p. 28). This statement again emphasizes shared responsibility.
“Continuous attention to technical excellence and good design enhances agility” (Larman, 2004, p. 28). “Champion technical excellence” (Highsmith, 2004, p. 27). These technical principles are applicable to most areas.
“Testing is integrated throughout the lifecycle” (DSDM Consortium, 2007). This principle refers to test first practice described in the next section.
“Simplicity—the art of maximizing the amount of work not done—is essential” (Larman, 2004, p. 28). “Simplify” (Highsmith, 2004, p27). These represent more technical tips in software development.
“The best architectures, requirements and designs emerge from self-organizing teams” (Larman, 2004, p. 28). “Build adaptive (Self-Organizing, Self-Disciplined) teams” (Highsmith, 2004, p. 27). “DSDM Teams must be empowered to make decisions” (DSDM Consortium, 2007). This principle is again about shared responsibility and emphasizes that people matter in software development maybe more than in any other industry.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” (Larman, 2004, p. 28). This is a well-known continuous improvement practice in quality management.
Agile Process and PMBOK® Guide Project Phases
The process structure of a typical Agile project looks most impressive in Scum. Exhibit 4 shows the Scrum project structure (Rally SDC, 2006).
Exhibit 4 – Scrum Project Structure
As compared to project phases in the PMBOK® Guide, there is good mapping to an Agile iteration as well as to an Agile release cycle (see Exhibit 5 and Exhibit 5a; Sliger, 2006).
Exhibit 5 and Exhibit 5a – PMB0K® Guide Project Phases Mapped to an Agile Iteration; PMB0K® Guide Project Phases Mapped to an Agile Release
Agile Practices and the PMBOK® Guide
Exhibit 6 presents practices from the most popular Agile methodologies: XP, Scrum and DSDM. The possibility of incorporation into the PMBOK® Guide is discussed in the Comments section of Exhibit 6.
Exhibit 6 – Core Agile Practices
Traditional practices are not necessarily the best ones. There are many principles in the Agile movement that just reinvent and point to best practices described in the PMBOK® Guide. However, the Agile methodology, being people oriented, offers a somewhat different project management philosophy and techniques that leverage trust and cooperation. The customer becomes part of the team and shares responsibility for the project success or failure. The project team becomes a self-disciplined, self-directed community. The first topic for discussion is whether this philosophical shift could be reflected in the PMBOK® Guide.
Other topics for discussion consider Agile-born techniques, which are deemed to be new to the project management community and applicable in most areas. Among them are the following: feature breakdown structure, value-driven and risk-driven planning, and timeboxing.
DSDM Consortium. (2007). Official DSDM overview presentation. Retrieved on March 2, 2007, from 8698%20Open%20Unified%20Process%20(2).pdf
Hass, K. (2007, May). The Blending of Traditional and Agile Project Management PM World Today [Electronic Version]. Retrieved on February 26, 2008, from http://www.pmforum.org/library/tips/2007/PDFs/Hass-5-07.pdf
Highsmith, J. (2004). Agile project management: Creating innovative products. Boston: Addison-Wesley.
Larman, C. (2004). Agile and iterative development: A manager's guide. Boston: Addison-Wesley.
Project Management Institute (PMI). (2004). A guide to the project management body of knowledge (PMBOK® Guide) (3rd ed.). Newtown Square, PA: PMI.
Rally SDC. (2006). Five levels of planning. Retrieved on March 2, 2007, from http://www.rallydev.com/documents/five_levels_of_planning270706V302.pdf
Sliger, M. (2006). A project manager's survival guide to going Agile. Retrieved on March 2, 2007, from http://www.rallydev.com/documents/rally_survival_guide.pdf
Standish Group. (2006). CHAOS 2004 survey results. Retrieved on February 22, 2007, from http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Sutherland, J. (2005). Future of Scrum: Support for parallel pipelining of sprints in complex projects. Retrieved on March 2, 2007, from http://jeffsutherland.com/scrum/Sutherland2005FutureofScrum20050603.pdf
© 2008, Alexander Lesnevsky
Originally published as a part of 2008 PMI Global Congress Proceedings – St. Julian, Malta