≡ Menu
Pawel Brodzinski on Software Project Management

PMBOK Can Be Agile Too

I was a part of hot but interesting discussion yesterday on agile community meeting. I was trying to show situations where agile doesn’t have to be a perfect solution. On the list of examples there were one-man R&D project like these done in Google and a tiny startup. A point I made was agile methods are too strict for these environments – you don’t need pair programming, daily stand-ups or 2-week sprints there.

Then the whole thing started. People went with argument that it’s not about every single technique which is a part of Scrum or XP. As far as we’re aligned with Agile Manifesto we’re still agile even if don’t follow every practice. And if some values from “the black list” of Manifesto are important for the customer (e.g. documentation) we should put enough focus on that.

At the first moment I got lost a bit. We can switch anything off as far as it does make sense or is forced by the customer and we’re still agile. Well, this actually means we can have pretty much formalism around which, if I remember correctly, was something agile was trying to avoid.

After a while I changed my mind. Hey, it’s me who advise you to take only tools which works for you in specific situation. It’s me who advocates for common sense in project management above following any rulebook. I definitely wouldn’t tell you to blindly follow any methodology.

This approach however means that you can call agile pretty much any methodology out there. As far as your methodology choice is based on reasonable arguments – e.g. the client forcing you to use more formalized or more heavy-weight process you’re still agile. If you skip some practices because you can’t have stand-ups in the team spread geographically and you can’t relocate these people – that’s fine. You’re still agile. If you put much focus on process to align with the rest of your org you can still say how agile you are.

That actually means you can use PMBOK to run your projects and basically be agile. You can have one of more formalized methodologies and be aligned with values of Agile Manifesto at least in these places where it’s under your jurisdiction. Which makes the whole holy war around agile quite irrelevant by the way. If that’s exactly what my adversaries were trying to convince me to I have to admit they succeeded. However I’m not sure if they would go that far even though that’s only interpretation of their arguments. After all I don’t consider myself as agile expert so I have to base on opinions of these who do.

A disclaimer: I do appreciate agile techniques. I believe short cycles are better than long ones. I think that everyday communication within a project is a must. I hope to see my team working with Kanban soon. And hell no, I don’t consider myself as agile-hater although I was probably labeled that way yesterday by a few people.

in: project management

