First of all, it was written in a not boring tone, and it also conveyed at least one point that gave me an "AHA" namely "you are just the PM".
The impression I am left with is that this is first of all written by someone who knows what they are doing, that are also capable of writing in such a way that grasps the attention of their audience (me).
I am going to read all the chapters, I am sure there are nuggets in there.
Thanks for sharing.
This article does get it more right than most.
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.
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.
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.
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.
"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.
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.
And just because a lot of us would rather not spend half the day emailing C-level folks in our organization does not mean that it's not important.
