Many of my best stand ups go like
Mary: "Nothing to report."
Jon: "Nothing to report."
Dyneshwari: "Nothing to report."
Shruthi: "Nothing to report."
Su: "Nothing to report."
Grant: "Oh, we moved all the test databases. You need to get the latest base data in your environment or you won't be able to work."
Joe: "Nothing to report."
It's over in 1 minute.
Mary: I fixed the missing-messages bug, and I'm about to refactor the protocol to support faster logins.
Jon: We should talk afterwards, I'm also touching the protocol to edit the login screen.
Dyneshwari: I did an unrelated UI change that doesn't interfere with anyone.
Shruthi: I just started laying the groundwork for ads in the stream.
Manager: We should talk afterwards, legal has a bunch of new requirements on the format of ads.
Su: Nothing to report.
Grant: Oh, we moved all the test databases. You need to get the latest base data in your environment or you won't be able to work.
Joe: Jon, loop me in when you talk to Mary, I just had to change the protocol for UI widget X and I've got some tips for working with it.
Not quite 1 minute, but it could save several hours of work when Mary, Jon, and Joe coordinate and make sure they aren't stomping on each others' toes, and their little mini-meeting probably won't take more than 20 minutes.
And here you have your real problem.
You're applying an office-tool (the board) to a team that is not sharing an office.
What works much better for distributed teams is to treat them like OSS projects.
Do you know any OSS project that uses a "board", or stand up meetings?
They use the issue-tracker, pull-requests and chat instead.
I feel that the article is attacking a strawman, or perhaps it is a no true Scotsman where the objections are all or mostly about standups that aren't working rather than about the idea of a short "Let's just make sure we are all on the same page" session.
Blog I haven't seen tried, but I imagine it would hit the same problems; either you notify everyone and have the same problems as slack, or you don't and have a big risk of someone missing an update.
This has an amusing side effect: For some reason, even if I attend the stand-up after all, nobody debates my completed tasks with the big green check marks. So I now do this before every stand-up.
I guess we are drilling down to the similarly fundamental yet pointless truth about communication: it's easy when it is working well.
I concur. My people don't communicate very well and have no real team spirit. The stand up meeting helps to alleaviate that.
Of course, people who "don't communicate" and "have no real team spirit" are not fit for Agile and stuff, but that's another story :-) In my case, Agile, having frequent deadlines and frequent stand up meeting, helps me a lot to maintain a soft pressure on people. I don't like that (I'd prefer a team of super motivated people), but that's the best I can do. Having a more formal method like RUP wouldn't help because the analysis/coding cycles are too long. Having a kanban could help a bit, as Agile with such a team feels a bit artificial.
"My people" are all terrible and need "soft pressure" to succeed....
+1. A "manager" can't replace a "team". And having a "team" is one of the key aspects of being agile(this is what "peope and interactions" is about).
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!
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.
But by all means try it out; if it works for your team, great!
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.
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.
When everybody already knows what's going on, then the standup loses a lot of its meaning, and should get cut down to "Anybody blocked, or need anything they don't have? Everybody good to go today? Okay, let's make this happen."
But at a lot of companies, it goes the other way, turning into a Kafkaesque version of Show and Tell.
Most people that end up in technical management don't get any serious coaching on leadership or management. This leads to a lot of management-by-bestseller, cargo-cult agile, and the sort of dystopian teams that grind the minds of otherwise talented developers into useless pulp.
It's not that these managers are incompetent or bad-intentioned, just that they never got any solid guidance on how to lead, manage, and grow a team.
What's truly insidious is that the problems don't really start becoming catastrophic for months or years, by which time it's very, very difficult to turn the ship around.
One of the more powerful tools for fighting this sort of problem is the retrospective -- a weekly block of time where the team goes over what works and what doesn't -- but, more often than not, the retro is the first thing that gets cut from the process because "nobody has time."