The Good Project Manager
teamgantt.com
The Good Project Manager
1–10 of 26 posts
Re: The Good Project Manager
#2A 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.
Re: The Good Project Manager
#3A 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/
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.
Re: The Good Project Manager
#4A 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/
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.
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.
Re: The Good Project Manager
#5I liked this write up on the overalls of being a project manager very much.
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.
Re: The Good Project Manager
#6A 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/
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.
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.
Re: The Good Project Manager
#7Earlier quoted context omitted.
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.
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.
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.
Re: The Good Project Manager
#8A 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/
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.
Re: The Good Project Manager
#9Not sure if submitter is the author but I think "queues" should be "cues" in the second sentence of the Be A Chameleon paragraph.
Re: The Good Project Manager
#10A 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/
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.