Jenny and I are doing a really nifty Q&A on the JavaRanch Saloon. People are asking us all sorts of great questions about Head First PMP, and we’re doing our best to answer every single one of them. We’ve gotten a lot of really good questions about Agile and how it works with PMP. It looks like some people assume that there’s some basic conflict between running an Agile shop and how a PMP certified project manager might typically run a project. Some of the questions were really good, and I think some of our regular readers would be interested in the answers I came up with. So here are a few of the best questions and answers from the forum in the last couple of days.
HF PMP: how does it fit with Lean Software Development…
Gian Franco asked:
How does PMP fit with practices as explained in Lean Software Development (by Poppendieck) or Agile practices in general?
I wrote a blog post about this a while back called “What About Agile?”
https://www.stellman-greene.com/2007/04/27/what-about-agile/
There are definitely a lot of things that the PMBOK(r) Guide and PMP exam cover that aren’t addressed at all with Agile — like whether a fixed price contract is better or worse for the seller than a cost-plus contract. But there’s one really important way that both the PMBOK(r) and Agile are very similar: they both recognize that managing change is an important part of a successful project. And in that respect, you’ll definitely find that your knowledge of Agile can help you when you study for the PMP exam.
And Gian had a follow-up question:
Well :), let me put it in another way…, In Lean SW development requirements churn is considered to increase costs, I don’t know much about PMP, but suppose it resembles to Prince2 (another comparable projectmanagement method) then the initial phases of specification might fall in this category of specifying too much too early.
The PMBOK(r) Guide was developed so that it can be applied to any kind of project, not just a software project. So projects that fit into its framework tend to develop all of the requirements up front, before any work begins. That’s because all of the plans for the submarine or office building need to be finalized and agreed upon before you hire the construction crew to break ground.
There will be changes that happen. But if those changes involve very large alterations to the blueprints and you need to tear out the last three floors you put in, it gets very, very expensive.
Oddly, the same is true of software in many cases. There are some changes that need to be made, and which you could have found had you “churned” through the requirements a little more before you started building the software, and now you’ve got a bunch of code you need to tear out — and it would have been a lot more efficient to take the time up front to figure out the requirements and then only build your software once. Unfortunately, many people don’t consider that “Agile”. (I think they’re wrong — I think that doing a lot of iteration before you even start writing code can be the most efficient and customer-focused way that you can build software… but that’s a story for another day.)
Darya Akbari asked:
Can one say that PMP is not agile :) ?
That’s an interesting question. But I’d ask the opposite question: can an Agile shop fit into the PMBOK(r) Guide framework?
The reason is that the PMBOK(r) Guide doesn’t define one specific set of doing things. In fact, just the opposite. It says that you need to select a particular methodology based on what you know about your industry and past projects, the specific needs of the project, the deadline and milestones, etc. It doesn’t say that every project needs to include specific things. Instead, it includes things that typically happen on most projects — and practices that are most commonly found. And remember, the PMBOK(r) Guide doesn’t just apply to software: it needs to be general enough so that it can include practices for construction, industrial, civil engineering, electrical and other kinds of projects.
So can a typical Agile process fit into the PMBOK(r) 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(r) Guide team members on our technical review team repeatedly stressed iteration and iterative development.
One of the strongest points in the PMBOK(r) 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(r) 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(r) 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).
Rogerio Kioshi asked:
I’ve read about SCRUM. Does PMP have anything to do with this metodology?
The PMP exam won’t have any questions specifically about SCRUM. But if you have a good understanding of SCRUM, then that will give you a good leg up on studying for the PMP exam. The reason for this is that if you’ve spent time thinking about SCRUM, then you probably have a good understanding of a lot of the ideas behind team communication, project schedule constraints, and activity sequencing, and those are core concepts that you need to understand to become PMP certified.
You’ll still have studying to do, though!
Need advice on HOW to start a new Software Product
This isn’t a question about Agile specifically, but it’s still a great question. Paul Michael Laborte asked:
I hope this doesn’t sound too off topic. Anyway here it goes…
I’m currently a software developer with a Monday to Friday job.
Right now, I’m looking for opportunities which would allow me to have a 20% time (pretty much like google).During that 20%, I’m thinking of developing my own software product.
I would be needing to wear different hats so I really think HFPMP would be of great value.Aside from the contents of the book, would you have any other tips for entrepreneur aspirants like us
That’s a really interesting question. How do you start out a software project?
Well, if you want to get your project started out right, the first thing you need to do is figure out what it is you want to build. That might sound a little odd — of course you know what to build, right? Otherwise, why would you start a project? But if you look at a lot of projects that went off the rails at one point, one thing that you’ll see over and over again is that many problems can be traced back to the fact that one person wanted to build A, while another person wanted to build B.
There are a lot of tools and practices that can help you with this. My favorite is a Vision & Scope document — mostly because it’s very lightweight, only takes a few minutes to write, and it’s something that anyone can read if they want to learn what it is your project does. Also, it’s something that serves really well as a front page for a wiki or project website, and immediately brings people up to speed on it. Basically, the Vision & Scope tells you very briefly who needs the software, what their needs are, and how you’ll meet those needs (by explaining the features of the software you’ll be developing).
To be perfectly honest, Head First PMP may not really help you as much with this particular problem. But it’s something that Jenny and I wrote a whole lot about in our first book, Applied Software Project Management. We have a whole chapter on starting out a project using a Vision & Scope document.
Other things you need to think about when you’re starting out your project — which we also talk about in depth in Applied Software Project Management — are figuring out how your users are going to interact with the software, setting up a version control system, and doing test-driven development.
I definitely recommend taking an hour or two and really think about how you’ll handle those things. One way I’ve seen a lot of people do this is start a wiki for your project, and have a separate page that says how each of those things will be handled. It doesn’t have to be fancy or anything, and it shouldn’t take long to throw together. But just doing that will really help get your head straight about them, and set your project in the right direction from the beginning.
If you’ve got a burning question and you’re wondering what we think about it, send it to us using our “Contact Us” page! We love answering questions from our readers.
Jenny and I were lucky enough to have a lot of contact with some of the people who created the PMBOK while we were working on the book. And as it turns out, they were very much into iteration and iterative development. But the PMBOK and the PMP exam need to apply to all kinds of projects, including non-iterative, non-software ones. And iteration does have its place, even in construction. You should definitely approach the design and planning iteratively. But while iteration may work fine for project plans and blueprints, but it doesn’t work particularly well once you’ve broken ground.But there is one big area where Agile and the PMBOK Guide are really similar: managing change. Change management is really important in the processes you need to know for the PMP exam. They are very clear on the fact that changes happen on every project, and that you need to make sure that you plan for change and expect it to happen. Every single knowledge area you need to study stresses that no matter what sort of project you’re working on, you need to constantly look for changes, and make sure that you change course whenever changes are necessary.Sound familiar? It should! Because it’s one of the fundamental goals of Agile development — the Agile manifesto itself says that we’ve come to value “responding to change over following a plan”. And that’s really similar to what the PMBOK tells us: that when there’s a change, we need to modify our plans in order to accommodate that change. (It also wants us to make sure that we know how much the change is going to impact the project, and that everyone involved agrees that the cost of making the change is worth the benefit… which is definitely a good idea too.)
All in all, I think that there’s a lot of value in the ideas behind the PMBOK and the PMP exam, and that an Agile shop could benefit from understanding and applying them. I definitely don’t think that the PMBOK and Agile development are incompatible. But it’s important to keep in mind that they solve different problems… and that neither Agile nor the PMBOK are intended to be a silver bullet to automatically repair all troubled projects!Oh, one more thing to remember. Jenny and I are software people, and we’ve spent most of our careers trying to figure out how to deliver software projects better. That’s what our