If so, do they ever interject and tell you not to work on something? I see stand-ups as a way to communicate information out to the rest of my team horizontally, but my manager seems to see stand-up as a time to micromanage.
Yes they do. They chime in with the business requirements and explains the tickets they created from a business perspective. They also asks for rough estimates and we have a chance to actually shoot down stupid shit.
They leans on us 100% for technical information.
I would hate they not being there as the information flow would be very bad without and priorizing stuff would eat up other half hours of the day.
We do Kanban rather Scrum, but we walk the Kanban board each morning which has a similar purpose to Scrum stand-up. Our manager is there, but because the board shows all the tasks the team has got that need working on, some of their tasks will be included (e.g. those that affect projects or the team as whole, not those that are direct line-management related). This helps them to know what the team is working on and also helps the team know what's happening that might affect them.
We're lucky that they don't have a micromanagement tendency, which means that when they say not to work on something it's usually backed up with a valid reason.
The manager should sign off on tickets in the sprint review to make a scope for the sprint. They can specify priority on the tickets to infer an order of execution, but, all things considered, and providing tickets aren't interlinked and blocking, if the sprint scope has been realistically allocated and not overstuffed then you should be able to do your work as you please by the sprint end in any order.
If the manager is changing sprint scope in scrums/daily stand-ups then they're being naughty. If they're policing order of execution, then maybe it's ok, but they should do that at planning time.
One of your managers primary jobs is to handle inter-team priorities and protect your team from external requests so that they can market you and your team's accomplishments for more resources (money for your promotion and head count to justify promotions to lead positions).
Managing timeline failures, particularly externally, and motivating other teams to unblock you is a primary management function.
Managers going to stand up doesn't seem like an anti-pattern to me.
Yes. He pretends to work on tickets in a sprint to justify attending. I think he's in a power struggle with the PM as we don't really need a PM with the work load we have, he could do his job.
And the PM loves to jump in to dev conversations that he doesn't understand on Teams too.
Yeah they attend the standup. No they don't tend to tell me not to do something, they just say what they're working on and talk to everyone about their current projects too.
Well, depends. If you do any kind of application which
1. Needs more than one programmer
2. The domain of the program is not the expertise of the programmers
Then you need someone to talk with the domain experts. Ideally someone who can communicate well, get information and handle the upcoming problems which arises whenever different domain expertises meet.
This role is called a manager, sometimes product manager. Sometimes the application is so large one person is not enough. Sometime a corporation is so disfunctional there are more managers talking than programmers doing the actual work.
But in its essence it is not a useful but an essential part of building something for other people.
They leans on us 100% for technical information.
I would hate they not being there as the information flow would be very bad without and priorizing stuff would eat up other half hours of the day.