4 ms·

How can you be so sure all your colleagues are useless? Are they doing any important but non-flashy work (planning, documentation, cleanup, etc) that isn't capt

How can you be so sure all your colleagues are useless? Are they doing any important but non-flashy work (planning, documentation, cleanup, etc) that isn't captured by the "story point" metric, which is a pretty bad tool to gauge productivity anyway?

icedchai 3y ago
Keep in mind all of that important but non-flashy work can also be used as a cover for not doing anything of consequence. Yes, sometimes it is important, but 70% of the time when I see someone has been "planning" they've done absolutely jack... (Recent example: How can a PM plan a software engineering project without talking to the people actually doing the work? Then they wonder why the "plan" makes no sense...)
- tengwar2 3y ago
  As a PM, I find it best to put together a straw man project plan before I talk with people, then revise it progressively as I talk with people. Not always, but it's often a good idea, particularly if the project crosses multiple departments or companies. Sometimes I can't get everyone in the room at the same time. Sometimes (often) people will see their own team's area of work as being the main focus, while I have to coordinate with other groups, while trying to minimise the "hurry up and slow down". Sometimes there is a need to get people started on the bits we know about and accept that other bits will need changing. And sometimes you need to get the person responsible to estimate the length of the piece of string, and putting up a wrong estimate is a good way to get an answer. I'm sure everyone is thinking "agile" now. Yes, I was in to that back when XP was the thing. But it only works for some sorts of project, typically where there is only a single company developing a project, and the customer is internal. If you have a big contract with specific deliverables, a contractual time line, multiple organisations, and perhaps large non-sw parts, you often find that you have to start planning even before the developers are engaged, then accept that some of your assumptions will be wrong.
that_guy_iain 3y ago
Realistically shouldn't those tasks be given story points too if they're done separaterly from the team?
- petterparker 3y ago
  I'm not sure why you're getting downvoted. At least when I was working for a contractor in the automotive industry, these kind of tasks where measured in story-points as well since story points roughly translate into paychecks.
Fire-Dragon-DoL 3y ago
I hear your point but I wouldn't dismiss the op point, those situations do happen. In this case the problem could be just miscommunication, it's worth asking some help from the team

icedchai 3y ago

Keep in mind all of that important but non-flashy work can also be used as a cover for not doing anything of consequence. Yes, sometimes it is important, but 70% of the time when I see someone has been "planning" they've done absolutely jack... (Recent example: How can a PM plan a software engineering project without talking to the people actually doing the work? Then they wonder why the "plan" makes no sense...)

tengwar2 3y ago
As a PM, I find it best to put together a straw man project plan before I talk with people, then revise it progressively as I talk with people. Not always, but it's often a good idea, particularly if the project crosses multiple departments or companies. Sometimes I can't get everyone in the room at the same time. Sometimes (often) people will see their own team's area of work as being the main focus, while I have to coordinate with other groups, while trying to minimise the "hurry up and slow down". Sometimes there is a need to get people started on the bits we know about and accept that other bits will need changing. And sometimes you need to get the person responsible to estimate the length of the piece of string, and putting up a wrong estimate is a good way to get an answer. I'm sure everyone is thinking "agile" now. Yes, I was in to that back when XP was the thing. But it only works for some sorts of project, typically where there is only a single company developing a project, and the customer is internal. If you have a big contract with specific deliverables, a contractual time line, multiple organisations, and perhaps large non-sw parts, you often find that you have to start planning even before the developers are engaged, then accept that some of your assumptions will be wrong.

that_guy_iain 3y ago

Realistically shouldn't those tasks be given story points too if they're done separaterly from the team?

petterparker 3y ago
I'm not sure why you're getting downvoted. At least when I was working for a contractor in the automotive industry, these kind of tasks where measured in story-points as well since story points roughly translate into paychecks.

Fire-Dragon-DoL 3y ago

I hear your point but I wouldn't dismiss the op point, those situations do happen. In this case the problem could be just miscommunication, it's worth asking some help from the team