Straw Men and Red Herrings

Whenever I get into a discussion on Agile Project Management, I inevitably find myself contrasting Agile methods with "Traditional Project Management". I use the phrase "Traditional Project Management" as a label for that style of project management advocated by the PMI, documented in the PMBOK, and certified through the PMP. It's the kind of project management we often characterize as big up front planning followed by a blind adherence to the plan.

Setting up the conversation this way gives me an easy way to establish contrast and teach about Agile methods. The problem with this approach is that reality is never quite so simple.

A well run "Traditional" project does adapt and respond to its environment. A good "Traditional" Project Manager does lead and empower their teams. While good "Agile" teams are structured and disciplined, many are unstructured and chaotic. Establishing an us vs. them mentality isn't going to lead us any closer toward developing more adaptive project managers or more adaptive project management practices.

We will always be able to find examples of misapplied process no matter what management or leadership philosophy we happen to hold.

Rather than setting up the "Traditional" crowd to take the fall for all our project management problems, we should acknowledge that there is a time and place where it does make sense to apply a more "Traditional" approach. Let's focus on making the Project Management community aware of those domains where it doesn't. If we can clearly communicate what makes some software projects different, in a language the "Traditional" crowd understands, we will be better positioned to open minds.

Agile is pretty risky for people that have been immersed in 30-40 years of conventional project management wisdom. As Agile becomes more mainstream, we are going to need to deal with people that are not ready to drink the Kool-Aid. If we want the PMOs out there to see Agile as a viable project management approach, we need to meet people where they are and guide them gently into this new way of thinking.

So here is my new formula for having a discussion on agile project management

1. Validate the traditional project management processes
2. Explain why these processes break down in certain problem domain
3. Listen for objections and understand their point of view
4. Explain how agile project management solves some of these problems.

What do you think?