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 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.
EDIT: phrasing
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.
Absolutely no experience, so this may be stupid.
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.
[edit] Oh, is that what the watercooler does!
But by all means try it out; if it works for your team, great!
It's a lot easier to be collegiate in a college.
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 prefer to have wash up meetings at the end of the day so you do not waste time in the morning hanging about for people to turn up
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.