3 ms·
1. Refusal to accept that task estimates are subject to change. 2. Managing people purely for their outputs; not as individuals with lives, career goals, inter
by andyjohnson0 7y ago
1. Refusal to accept that task estimates are subject to change.
2. Managing people purely for their outputs; not as individuals with lives, career goals, interests, strengths, weaknesses.
3. Insisting on process but not participating. E.g. scrums with no management present.
- ravenstine 7y agoIt depends on how you define management. PMs should probably be present during sprint planning for Scrum, but any level of management above PM really shouldn't be there. I worked at this one place where, as much as I dislike Scrum, we had a pretty good pace going without upper management ever getting involved. Then the manager of our department(not an engineering manager) decided to show up to all our meetings because, shit, why not, and it completely cramped our style. They also began to dictate that we do things in a specific way even though our productivity was fine before. Fortunately, like most non-engineers, they lost interest after a month and almost never showed up again. Granted, I have found at most of my jobs that management is absent when it usually counts. At one place we had a "demo day" as part of our Scrum process, but relevant parties in management almost never showed up. They would even claim they would show up but always came up with an excuse at the last minute. It wrecked everyone's confidence in them because a manager can't claim to say things like "product is key" and then fail to show up to product demos every single time. Yet demo was something our management wanted us to have.
- Ididntdothis 7y agoYour last paragraph is important. At a minimum management needs to understand scrum and play their part.
- Ididntdothis 7y ago”Insisting on process but not participating. E.g. scrums with no management present.” That’s pretty common. Retrospectives are also only for devs, not for management.