You are correct, context is very important. That is why I said to assume my starting point solution was wrong – regardless of your context.

I am certainly discussing software development. I am not prescribing how to do a project or “how much” Agile vs. PMBOK should be used by the team. It should be decided by the organization and the project/product team on a situation specific basis.

Personally, I believe that a multi-year, 10k person, weapons defense system would depend much more on a formal application of the knowledge areas in the PMBOK with more planning then a 5 person website would.

However, even on the 10k person project, we could draw from the Agile principles and on the 5 person website we could draw from the PMBOK when deciding the most responsible way to run the project.

My post is based on the out-of-hand rejection of the PMBOK that I have experienced in discussions with some members of the Agile community (of which I are one).

Dennis Stevens

There is no context…how can we have this discussion outside a particular context? You have an assumed context of “product”, but don’t mention the type of product. Would this be different in the context of a non-critical IT system built by a small, co-located team vs. the context of multi-year, 10k person, weapons defense system?

– Hank

This is an excellent point. I agree that the “clash in the type of language” puts up barriers. But shortcut naming isn’t just to create divides – it conveys a tremendous amount of context and subtle meaning.

Agile and PMBOK practitioners come from very different backgrounds. They have historically been solving different problems. The challenge is that, as we move Agile into larger teams and the problems become messier, we have to draw from both of their backgrounds.

In his conversation theory, Gordon Pask says the way we hold the other participants in the conversation, and therefore the private conversations we have about them as they as participating in the conversation, has a tremendous influence on how we understand them.

We have to start by accepting the mindsets as different and recognizing the resulting language as a potential barrier. Then we have to learn to translate and/or look beyond (maybe underneath) the clashing meaning and evolve a more robust understanding.

Dennis Stevens

Thank you for the comment. As a manager and coach helping teams deliver software I have gained value from the PMBOK. I believe there is value in sharing our experiences and hope, as a community, we can get get to the point where we are looking at other bodies of knowledge to see how they can add to our world view – rather than fearing they may threaten our world view and looking for ways to dispute them.

Dennis Stevens