4 ms·

It's worse than "assembly line worker." For that, a hyper-specific set of actions is created, and then commoditized workers are inserted into this rigid process

It's worse than "assembly line worker." For that, a hyper-specific set of actions is created, and then commoditized workers are inserted into this rigid process. The spec/actions rarely change over time. In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someone is analyzing those actions for "blockers." A "blocker" is either a case where the manager didn't communicate effectively and/or didn't set effective scope/milestones, or else it's a code word for "you're doing it wrong" and gives the manager a change to micro-manage the specific actions the worker is taking day-to-day. In any case, I firmly agree with you that the core message is "I don't fucking trust you even an inch." If you want to see a bad engineering manager's brain misfire on cue (if they are of this micro-manager type), ask them why the product manager or designer on your team isn't expected to time-box and pre-estimate his/her spec. writing tasks.

fiachamp 8y ago
In orgs I've been in the daily standup was clearly intended to help people get a heads up on who can help them with blockers or may be working on a similar part of the codebase that day. It also helps PMs know what kind of support they'll need to give their dev team that day since they often get pulled into meetings by other parts of the company. As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.

fiachamp 8y ago

In orgs I've been in the daily standup was clearly intended to help people get a heads up on who can help them with blockers or may be working on a similar part of the codebase that day. It also helps PMs know what kind of support they'll need to give their dev team that day since they often get pulled into meetings by other parts of the company. As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.