[tjradcliffe]

There's nothing particularly long-winded (it's only a thousand words or so!) or self-contradictory about this. Good communication, clear setting of scope and expectations, good communication, team buy-in, and good communication are key elements of the PM's job.

I also liked the low-key tone. In contrast, anything that calls itself a "manifesto" is apt to sound a little arrogant and abrasive out of the box.

That said, I have to admit that anything associated with the word "gantt" puts my back up, as Gantt Charts are almost never an appropriate tool for project management: they were developed to plan the invasion of Europe, and on that scale they are necessary and useful. For typical software projects they are like swatting a bug with a nuclear weapon.

So even while being ill-disposed toward the author from the outset, I found myself agreeing with the thrust of the article.

[copsarebastards]

> There's nothing particularly long-winded (it's only a thousand words or so!)

Using a thousand words to say 200 words of content makes it long-winded.

> I also liked the low-key tone. In contrast, anything that calls itself a "manifesto" is apt to sound a little arrogant and abrasive out of the box.

That's an entirely pointless and off-topic criticism. You're only holding yourself back if you refuse to learn from anyone who doesn't make you feel warm and fuzzy.

Every one of the original signatories of the agile manifesto are well-respected coders who have produced major successful pieces of software. Arrogance is unearned confidence and I don't think you can reasonably accuse them of not earning their confidence. If you're judging them as arrogant based on the word "manifesto", that sounds a lot like anti-intellectualism.

[jbergens]

> Creating realistic project plans, estimating time and effort, rocking a spreadsheet your own way... those are all things you MUST do as a good project manager, and those skills are easily learned.

I don't think a PM should do much estimating. It is the team that should estimate the effort when given goals.

>SET EXPECTATIONS AND NEVER ABANDON THEM

This somewhat contradicts the agile way. Yes, I do think that expectations should be discussed and set but I don't think you can promise to never change them. People can change their minds, communication may have been missunderstood, technical difficulties may be larger than the team first thought, etc. I think you need to be able to change scope and/or expectations in a project.

[copsarebastards]

The second part of what you're saying is:

"Responding to change over following a plan."