3 ms·
Sounds good. 15 people seems too big, but if you're keeping it under 10 minutes then all power to you. Very few people care about "what did you do yesterday?".
by the_other 3y ago
Sounds good. 15 people seems too big, but if you're keeping it under 10 minutes then all power to you.
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.
- nine_k 3y ago> Very few people care about "what did you do yesterday?" ...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.
- skydhash 3y agoIf you have deps, it’s better to have a direct meeting with both teams in order to resolve mishaps and have a channel of communication setup for that. Daily standup is a poor replacement for that.
- the_other 3y agoThis is a good point. I imagine in a more cross-functional team this would become more important. 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.