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 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.