Thanks for a comment. I don’t say your classes aren’t worthy. I just point that having skeptic PMs as an audience makes classes probably useless for them as they’re to scared to use the knowledge. When you ask a skeptic what will and what won’t work in his case, he’ll come with a lot of reasons why it don’t even have chance to work in his case (yet he’ll probably admit the method is good for others).

Having said that, I like your approach to try to avoid any bias. Although you won’t bring many Agile Believers that way, it’s fair.

And when talking about “take-it-or-leave-it” standpoint you can use it against any methodology. As far as you are conscious what you resign from and which consequences you agree to face it’s OK. Of course you have to know the whole methodology very well and most likely has experience in using it as a whole. Process-oriented methods are no different here – I guess there are their mutations which do exactly the same thing – cut off a couple of things which didn’t work in specific (author’s) environment.

Thank you for your comments. Like you, I resist dogmatic and evangelical approaches to PM and IT architecture – preferring to use what works in a given situation and casting aside what doesn’t.

The goal of a course like the one I described is to present the facts and methods and leave it up to the student what will or won’t work for them. That’s a primary reason I get the questions that I do in a class like this, and try to give the best answers I can.

I also point out what can happen when certain things are left out of any particular method approach as I detailed in the post. What I say to the students is: by all means, leave [XXX] out of your approach if you feel the need, just be aware of what can happen if you do, and be prepared for the outcome of that decision, positive or negative.

I will take issue with your comment that Agile methods are no different from a take-it-or-leave-it standpoint as opposed to traditional process-oriented methods. If iterations are very short, say a couple of weeks, there’s not a lot one can leave out without compromising the iteration and perhaps the project because the delivery tempo is very high when compared to other methods. Also, if people start out with a method roadmap and follow it completely once or twice, they then learn how it fits in their work and organizations as opposed to second-guessing the whole thing right from the start – which lengthens the leaning curve and can lead to sub-optimal results.

Regards,
Bob McIlree