> Specifically, if you have a team that doesn't communicate effectively on a daily basis, then the standup gives you -- the manager -- a place where you can get and keep your developers on the same page.
The standup should not include the manager as a participant; that's broken. The standup is supposed to be for coordination among the team, not status reporting to the manager.
Most of the time, the manager is partly responsible for solving the "blocked" and "things needed to do this task" issues that come up so it's better to have them there then not. If the whole point of a stand-up is to have all the team members forced into a quick acknowledgement, leaving someone out doesn't seem to help.
I think it's actually the opposite: everybody is invited to the daily standup, even the janitor if she/he so pleases... but only developers can talk.
I sell the daily standup to the developers as a tradeoff: we do a quick daily meeting in exchange for keeping stakeholders off your backs the rest of the day/iteration.
> I think it's actually the opposite: everybody is invited to the daily standup, even the janitor if she/he so pleases... but only developers can talk.
You're right; a better phrasing would be that the manager is not an active participant in the meeting. It's a developer coordination meeting, not a status reporting meeting. So the manager is welcome to listen in, but they're not supposed to be managing during that meeting, and in particular they should not be asking questions, because that'll very quickly turn the standup into a daily status report instead.
Has anybody tried to replace this with a "daily shared morning tea/coffee"? Create a collegial atmosphere that's intrinsically unsuited to active management; there's no real need to keep people ontopic anyways because they'll naturally talk about work. Plus drinks may keep people occupied enough that only one person would naturally talk.
I actually like to run standups as "all business": everybody says their piece and goes back to work as quickly as possible.
One of the main goals of Agile processes is to remove overhead from the developer so they can focus on adding value to the stakeholder. Anybody who starts goofing around the standup is disrespecting and wasting the team's time.
Now, your idea might be worth a try. As I said in another post: the team runs itself and might decide to try something like you propose... and keep doing it if it works for them.
I find I have a natural tendency to talk about non-work things because I feel guilty about not being more social. If we did that in my team I'd probably spend 20 minutes talking about netrunner with the other player and not actually mention any of my blockers.
But by all means try it out; if it works for your team, great!
That's good to be aware of. And your self-modulation helps the team. But don't let that be an excuse for not sharing what you learned yesterday that you think the team needs to know.
Technical teams often have a team lead, who can be the line manager for the developers. This person is part of the team, and can help identify problems and fix them. I think this works better than managers who are not involved in the daily work of developers.
I'm the team lead for my team and that's more or less what I do. A lot of the developers on my team are juniors and haven't developed the sense of knowing when there has to be an obviously easier way to do something and ask someone or search for it. Standup helps me to see who's stuck or where I can help them with an issue that could be done more efficiently from my own trial/error and experience.
Overall, I do as much coding/development as anyone else on the team. However, I also identify problems that others on team may not see until they become serious. I also look for ways to make the team more efficient through automation of the more tedious/repetitive aspects of the development process and implement a solution when I have downtime.
For example, we have a lot of network/hardware integrations we support and each one requires reconfiguring a database and reloading a couple services. This reconfiguring was being done manually much of the time through the web interface so I tracked down the rows being changed in the db by doing db diffs on each configuration and scripting out the changes that might be different on each developer's machine. Instead of manual config, developers just put a few custom constants in a json file, run the script and select the configuration they want to load from a script. That then updates the test db and they can be running/debugging their code in less than a minute instead of up to 10-15 at times (plus time lost from losing focus/train of thought). I know my example is nothing amazing really, but with some developers having to test a couple configurations a day, that time adds up without realizing it. The db schema rarely changes nowadays (maybe once a major version), but if it does, I just have to add a column perhaps at the most to the script and have them run it again after they update their build.
The standup should not include the manager as a participant; that's broken. The standup is supposed to be for coordination among the team, not status reporting to the manager.