Agile Principles and PMBOK® Guide
In this article, 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.
Suggested Read: Agile method for planning and controlling innovative projects
“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.