It was literally a stand-up, that is, everyone stood in a circle. Everyone was expected to utter exactly two sentences: what has been done yesterday, and what are the plans for today. It usually took 10-30 seconds per person, so the entire meeting was under 10 minutes.

It was pretty efficient: you almost instantly knew who are you going to talk to later in the day, if need be, or what changes to look at.

Very few people care about "what did you do yesterday?". It's already over, by that point. There's a lot of benefit to removing that one.

In my team we do it like this:

- how are the nightly tests? (we've actually dropped this in recent months)

- what's in the Test column, and does it still need manual testing? (we have automated unit and integration tests but also, sometimes, do manual testing just so a 2nd pair of eyes has seen a thing work. We're not strict about it)

- what's in the code review column? Are any of them stuck/unreviewed/etc? (to remind people to do reviews)

- what's in the progress column that needs help/pairing or some kind of management support?

- any other business

With these three rules:

- save the details for other, more focused meetings or Teams. Anyone call time on any discussion.

- strict max 15 minutes time-limit

- jokes are fine

Works well enough that the next time I work in a team that doesn't do it this way I'll do all I can to move them to this format.

...except the people for whom what you have accomplished is a dependency in their work. It can be a direct code change you'd have to merge into your current branch, or something you might want to start using (or finally stop using). It may be even something you have to contemplate on, and it may affect your work much later.

Work of people in a team is inevitably interconnected, and so is work of people in sister teams.

My current team is essentially front-end only and it's rare that we divide work up such that one person is waiting on another in the same team. If that's a possibility, we tend to pair instead.

Eventually we wrote a real-time web chat, just because it was a fun project for someone. But it did not replace the standup, until I left in 2011.

I've also seen teams update wikis for their daily standup.

Some things are not very enjoyable, but still necessary.

Also, if your boss tells you to read the emails, and you don't, then you can get fired. You can't get fired from your job for not exercising. If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.

The boss has no easy way to tell if you read the emails or not. The consequences of lack of information are often hidden / long term.

In many countries, it's pretty much impossible to fire employees for forgetting to read an email.

> If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.

I'll try a proof in a similar style - if Scrum was so wildly inefficient, the companies practicing it would be a long time out of business since companies with no meetings would easily outcompete them by offering better products/services for lower costs. Yet Scrum (or similar methodologies) are used in many successful companies all over the world, that's a proof that Scrum works.

How do you like them now, these oversimplistic "proofs"?

What about "forgetting" to attend a 10 minute meeting?

> I'll try a proof in a similar style

It wasn't a similar style.

The instances of people not attending standups I've seen were just symptoms of a larger problem, and such people did not last long in the company.

Standups are one of these in my honest opionion.

The main point of stand-up/daily scrum is to set up collaborations and coordination. It's where you invite pairs, inform POs of blockers and discoveries that will lead to longer timelines etc.

If you're doing all that anyway, keep going and don't worry about stand-up.

It was even worse than this: The Scrum operators wanted an engineer from every team they interacted with to also join their meetings.

So if a project made an API request to another project, they'd insist on pulling an engineer from that team into their weekly or daily meetings.

I had daily meetings with 10 people, half of whom might be engineers from other teams who didn't need to be there.

Meetings became so useless that everyone stopped listening until their name was called so they could work through meetings. Then every time someone's name was called, we had to spend 5 minutes recovering the last 5 minutes of the meeting to bring them up to speed.

The inefficiency was out of control, but the worst part was that some people thrived on this level of inefficiency: Lack of progress meant the empire builders could argue for more headcount, too many meetings meant the Program Management department could hire more program managers. It was like a case study in adverse incentives.

The agile manifesto was too abstract in it's original state, and folks who needed a rigid framework created capital A agile in order to adapt it to their cog in the machine role.

For my team of 6 in a ~20-25 person (remote) startup, we have a 30 minute dev meeting in the morning, and a 15 minute full team meeting where the agenda rotates daily around departments. I quite like it honestly, remote can be lonely and isolating otherwise.

Generally I think it's important to structure team responsibility around who ultimately needs to make the decision (although they need to consult others and get team buy-in). And hire people you trust to make the decisions. Then the meetings become about problem solving and getting through the work, rather than performance art and politics.

It should be a literal standing meeting. You dont get to sit and drone on. There is one in every bunch and when they make their peers stand for 10 mins. The team will self correct the person into not being that way.

That meeting is a check point. What is every one up to, and everyone else gets to hear. It's a way to get a team to gel (and many aren't)... If someone surfaces a problem in there (and they should be) then there should be some other team member offering to help out - there should be dialog if some dependency is going to get bumped by others being distracted.

These meetings are effective up to about 10 people. They work well with cross functional teams, or teams where the members have varying levels of experience.

Also no managers are allowed during our daily meetings. This is something important that enables more candid communication.

Something I've seen for the first time at my current project is instead of a daily standup, there's a daily thread to report what you've been doing in Slack instead. And then as long as there's nothing people want to go over, the actual standup meeting is skipped. We sometimes go a 2-3 weeks without an actual stand up call. It's pretty nice. Even if not, the calls are only scheduled twice a week anyway.

Much better than the 20 person in-person daily standups in the conference room, better get there early if you want to have a chair, at 8:15am every day, like a previous job.

I found it stressful to write the summary of what I did yesterday in the morning because I’d been thinking about other things in the interim. I discovered the “life hack” of filling out my report in the afternoon at quitting time which makes me, from the viewpoint of everyone else, the first to report. I find it really easy to do and when I get in the morning I have a plan in front of me which helps me carry forward my momentum from the previous day.

I once mysteriously turned into "not a culture fit" after several rounds of interviews with excellent feedback up to that point and I'm fairly sure asking a couple of similar routine questions about their dev process was what got me tagged with that label. I do consider that one a bullet dodged - if your process is so bad that you're worried about a candidate asking about it or you think they're being awkward for doing so then that says everything really - and I still ask similar questions of anyone I might work directly with/for today. But if there's a place you really want to work it's worth keeping in mind that some people apparently get rubbed the wrong way by this kind of question.