[copsarebastards]

A lot of this is just long-winded and self-contradictory. It's not all wrong, but I'd simplify it down to the agile manifesto. [1] If you understand and internalize the actual principles of the agile manifesto, everything useful in this article becomes clear.

This article does get it more right than most.

[1] http://agilemanifesto.org/

[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."

[slavik81]

As much as I appreciate the agile manifesto, your suggestion seems a little like teaching the fundamental axioms of mathematics and leaving it at that. Yes, those principles are useful, but it's a lot easier to reach practical conclusions with more specific guidance.

[copsarebastards]

Yes, but this is establishing a whole new set of principles ("Communicate like a pro", "Be a chameleon", etc.) without coalescing them down in any way. It's one thing to talk about a principle and then give specifics examples of how to apply the principle, but this hasn't bothered to coalesc coherent principles.

To steal your analogy, this is like stating principles: "When a triangle has a multiple of 3 length and a multiple of 4 length next to a right angle, the remaining side is a multiple of 5." "When the hypotenuse is a multiple of 13 and a side near the right triangle is the same multiple of 5, the remaining side is the same multiple of 12." People get lost in a bunch of random examples when all you really need to solve for the sides of right triangles is the Pythagorean theorem. A few examples help, but if you don't relate them back to coherent principles they're pointless.

[EliRivers]

But a good PM has to be able to manage projects using more than one methodology. Agile (or at least, agile as it is commonly practised, because I just know that someone is itching to say "No, the reason that's not working is because you're doing agile wrong") is inappropriate for many projects.

[copsarebastards]

Starting your post with "But" makes it seem like you're disagreeing with what I said.

"Agile as it is practiced" is not what I was talking about and has very little relation to the agile manifesto. The agile manifesto isn't a methodology, it's a philosophy. I would go so far as to say that "Agile process" and "Agile methodology" are oxymorons if you're using "agile" in the "agile manifesto" sense.

Everything you said in your post is a direct consequence of prioritizing individuals and interactions over processes and procedures: the first statement of the agile manifesto.

I realize I am being one of those "you're doing agile wrong" people, but only because I feel that it's worth rescuing "agile" from "Agile" because otherwise we're just rediscovering the same principles under a different name. I would rather fight to remove the pollution of "Agile methodologies" from the actual meaning of the agile manifesto than reinvent the wheel, and run into the same issues where people coopt the principles and pretend they support whatever flavor-of-the-week methodology they are espousing.

[ska]

This is important. The idea that some sort of methodological silver bullet exists that will solve your projects problems "for you" is as pervasive as it is naive.

A big part of a good PM's role is knowing what approach is appropriate for which project(s) and knowing how to implement it practically with the team(s) they have.

[copsarebastards]

You've just described "individuals and interactions over processes and procedures".

The agile manifesto isn't the cluster fuck that Agile has become. Agile methodologies directly violate the agile philosophy, but that's no reason to pretend that we're just now discovering that methodologies suck. It's in the manifesto.

[munchbunny]

The difficult part of being a good PM in a team is that Agile is hard to do right with real humans. Even if it can be reduced to the Agile Manifesto, putting it in practice is difficult and takes work, time, and skill. The ability to consistently create good practices are what differentiates the good from bad PMs.

So while I agree with you that it does reduce to the Agile Manifesto, I'd also say that from a PM's perspective, that's not the point.

[ska]

What I've described are ideas that predate the agile manifesto, and are not subsumed by it.

[copsarebastards]

Of course the agile manifesto didn't arise ex-nihilo. But it's a much clearer, more concise statement of what you said.