Fred Koos, PE, PMP, CSM, Pittsburgh PMI VP of Education

INTRODUCTION
In the IT field, some of our Pittsburgh PMI Chapter members have been using agile software development methodologies for years.  Others have used more traditional methodologies for software development.  In fields outside of IT, many are curious on how agile methodologies can help their project’s success.  This article is a review of the Manifesto for Agile Software Development (simply called the “agile manifesto” below) aligned with some points in the PMBOK® Guide, Fourth Edition, and some other best practices.

In the journey to apply more agile practices, the agile manifesto gives an important foundation.  It helps to make the many direction setting decisions while applying agile practices. The agile manifesto has similarities to various processes in the PMBOK® Guide.  This comparison is interesting and facilitates step in the journey of applying agile practices.

A journey to apply agile practices can include the PMI-ACP (Agile Certified Practitioner) credential.  For those interested in this path please contact the Fred Koos, VP Education, Pittsburgh PMI, at FredBKoos@IEEE.org for information on support through our PMI chapter.

EFFECTIVE METHODOLOGIES ARE SYSTEMS OF SYNCHRONIZED SUBSYSTEMS
In relating the agile manifesto to the PMBOK® Guide it is important to treat a project management methodology as a system of many interconnected subsystems.  To be effective the entire system should be lean and synchronized.  Many of us read the PMBOK® Guide with a preconceived environment, culture, methodology or system in which the processes are applied.  In agile organizations this higher level system may be different than in some of our experiences and preconceptions.  Thus, in applying agile practices in any particular organization, please consider the organization’s methodology holistically.

TYPES OF PROJECTS WHERE AGILE PRACTICES ARE EFFECTIVE
Agile practices have deep roots in software development; so much of the agile literature is from a software perspective.  Still, many agile practices apply to all types of projects.  It is interesting that some agile practices pull from Lean concepts which have deep roots in manufacturing.  Many practices are very portable across project types.

THE MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
The Manifesto for Agile Software Development (Agile Alliance, 2001) follows:

“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

It is interesting that agile focuses largely on people, products, customers, and change.  Then agile recognizes value of processes, tools, documentation, contracts, and planning as needed supporting the former.

SELECTED PMBOK® GUIDE AND OTHER PRACTICES RELATED TO THE AGILE MANIFESTO
As a step along the agile journey, let’s compare the four points in the Manifesto for Agile Software Development (Agile Alliance, 2001) to some other familiar concepts.

• "Individuals and interactionsover processes and tools":
  • Clearly great leadership must include a focus on individuals.  As project managers we lead and manage individuals and teams.
  • The PMBOK ® Guide (Project Management Institute, Inc., 2008) has one process for Project Human Resource Management defined as follows: “Develop Project Team – The process of improving the competencies, team interaction, and the overall team environment to enhance project performance.”  Notice the PMBOK® Guide focus on “team interaction” and notice the similar agile manifesto focus on “Individuals and interactions”.
• "Working softwareover comprehensive documentation":
  • A lean business process should be focused on the end product (software in this case) and documentation should only be created if it adds value.  Otherwise it should be considered waste and eliminated per Lean concepts.
  • In the PMBOK® Guide (Project Management Institute, Inc., 2008) the WBS (Work Breakdown Structure) is discussed.  PMP’s will know that a WBS, including its work packages, provides a focus for the direction of the project’s work.  Here a “work package … refers to products or deliverables that are the result of effort and not the effort itself.”  Thus a focus should be on the “product” (working software), similar to the agile manifesto’s focus on “Working software”.
• "Customer collaborationover contract negotiation":
  • We know that an effective business benefits greatly by a focus on the customer. 
  • In the book, The SPEED of Trust: The One Thing that Changes Everything (Stephen M.R. Covey, 2006) Covey discusses examples of how collaboration and trust has provided much more value and speed in business than spending effort on detailed contract negotiations.
  • In the PMBOK® Guide (Project Management Institute, Inc., 2008) process group of Project Communications Management, one process is “Mange Stakeholder Expectations – The process of communicating and working with stakeholders to meet their needs and addressing issues as they occur.”  This “working with stakeholders” is similar to the agile manifesto’s “customer collaboration”. 
