As a manager, the most important thing to remember about the meetings you schedule is that they are for your benefit. If you are the type of person who needs to know what is going on every minute, you will hold a meeting every minute. When developers need to know what is going on they simply turn around and ask, exactly as often as necessary. 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.
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.
And everybody is going to have strengths and weaknesses. As a great manager, it's up to you to play to each person strengths. The other two employees may be scatter-brained, so perhaps task them with very specific goals that aren't as time critical as the other ones. The term Rock Star Programmer, is so fucking overused, overhyped and just plain stupid and I wish that it never entered into our vernacular.
It's also your job to realize realistically, where your employees have weaknesses (trust me everyone does). A great manager will help bolster areas that people are weak in, in a way that doesn't demean them.
Management ain't easy.
In this case, I suggest the OP read up on the situational leadership framework [1] (Wikipedia is a good start but I suggest you pick up a book since they explain it far better). It is designed for the exact problem OP is encountering: what to do when you have people with different levels of expertise at a task. In a nutshell, it's about helping your subordinates manage the experience curve by recognizing where they are and providing the right kind of encouragement at the right time.
[1] http://en.wikipedia.org/wiki/Situational_leadership_theory
While some managers want to stay away from so called micro-managing at all costs (either because they are afriad that their employees won't like it or becuase they are lazy) it has to be said very clearly: There are certain situations when so called micro-management (very precisely set goals with clear metrics, large amount of detailed instructions, frequent controlling and immediate corrections) is absolutely necessary to push someone's growth forward. Of course such management style isn't scalable and ultimately must be changed when the employee's competences grow. It's just an investment into future performance.
Of course as in case of every investement you need to evaleate if it makes sense. Assuming that the employee has only one particular area that needs to be improved, the answer usually will be "yes".
Unfortunately, standups, like so much of "agile", are a perfect disguise for wolves in sheep's clothing.
I've been incredibly burned by agile, and I realized it's because agile encourages a developer to let down his or her guard at the wrong moment.
Going through the agile manifesto, I can now see how each one of these has gone wrong for me.
"Individuals and interactions over processes and tools". Right, we all get together, discuss what we're working on. It feels very collaborative. But there will be this tool, this time-tracking system, that we'll enter stuff into, and your name will be next to those things with a deadline. If you don't meet it, we'll interact with you as an individual about why you aren't meeting your deadlines.
"Working software over comprehensive documentation". Again, sounds great. Rather than spec'ing out every little detail, let's work together iteratively to get the right product out. Here's the thing - you just allowed the people who are putting your name next to a task and a deadline to never commit to exactly what they're trying to build and by when. The deadlines are yours, but they'll enjoy changing their minds, because, you know, "agile."
"Customer collaboration over contract negotiation". The trap has been set, this is where it is sprung. Most developers, I'll guess, aren't truly in contract situations where there are lawyers and signatures and so forth. The tend to work on internal projects. But make no doubt - if someone can turn to you and say "you committed to getting X done by date Y", and it's in there in the system, you are in a contract situation. But because it was "agile", you didn't negotiate properly, and now you'll get rolled.
"Responding to change over following a plan". I assure you they will hold your feet to the fire if you don't follow the plain that was clearly in the "contract" and documented in the progress tracker system. However, because it was "agile", you never really got them to commit to what they were asking of you, so they retain the ability to change and adapt. If it suits their purpose, so can you, if not, you're "in breach". If it's internal, this isn't some lawsuit, it tends to be a sit down with people, including your manager (and perhaps a few other managers), where people act like they're all here to solve a problem and get things back on track, with a heavy undercurrent that it's your fault.
Standups, while not part of the manifesto, corrupt similarly. Instead of "here's what I worked on yesterday, here's how it went, here's what I'll work on today", they become a daily application of pressure and reminder of deadlines. It appeals immensely to someone who would like micromanage a developer. They're meant to keep communication open in complicated projects where it can be difficult to make estimates under uncertainty (you know, a software project). But they often end up with one person trying to explain complexity to an exasperated (and perhaps manipulative) person who really just wants to apply (often artificial) deadline pressure.
Unfortunately, "agile", for all its promise, turned out to be amazingly fertile ground for manipulators. I think this, more than anything else, is what has so badly damaged "agile."
Waterfall seems like a discredited old system, and I don't love it either, but it has a huge advantage for developers. It requires people who will insist on and enforce deadlines to state upfront, in considerable detail, exactly what they want.
Except it never really worked that way, which was the entire problem with waterfall. Waterfall works best in a static environment with guaranteed funding because it doesn't react well to shifting priorities. In reality, requirements change and budgets get cut, which sets off a chain reaction of change management activity in a waterfall model. Agile is so much better -- you reassess requirement priorities every few weeks and that dictates what you work on over the next few weeks. In very few situations under which software is developed today is it even possible to state upfront what you need with any certainty. Waterfall assumes that requirements gathering and development take place serially, whereas agile recognizes the reality that they are more or less concurrent.
Waterfall still has its place - if I were developing a nuclear reactor or an airplane, waterfall is still the way to go. But for projects where 100% requirements completeness is unnecessary (and let's be real, nobody runs a full regression suite after every sprint), Agile will get you a better product faster and cheaper. Everything you said is true -- agile is a fertile ground for manipulators, but so was waterfall.
The manipulation is a byproduct of any reasonably large organizational structure, and if you want to stop it, it's got to be a cultural thing. Bad actors will exist under any development methodology, it's up to the leader of the engineering organization to stand up and refuse to allow his/her people to be abused.
It's a two way street though: the business folks need to understand that they're giving up some control and predictability in exchange for lower overhead and faster delivery. This is the hardest part of Agile IMO since most business / product folks don't like not being in control. Agile gives engineering more autonomy, but only if the business respects that autonomy. If the business starts dictating too many processes/priorities, the whole thing crumbles into a waterfall mess (even if you call it "Agile").
From your description, it sounds like these programmers are not as efficient in their work, or as task/goal-oriented as you'd like them to be, but not that they're completely incapable. Sometimes you will find programmers who can't program; they're hopeless, you have to fire them. But otherwise good programmers can be awful at managing themselves... and you're the manager, after all, so it's your problem to solve. Of course, you don't want to micro-manage them every hour of the day; that's not scalable.
Not every aspect of Extreme Programming is applicable to every situation. But a quick morning standup meeting can be a very effective tool. First, you will find out when people get off track and are having problems. Second, it creates some accountability to advance the ball every day. Third, while you must actively work to have the team cooperate instead of compete, it will naturally create some competitive and evolutionary pressure, where the more focused members of your team provide a good example and, over time, can share some of their secrets. Finally, the standup helps reinforce teamwork. If someone is having a hard time with a task, you can respond and say, "hey, you know, Bob's in a good place with what he's working on, why doesn't he help you out today, see whether a fresh perspective can help?"