It sounds like these engineers have tasks they think are important: I don't think anyone spends several days setting up a VM for fun. Does everyone have a say in what user stories are worked on? Do they have a mechanism to suggest improvements, and help prioritize them against the rest of the backlog to figure out what's most important?

Now we moved it to quarter to two, which for most of us means a bit after lunch. Now we have no interruption throughout the morning, and the hour before the standup we're not working anyway.

This sort of stuff tends to get imposed from above, or by busybodies enraptured with ideas and theory as opposed to practicality. I'm endlessly told how nothing but agile works, despite the fact that I'm 48, and successfully lead dozens of projects before agile was an idea, on time and on budget.

If I was to take a list of aglie practices, I maybe end up ticking half of them. Same things I did when waterfall was all the rage.

Identifying issues encountered (both to share knowledge of how issues were resolved and to gather information on addressing barriers that haven't been resolved) is a pretty standard element of standup meetings even when they include progress updates, and certainly a good thing to keep them for if you've moved the status updates to another channel.

One advice to the OP - dont think of yourself a "manager". I always think of myself a "lead"er - as in "lead by example". So, anything that i ask (and consequently expect from my team) is definitely something that I would also do given the same circumstances. Going by this, the standup (as an example) is where I am the first one to share what I did yesterday, something interesting that I found out about yesterday, and what I hope to accomplish today. I add any blockers that I came to yesterday couched in the "can someone please help with this problem?". Since I open up the "discussion", its not even considered an interrogation - its just sharing my accomplishments, interesting things, etc with my peers/team mates.

That's far from an interrogation

However I would argue that the problem isn't stand up itself, but a culture of not being able to say you didn't finish something. After I realized in my last company that it was okay to say I couldn't finish something in time, the environment quickly felt much nicer to be in.

So they implemented daily stand-up meetings at exactly 8:50 am, including every single person on the development team, as well as all the testers. The natural politicians on the team immediately pivoted towards writing down every bullshit thing they did during the day, so they could recite them the next morning as evidence of productivity. Incidence of scheduled meetings that would require at least one of the seniors to be present exploded.

Every single one of those damned meetings was scheduled for 10 minutes, and lasted at least 30.

The stand-up is not the problem. Incompetent management is the problem. Management fads won't do anything to address the underlying deficiencies. The actual problem with that office is that smart and unethical developers are leading the incompetent managers around by the nose, using the very process and metrics that the managers had created to hide their lack of development knowledge.

As a result, the senior developers assigned themselves the privileged tasks that sound important but don't actually require much work, assigned the grunt labor to juniors, and gamed every last one of the management metrics to make sure everyone on board with "the program" gets paid until the gravy train runs off the cliff.

So naturally, every last line of that code base is DailyWTF candidate material. The management does not understand technical debt, so the seniors issued them high-interest loans from their own bank.

This is not the fault of the developers. It is 100% the fault of the managers that allowed that toxic creature to take root.

So with respect to the question post, I suggest that the "slow" employees may actually be testing their new manager's capability to manage them. This is particularly relevant if any of them have ever worked for another company.

Assume they are trying to establish their own slack margin, so that they can safely read HN every morning, or some other equivalent time-waster, without falling behind on assigned tasks. If so, implementing a daily stand-up will only confirm that you are a management novice that can be manipulated.

Just establish a tough, but fair, work standard, and check to see if the "slow" guys speed up in response, or continue to struggle for more hours. For the former, you will need to court their favor by assuring them that good productivity will not be punished. For the latter, you will need to continue their education by sharing the knowledge and experience you and the faster developers have acquired during your careers--but subtly, so as to not embarrass them before their peers.

While it's far from the worst thing to drive developers away, I do agree a standup/scrum meeting every day is stupid, counterproductive, and just plain useless.

For the managers, they should be able to look at your ticketing/project system and know instantly what everyone is working on. Keeping tickets up to date is part of the job and really, it's not that hard.

For the programmers, they are now tasked with figuring out what to say in the standup and how to make sure that they are not perceived as not working when they really are. Programmers who need to know what other people are working on in the team can also look at the ticketing/project system and when they need more information (as in cases where their work depends on someone else), they will ask directly.

I've been to standup meetings in close to a dozen different companies, ranging from the smallest startup to some of the biggest tech companies and never have I ever seen a standup meeting end on time. NEVER. I don't think it actually happens. What I have seen is the meeting go on for half an hour to an hour, boring everyone out of their minds. Sometimes this even involved multiple teams whose work barely intersected at all. The other team's work status was a pure waste of time for anyone not on that team.

Yes, it is absolutely an interrogation. A daily standup shows that the manager doesn't trust his employees. He doesn't trust them to keep the ticketing/project system updated. He doesn't trust them to do work without the threat of being shamed and/or seen as lazy if the work done doesn't sound impressive in a standup. He doesn't trust them to seek help on their own. Basically, a daily standup is the sign of an incompetent manager.

Scrum is for rugby.

I've never seen a huddle exceed 5 minutes. Ever. Even sit-down meetings, in large corps, rarely exceeded half an hour (Fortune 50 type companies).

I find the daily update hugely useful as a quick run-down into the changes in strategy happening, and as a chance to know the focus of what others are doing.

Perhaps I'm just lucky? Industry and location: Banking (UK); Finance and Technology (China).

In my personal experience, standups are practically useless if you have a team that has good communication practices. You know what people are working on from the ticket system, things are shared throughout the day as people work on chat, and if you do need some level of daily status report, having everyone email one in directly to the manager is the most efficient route.

If it acquires a have you done any work at all? vibe, you just fight it off with honesty. A half-hour standup is just insane. A large 'scrum of scrums' standup with dozens of people/teams shouldn't take longer than 15 minutes.

It's easy to sabotage standups in this manner by asking questions of others that you know will cause extended discussions. Especially on topics that have previously been "settled" by fiat.

A stand-up shouldn't take more than a couple of minutes per person, at the most. The thing that seems to help the most with this is to set aside a section of the whiteboard for the "Parking Lot". If the discussion starts getting off-topic or taking too long, the leader says "let's put this in the parking lot for now", makes a note of the topic on the whiteboard, and you move on to the next person. After the main part of the stand-up meeting is done, the Parking Lot is addressed, but only people who want to discuss it (or are needed for such discussion) need to stay.

In organizations, people will form suspicions, e.g. "does that guy actually pull his weight?" It's not a good thing. It's not what people should do. It's what they will do. Standups allay that suspicion. Of all the political games that an office environment can make you play, standup is one of the easiest ones, and that's good because even with the losses you mentioned (such as regaining focus) it's limited in the amount of time it takes, and you still have 50-65 percent of your time for real work, which is 3-4x what many programmers get.

One way managers could minimize disruption is to walk up and ask developers what is going on as often as necessary on a per developer basis.

Impromptu status pings are more disruptive (and, in some companies I've seen, obnoxiously frequent, like 1-4x per day) than scheduled status meetings. If you've decided that you need status updates, you should have the standup instead of having the whole office on edge all fucking day.