A place where I worked got off the rails when standups were used to allow two people to work through a problem while the rest of us sit there patiently. They grew to be 45 minutes long each day.

People brought chairs. To a standup!

That sounds like an opportunity to very politely explain the phrase "take it offline" to everyone. It would be awkward, but probably less awkward than standing there patiently doing nothing for half an hour.

This is where the Scrum Master should step in and move the conversation along.

Agreed. PMs (product or project) should rarely speak during standups; instead, they should be listening for blockers and other action items for them.

I've worked in environments where the PMs micromanage like this. It's both hellish and extremely inefficient.

It's almost like... gasp management always used agile to implement micromanagement all along.

I logged in just to make this same comment but you beat me to it. Agile is micromanagement in disguise, and we fell for it hook, line, and sinker.

To be fair, we were already micromanaged. Then Agile was posited as a solution, so of course we were enthusiastic. Unfortunately the only thing that appeared to change was the name.

So we’re not really any worse off than before.

Are you sure you haven’t just always been micromanaged and this is another way for that to happen? All things can be abused for bad purposes.

I haven’t heard too many examples of “oh man we used to be free and ship great features on time but now that we have a backlog and talk to each other every day it’s a hellscape death march”

I've done my stint in "large enterprise". It's a whole new world there where management believe that if projects aren't on track, then the solution is more meetings, more agile training and in-house "coaches", and even more micromanaging. I'm no longer in that world, and I'll never go back.

As someone that has also worked for large enterprises as well as government, I’d say that using agile can be another way to micromanage, but it can also be used in a way that improves product quality and impact while helping developers.

Generally, I’ve found that the level to which agile approaches make life better depends on how much management is actually willing to let the team do its work and stay empowered. This can happen with trust and top cover in large enterprises, but it takes constant work at the PO / product manager level otherwise regression to the mean takes over. Also hard to avoid the inertia of making successful teams bigger rather than letting them continue small.

I wonder how the Amazons / Facebooks of the world avoid the trap, but then their enabling teams are likely a big percentage of their workforce because they understand how important software is to their business.

By top cover, do you mean managers shielding lower level employees? That was my experience at a mid-size finance firm, it was only possible for my team do to decent work because my team lead was fairly competent at keeping the higher-ups up at bay.

The best managers I've worked for have understood that one of their key roles is to be shit-umbrellas.

Precisely.

I stopped going to my team's standups because of this. For a few weeks I was occasionally asked about what I was doing, I just always said I was busy on whatever I was working on. Now I'm the only member of my team who never joins the standups. I wonder if they resent me for that, but it's not worth going back.

Probably they resent you. What feels like a good solution is discussing this in the retrospective or have an informal discussion about this. Then again, team members need to be open to discussing this and viewing it from another angle.

Also, by discussing the issue you might discover others feel the same way and are open to changing the process.

If this were the case then standups would be totally useless unless the org was so cooked that nothing gets done unless someone is made accountable in front of the entire team.

If I run into a blocker why would I wait until the next morning to try and get it resolved?

Usually the idea is you move onto another task since you have multiple allocated at one time, then ask briefly for guidance during the standup when everyone has put time aside, rather than interrupting everyone throughout the day.

Blockers are not just people and usually it's not done for accountability. They can be undocumented APIs, an unfamiliar requirement ("do we already have a way to extract images from PDFs before I download this new thing?"), etc.

If it is urgent and your only option is to sit there and do nothing then asking the team for help during the day is fine. Just weigh up the cost of interrupting everyone (or that high-performer who has all the answers) against what you gain.

> If it is urgent and your only option is to sit there and do nothing then asking the team for help during the day is fine.

Sit there and do nothing for awhile just may be the right thing to do!

I'm thinking about the Theory of Constraints and optimizing a system versus individual parts. This is a concept you would want your PM to know. So when they are mentally mapping the workflow heard during standups, they can be thinking about optimizing the entire production system.

Next step is the importance of communicating this to everyone on the team, so that they understand that there may be times when the right thing to do is nothing.

"Hey, I spent all yesterday trying to get X to work but I think I'm stuck"

"Hey I was trying to use Mary's api but I couldn't figure it out, can someone help me find who to contact?"

If you ask immediately for help all the time you aren't being self sufficient. At the same time if you are spinning your wheels then just a second pair of eyes can be helpful.

I had a new manager start his first weekly meeting by asking if there was anything on fire. People filled the ensuing silence with recent annoyances. Of course nothing is on fire right now (and I get it’s a metaphor). If something is “on fire”, I’m not waiting till the Monday meeting to bring it up. I’m not even going to attend the mandatory meeting while I put it out, if that’s when it happens. That’s the definition of on fire.

To be fair, your new manager doesn't know that's how you operate. It seems a reasonable question to me, with the expected answer being no. But why not ask just in case? You wouldn't want to be the new manager who just launches into new business not realizing that one of your developers is too timid to interrupt you with the major breaking bug that's currently live, or whatever. Once they get to know the team and can trust that you'd be on top of that kind of thing, it's another story.

Maybe I’m too sensitive to the phrase “on fire”. I can’t imagine someone at a factory starting a meeting the same way.

He was perhaps trying to get a feel for the team?