Agile development and PMP

By Sanders Kleinfeld

Andrew Stellman (co-author of Head First PMP and Head First C#) has a great post on his and Jennifer Greene's blog Building Better Software, where he tackles some JavaRanch reader questions about how Agile development processes mesh/conflict with PMP® practices and the principles espoused by the PMBOK® Guide. An excerpt:

So can a typical Agile process fit into the PMBOK® Guide? As far as I can tell, the answer is yes. One hint is that when Jenny and I were working on Head First PMP, the PMBOK® Guide team members on our technical review team repeatedly stressed iteration and iterative development.

One of the strongest points in the PMBOK® Guide (ones that is stressed on the PMP exam) is that it really emphasizes collaboration with the stakeholders, and keeping them in the loop on all important decisions. Another thing that it really stresses is responding to change — and it's very clear that the customers need to be involved in decisions about change.

There are definitely some things that Agile people might not agree with. It may seem very documentation-heavy, and very concerned with contracts. But the PMBOK® Guide was developed in a world where subcontracting is very important, and where a lack of documentation or attention to the contract can mean that the company can get sued and go out of business. I've spent a lot of time working in a consulting situation, and even the friendliest clients can turn into adversaries if you don't have everything documented properly. But if you go back to the Agile manifesto, you'll see: "Individuals and interactions over processes and tools", "Customer collaboration over contract negotiation", and "Working software over comprehensive documentation". While the PMBOK®Guide highly stresses individuals and interactions, customer collaboration, and working software (in the form of deliverables that meet the customer's needs). But it needs to pay attention to processes and tools (since that's what a framework is made of), contract negotiation (because a process is no good if it puts your company out of business), and comprehensive documentation (because it's really hard to build a strip mall or highway overpass without it).

And, of course, if you're interested in learning more about software development, we have just the book for you :)

Comments

Post a comment: