Building Better Software

One of the best things about writing a Head First book is that you get feedback from other Head First authors. Our editor, Brett (who you may know from Head First OOA&D), got some interesting feedback from Bert Bates. Bert was going through Head First PMP, and pointed out — and rightly so — that at first glance here seems to be some distance between the PMP approach to projects and the Agile approach.So he’s right. There’s definitely some distance between what you’ll see on the PMP exam and in the PMBOK® Guide, and what you’ll see in an Agile development process like XP, SCRUM, or Crystal. There’s a lot of stuff Agile does that isn’t addressed in the PMBOK, and there’s a lot that’s on the PMP exam that Agile doesn’t address. But this shouldn’t really be a surprise to anyone. See, the PMBOK wasn’t written specifically for developers. A lot of projects that use the PMBOK processes and principles are things that you can’t do iteratively — like, say, highway construction or building a skyscraper. That’s why you see a lot of focus on things like subcontracting and procurement, risk management, communications (which you need to plan for really carefully when you’ve got a thousand people working on a project!), and budgeting. These are things that Agile doesn’t address because they’re just out of its scope.That’s not to say the PMP stuff doesn’t work on software — in fact, it works really well. So why isn’t the opposite true? Why couldn’t an Agile process work for, say, building a high-rise?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 first book was about. We spend some time in that book talking about Agile — and a lot of time talking about some specific practices that were popularized along with Agile development: refactoring, test-driven development, continuous integration, pair programming and a few others. We love those practices, and regularly use them on the job. Personally, I always do test-driven development when writing my own code. But that’s definitely an area that you simply don’t see on the PMP exam, and for good reason. What does it even mean to build, say, a highway on-ramp using test-driven development? (Actually, that question may actually turn out to have a meaningful answer. If anyone can think of one, please let us know!)

Be Sociable, Share!

•