12 comments… add one

  • Glen B. Alleman June 26, 2009, 1:30 pm

    The notion of a "graded" method set is common in PMBOK, DOE 413.3, NASA, and DoD program management domains.

    The entire set of practices is narrowed depending on the program or project attributes. Typcially there are 5 classes of projects, ranging from a single person effort, to billions of dollars of development with dozens of integrated teams.

    The key is that there are processes applicable across the specturm, and the management picks which class of project and the "graded guide" says what to apply.

    That way people don't "make stuff up," they follow a process. Rememebt Scrum and XP are HIGHLY structured development methods.

  • Pawel Brodzinski June 27, 2009, 5:25 am


    My point of view on the subject is actually the same. The problem is some people tend to treat agile as a source of all good in the world and more formalized approaches as the source of all evil. Which is of course wrong, since every method, no matter if agile-labeled or not, should be appropriate to the situation.

    Another thing which struck me strongly was tendency to throw out parts of agile structure which doesn't suit to the example. "If you sit in a single room you don't need stand-ups since you basically on the meeting all day long." The funny thing Scrum at the same time says the team should be located in one room and people should do stand-ups.

    I'm cool about that – if that works for someone they can cut Scrum in a half and still call themselves agile. That's only a label after all. But on the other hand they should let people exercise the same task with other methodologies. Unfortunately quite often it doesn't work that way since most of the time anything based on Prince-2 or PMBOK will be called highly formalized and heavy-weight, no matter how much it is adjusted to specific, maybe agile, environment.

  • Glen B. Alleman June 28, 2009, 3:22 pm

    The irony of course is the agile processes are VERY formal, structured and process centric. The XP and Scrum processes are explicity defined in the literature from each "owner." In much the same way Prince-2 is. PMBOK of course is not a method, but a survey of process groups and knowledge areas that "should" be found in all methods.

  • Pawel Brodzinski June 28, 2009, 11:50 pm


    You should try to deliver this message to agile zealot group. I guess the response would be far from enthusiastic.

    Sometimes I think we have a similar situation to .net versus java discussion, which is irrelevant most of the time. We can achieve pretty much the same using different techniques and you can't say one is universally worse or better than others. It all depends on the specific situation you're in.

  • Michael June 29, 2009, 7:06 am

    Good thoughts, once again.

    I was part of an online discussion recently about the value of a PMP. And it was equally frustrating because so many people's conclusion was that the PMP is "worthless" and they based this mostly on the fact that they assumed the PMBOK was essentially the Ten Commandments of project management, and that it was not scalable and it required you to follow every practice and method it taught.

    The problem is, so many people out there want to find the "Bible" of project management. They don't want to think for themselves. They want to find the perfect methodology and be able to follow it step by step to the letter and magically have successful projects. So, if someone points out a step/point/idea in their latest bible that doesn't fit, then they throw it out and move on to the next.

    Anyway, good thoughts again, Pawel.

  • Pawel Brodzinski June 30, 2009, 1:23 pm


    Even when they find their bible appealing they stick with it no matter what which is equally bad.

    Nothing can substitute common sense. And the hammer is neither the best nor the only tool in the toolbox. Even if it suits most of the tasks we do. The same is with any methodology out there.

  • Glen B. Alleman June 30, 2009, 3:00 pm


    Common Sense is neither common nor sensical. Much of what passes for common sense is not based on any underlying principle it’s just anecdotes that have worked for the current situation.

  • Pawel Brodzinski June 30, 2009, 3:15 pm


    This is the old discussion we had here and on your blog. We may understand common sense as something a bit different. Either way I'm going to stay wit common sense as a guide which helps me to choose right techniques in right situations.

  • Glen B. Alleman June 30, 2009, 6:28 pm

    With no attmept to influence your position, might I make a small suggestion to broaden your horizons a tiny bit with a quote from Russell Lincoln Ackoff, one of the western world's better thinkers…

    "Common sense … has the very curious property of being more correct retrospectively than prospectively. It seems to me that one of the principal criteria to be applied to successful science is that its results are almost always obvious retrospectively; unfortunately, they seldom are prospectively. Common sense provides a kind of ultimate validation after science has completed its work; it seldom anticipates what science is going to discover."

  • Pawel Brodzinski July 1, 2009, 1:51 am


    I actually fully agree with the quote you mentioned. Here in Poland we have a saying that we're always wise when damage has already been done.

    It works that way with pretty much anything. Estimation? On the lowest level you actually guess to some point how much this small fetaure, class, function will take. 3 hours or 4 hours? If you wrote very similar function a couple of times before (aka you're retrospectively wise) your estimate will be better.

    Problem solving? The same. If you were in similar situation before you are retrospectively wiser and choose statistically better solution (same if it worked before, different it didn't).

    The role of any process of technique is, or should be, to gather knowledge of many people and give you a guide which helps you to choose right paths whenever you have to make a decision. The trick is probably no one was in exactly the same situation in exactly the same environment so you have to approximate. You choose which path promises, in your opinion, the best results.

    Now, the question: How? How do you choose the best option? How do you decide which techniques among these delivered by methodologies you consider as valuable (whichever they are) are the most appropriate in a specific situation?

  • Josh July 7, 2009, 5:23 am

    It's always like a tragic comedy.

    Why do people feel the need to "drink the Kool-aide" and trade in their brain for a "Manifesto" of some sort? Come on, is this a religion or cult of some sort?

    You run into this everywhere. I've had some conversations with Critical Chain PM proponents in that past that were very similar. It's all or nothing, black and white. "Either your with us, or against us!"

    Me? I use what works, adapt as lessons learned guide, and re-use as much as I can if it makes sense to do so. There are too many variables for me to submit to any particular method of project management.

    Josh Nankivel

  • Pawel Brodzinski July 8, 2009, 1:01 am


    That's exactly what seems like really reasonable approach to the problem. Learn, experiment, adapt. The funny thing is many PM methods (including vast majority of agile methodologies) incorporate this process. At least in theory. Why the practice looks that way oh so often then?

Leave a Comment