Daily Standup

Daily standups are short meetings where team members come together to update each other on what they have planned for the day and build a stronger sense of team spirit. Different teams do this a bit differently but what I will present here is a pretty solid basis for any team to follow.

Meeting agenda

1. Select a leader

   At the start of each daily a leader should be appointed. The leaders job isn’t scary at all and in fact I encourage teams to have a rotating leadership so that all team members get to take turns being the leader.

2. Leader gives their update

   Leading by example the leader always gives their update first.

3. Leader picks who goes next

   All members should give their update and it’s the leaders job to select the next lamb for the slaughter. How you do it is up to the leader, just make sure you have a system that works for you. It’s usually easiest to just check in whatever meeting app your team is using which people are present in the meeting and just go through the list from top to bottom. Note that even if some attendants might not be developers they too should be providing their update. You can also pick people at random which can help to mix things up, but it can be a comfort for people to have a predictable order if they’re nervous, and going at random tends to slow the meeting down because you lose track of who you have left to do.

4. Leader asks the group about parking lot items

   Parking lot items is just fancy words for “things you want to talk about”. If you have items that need to be brought up with a majority of the group then it’s ok to raise them now. If you have items that only require the attention of 1-2 members it’s more appropriate to request either if they can stay behind after the others have left so you can talk to them, or schedule a separate meeting. Standups should after all be a quick update spanning 15-30 minutes at most.

5. PR Callout

   This is an optional extra step that tends to be very helpful in teams. It’s common that PR’s end up sitting unmerged for prolonged periods of time. This isn’t a time to actually do code review, it’s just a time towards the end of the meeting where the leader asks if there are any notable PR’s people want to get checked. If there is you call out your PR and it’s expected then that whoever is capable of doing review of your PR does it at their earliest convenience.

   Remember when working in a team that your primary function isn’t to write code, it’s to unblock team members. If I get to choose between unblocking 3 collegues or getting a PR made for one of my own issues the choice is simple, unblock the collegues. So make it your highest priority to do code review, after standup if you’re assigned to something do that before you let yourself work on anything else.

Giving your update

1. Leader displays your board of active issues

   Whoever is leading the meeting should be sharing their screen and showing off the teams issue board.

2. Yesterday I worked on A, B and C

   Give a brief update on what you did since the last meeting. Be brief and just say things like “yesterday I got a PR up for X” and “PR Y got merged so we can mark issue Z as done”.

   If you ran into issues it’s ok to inform the team now but don’t make a long discussion about it. It’s usually best to just say “I ran into some issue doing this thing and I’d like to discuss it during parking lot”, or “I ran into some issues and it’d be great if you and I [persons name] could schedule a meeting to talk about it”.

3. Today I plan to work on X, Y and Z

   Same principles here as when you inform people on what you worked on. You can’t have issues already of course since you haven’t started working, but you might need to discuss it nonetheless to clarify what needs to be done as it’s not always the case that issues are sufficiently descriptive.