Enriching PMBOK® Guide by practices and techniques of agile project management of software development

Abstract

Agile project management methods of software development became very wide spread in a recent decade. These methods appeared in response to inability of 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 A Guide to the Project Management Body of Knowledge (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 assess how they could be incorporated into PMBOK.

Introduction

According to CHAOS 2004 survey results (Standish Group, 2006) most of software development projects are still challenged or even failed, more than that, the progress is still not very evident – see Exhibits 1-3 (Standish Group, 2006).

Software development projects success rates

Exhibit 1. Software development projects success rates

Average percent of cost overrun in software development projects

Exhibit 2 Average percent of cost overrun in software development projects

Average percent of time 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 improving project management in software development.

The Agile Manifesto (Larman, 2004, p28) presents main values of 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 Agile Manifesto is shared by many project managers working in software development field, who regard PMBOK as something bureaucratic and adding not so 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, p35). Although the main message of Agile Manifesto is “People still matter”, each Agile method is first of all very well defined process; and there are several useful techniques, which deserve at least to be considered as candidates for incorporation into PMBOK® Guide. Let us don't forget that “The 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, p3)

The main objective of the paper is to discuss which practices and values of agile community could be introduced as general ones and possibly incorporated into PMBOK.

Agile principles and PMBOK

In this section principles of Agile movement are reviewed with an emphasis on relationship with PMBOK.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” (Larman, 2004, p28); “Deliver customer value” (Highsmith, 2004, p27); “Fitness for business purpose is the essential criterion for acceptance of deliverables” ” (DSDM Consortium, 2007). – These principles point out 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 change for the customer's competitive advantage” (Larman, 2004, p28); “Encourage exploration” (Highsmith, 2004, p27); “All changes during development are reversible” (DSDM Consortium, 2007) – These principles show quite different approach to project scope as compared to PMBOK which reads: “The approved detailed project scope statement and its associated WBS and WBS dictionary are the scope baseline for the project” (PMI, 2004, p104). It could be understood as if the scope is frozen. The scope in agile projects is very often defined as Feature Breakdown Structure whereas WBS is defined only for the next iteration at a WBS level, which is pretty fine grained. The suggestion here is to emphasize that the scope can be defined on a high level in order to embrace and not to 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, p28); “Employ iterative, feature based delivery” (Highsmith, 2004, p27); “The focus is on frequent delivery of products” (DSDM Consortium, 2007) – These principles well in sinc with PMBOK and point to practices, which are crucial to project success.

“Business people and developers must work together daily throughout the project” (Larman, 2004, p28); “Active user involvement is imperative” (DSDM Consortium, 2007). “A collaborative and co-operative approach between all stakeholders is essential” (DSDM Consortium, 2007). – This principle is of course about project philosophy. To compare with: “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, p24) Agile principles are about trust, shared vision and shared responsibility, while PMBOK suggests more formal style when contract is a basis for relationships with stakeholders. It is well known than an Agile project is successful when customer actively participates in project and in fact becomes part of a team. Maybe it is worth to discuss this major shift in project philosophy toward 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, p28). – Well known practice from PMBOK.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” (Larman, 2004, p28) – Once again well known practice.

“Working software is the primary measure of progress” (Larman, 2004, p28) – Self evident.

“Agile processes promote sustainable development” (Larman, 2004, p28)

“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” (Larman, 2004, p28) – Once again about shared responsibility.

“Continuous attention to technical excellence and good design enhances agility” (Larman, 2004, p28); Champion technical excellence” (Highsmith, 2004, p27) – Technical principle 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, p28); “Simplify” (Highsmith, 2004, p27) – One more technical tip in software development.

“The best architectures, requirements and designs emerge from self-organizing teams.” (Larman, 2004, p28); “Build adaptive (Self-Organizing, Self-Disciplined) teams” (Highsmith, 2004, p27); “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, p28) – Well known continuous improvement practice in quality management.

Agile process and PMBOK project phases

The process structure of typical agile project looks most expressively in Scum. Exhibit 4 shows Scrum project structure (Rally SDC, 2006)

Scrum project structure

Exhibit 4. Scrum project structure

As compared to project phases in PMBOK there is a good mapping to an Agile iteration as well as to an Agile release cycle ( see Exhibit 5, 5a). Source: (Sliger, 2006).

PMBOK project phases mapped to an Agile iteration; PMBOK project phases mapped to an Agile release

Exhibit 5 and 5a. PMBOK project phases mapped to an Agile iteration; PMBOK project phases mapped to an Agile release.

Agile practices and PMBOK

The Exhibit 6 presents practices from most popular Agile methodologies: XP, Scrum and DSDM. Possibility of incorporation into PMBOK Guide is discussed in comments.

Core Agile practices Core Agile practices Core Agile practices

Exhibit 6. Core Agile practices

Conclusion

Traditional practices are not necessarily the best ones. There are many things in Agile movement that just reinvent and point to best practices described in PMBOK, rejecting bad “traditional” practices like waterfall. Agile methodology, being people oriented, offers somewhat different project management philosophy and techniques, which leverage trust and cooperation. The customer becomes part of the team and shares responsibility for project success or failure. The project team becomes self disciplined, self directed community. The first topic for discussion is whether this philosophical shift could be reflected in PMBOK.

Other topics for discussion consider Agile-born techniques, which are deemed to be new to project management community and applicable in most areas. Among them: feature breakdown structure; value driven and risk driven planning, timeboxing.

References

DSDM Consortium (2007). Official DSDM overview presentation. Retrieved on 03/02/2007 from http://www.dsdm.org/

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

Standish Group (2006) CHAOS 2004 survey results. Retrieved on 02/22/2007 from http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

Project Management Institute. (2004) A guide to the Project Management Body of Knowledge. (PMBOK® Guide) Third Edition. Newton Square. PA: Project Management Institute

Rally SDC (2006). Five levels of planning. Retrieved on 03/02/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 03/02/2007 from http://www.rallydev.com/documents/rally_survival_guide.pdf

Sutherland, J (2005) Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects. Retrieved on 03/02/2007 from http://jeffsutherland.com/scrum/Sutherland2005FutureofScrum20050603.pdf

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2007, Alexander Lesnevsky
Originally published as a part of 2007 PMI Global Congress Proceedings – Budapest

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.