• "Responding to changeover following a plan":
  • Change is constant and great project teams manage change well.
  • In the PMBOK® Guide (Project Management Institute, Inc., 2008) one of the five process groups is the “Monitoring and Controlling Process Group. Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes”, similar to “Responding to change” in the agile manifesto.
  • In the PMBOK® Guide (Project Management Institute, Inc., 2008) there is a process “Perform Integrated Change Control.”  “Perform Integrate Change Control is the process of reviewing all change requests, approving changes, and managing changes to deliverables, organizational process assets, project documents, and the project management plan.”  This is similar to the agile manifesto’s “Responding to change”.
  • Those familiar with the PMBOK® Guide should be well versed in responding change.  The word “change” is in the PMBOK® Guide 759 times, including references to changes in the PMBOK® Guide itself.

With the elements of the agile manifesto being similar to some elements in the PMBOK® Guide, the use of the word “over” in the agile manifesto helps to define how to make a project more agile.  The emphasis is on being more agile vs. more fixed structurally.  This does not imply a total lack of structure, but a reduced focus on structure for the sake of structure.  In the journey to be more agile, many decisions are made daily that can lead to being more or less agile.  Putting a stronger focus on the items to the left of the word “over” while not ignoring the items to the right of the word “over” requires finding the right balance.  Balancing the right and left side of the word “over” is an important art of leading agile teams.

The above comparison does not imply that following the PMBOK® Guide alone will result in an agile methodology.  Agile practices complement the PMBOK® Guide and provide more specific direction to be agile.  Also, from the agile perspective, specific elements of the PMBOK® Guide complement agile methodologies.

This comparison of the PMBOK(R) Guide to the agile manifesto should help PMPs take a step in the journey to be more agile.

SUMMARY
The items in the Manifesto for Agile Software Development should not be foreign to us.  The focus on the left side of the word “over” may be an adjustment in our practices and habits.  This view of the agile manifesto is just one step in the journey to be more agile.  Other topics, including the benefits of agile and Scrum, will be addressed separately.  More information is in references below. 

ADDITIONAL AGILE INFORMATION
Additional information on agile practices can be found in the references that PMI recommends for the PMI-ACP certification as follows:

Agile Retrospectives: Making Good Teams Great; Esther Derby, Diana Larsen, Ken Schwaber; ISBN #0977616649
Agile Software Development: The Cooperative Game – 2nd Edition; Alistair Cockburn; ISBN #0321482751
The Software Project Manager’s Bridge to Agility; Michele Sliger, Stacia Broderick; ISBN #0321502752
Coaching Agile Teams; Lyssa Adkins; ISBN #0321637704
Agile Project Management: Creating Innovative Products – 2nd Edition; Jim Highsmith; ISBN #0321658396
Becoming Agile: ...in an imperfect world; Greg Smith, Ahmed Sidky; ISBN #1933988258
Agile Estimating and Planning; Mike Cohn; ISBN #0131479415
The Art of Agile Development; James Shore; ISBN #0596527675
User Stories Applied: For Agile Software Development; Mike Cohn; ISBN #0321205685
Agile Project Management with Scrum; Ken Schwaber; ISBN #073561993X
Lean-Agile Software Development: Achieving Enterprise Agility; Alan Shalloway, Guy Beaver, James R. Trott; ISBN #0321532899

SELECTED AGILE SOURCES OF INFORMATION AND ACTIVITIES
For information on future agile training, study groups, and other professional development through our PMI chapter please continue to check the Professional Development page at www.PittsburghPMI.org or contact Fred Koos, VP Education, Pittsburgh PMI, at FredBKoos@IEEE.org.
The Manifesto for Agile Software Development: http://agilemanifesto.org/
PMI Agile Certified Practitioner, PMI-ACP (http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx)
PMI’s PMBOK® Guide and other project management information (www.PMI.org)
PMI Agile Community of Practice (http://agile.vc.pmi.org/Public/Home.aspx)
Jesse Fewell of ripplerock which is based in Pittsburgh is the founder of the PMI Agile Community of Practice.
Pittsburgh Agile Group (http://www.meetup.com/PittsburghAgile/)
Agile Alliance (http://www.agilealliance.org/)
Scrum Alliance (http://www.scrumalliance.org/)

BIBLIOGRAPHY
Agile Alliance. (2001). Manifesto of Agile Software Development. Retrieved December 30, 2011, from http://agilemanifesto.org
Project Management Institute, Inc. (2008). A Guide to the Project Management Body of Knowledge. Newton Square: Project Management Institute, Inc.
Stephen M.R. Covey, S. R. (2006). The SPEED of Trust: The One Thing That Changes Everthing. New York: Free Press.