How to make standups that stand out?
If you work in the agile environment, you may already know the purpose of the daily standups. If you aren't aware of it, I would like to start with a brief idea of what they are and why do teams need it.
Standups are an integral part of agile teams. They are held every morning for a brief period of time (From 10-15 minutes depending on the size of the team). Everyone present on standup will briefly talk about things they did the previous day, things they are working on and issues they are currently blocked on.
It helps teams to understand what other person is working on, understand the blockers, support others if you have more information and let others know your priorities and plan. Therefore, standups are a great way to keep everyone on the same page on a daily basis.
However, as being part of these standups I have made a lot of observations and would like to put them under this post. Hopefully, it will help you organize things around if you are a part of the team which organizes stand-ups on the daily basis.
1. Keep your updates short and sweet
Although it may sound a good idea to add long descriptions about things you're working, it may be counterproductive if the team is large enough. It's recommended to add 4-5 short sentences for things you worked on yesterday, and things you're working on right now in addition to any blockers you're facing and need help with from other team members.
In case you're working on 10 different things (Which should not really happen), try to prioritize 1-2 things on the top and bring them up in the standup. This is beneficial since there are usually going to be so many people and it's impossible to remember all the things besides the top 2 or 3 things every person has brought up in the stand-up.
It helps individual contributor to stay up-to-date with and remember the concise summary, saves time in case you have too many people on your team or have to run between successive stand-ups early in the morning.
2. Include extra details as necessary
Stand-ups are not just for saying things which are work-related. Once in a while, you can also include things which will act as "heads-up" for rest of the team.
If you are going on a vacation, briefly explain when and how long you will be gone. If you're working from home or taking a half-day, it can also be communicated in short sentences.
This helps people to stay abreast of these developments which may not be directly connected with your team. If someone needs an urgent update before you go out of the office, they can organize an impromptu meeting or find someone else to work on while you're gone.
3. Be on time
This is one of my intense pet peeves when it comes to stand-up attitude. Stand-ups are there for a purpose and there is a reason why people need to be on time. I am not particularly a fan if idea when half the people are on time and waiting for several minutes before another half can appear.
This is fine if other people are in the meeting or successive standups, they can join later when stand up update is already in progress. However, unless people are preoccupied with something else, I don't see any reason to delay the meeting.
Once the majority of people are present, people tend to hesitate to start the updates until the key person arrives to start the kickoff. It's ok even if that person does not arrive late due to other engagements. One of the team members can be proactive and take an initiative as an ice-breaker and start with their updates. In other words, it's ok to have the scrum master who will be proactive in breaking the ice, easing the tension and initiating the stand-up. But it's not certainly great if the absence of that person is going to cause a disturbance within this daily routine.
In order to avoid this, make sure to assign backup scrum masters who can take over when principal scrum-master is unavailable or delayed.
4. Reserve some time later for longer updates
I am really sorry about the things I mentioned in the first point about keeping your updates short and concise. It doesn't mean that you've to miss the longer updates on a daily basis. You can still find time post-standup to talk about them.
Usually, a scrum master can organize things as a central resource for handling effective communication. If they think that someone is providing too much information, it's ok to request them to continue that conversation after everyone is done with their updates.
I have seen these scenarios when someone started talking about blockers they were facing, while at the same time someone from other team mentioned they were having the same problem, then the person from another team starts explaining the cause of the problem and what needs to be done to fix this - Imagine this being repeated for over half the people!!!
In order to avoid these kinds of things, let people provide their updates. But follow-up with them later on after the stand up is completed for everyone else. It's certainly not rude to interrupt them from giving longer updates and request them to follow up on it later.
5. What if you're working remotely?
If you've already followed the second point of this post and let everyone know about your working remotely schedule good job! But how do you provide stand up details in case you're working remotely?
Ignoring stand-ups while working remotely is a sign of mild unprofessionalism. You're still part of the team and thus obligates to provide updates on a daily basis. In order to make sure everyone is on the same page, make sure to make these announcements beforehand and update the immediate stakeholders.
If you're using Slack, and already has a channel for your team, you can
@herefew minutes before the standup along with things you worked on the day before, things that are in progress and current blockers.
This achieves two things - First, being working remotely does not stop you from updating your team. Second, providing updates beforehand the meeting helps people stay on-track before the stand-up and lets them adjust responsibilities in case you're blocked by something that can only be solved by coming into the office. (Lack of test devices, VPN issues, content restricted only within the company network etc.)
6. Using sprint boards
I am sort of divided on the strategy to use sprint boards during stand-ups. If I have to answer on its usage, I would say it depends!
Let me explain this with an example.
A year earlier, I used to work on Core iOS team. This team consisted of only iOS developers along with project managers and QA team members. It was a simple use-case since all of us were using only one sprint board. So while we provided our daily updates, we also used the sprint board as a reference point during stand-ups, moved the tickets around and shared the responsibility as stand up progressed.
This helped us to get the visual representation of things rest of the team members were doing and keep the sprint board in sync with actual work being done. We also kept an eye on tickets lying in the waiting or blocked column for longer time and prioritized the time later on to have an extended meeting on making a strategy which will deal with blockers, and in the worst case if blocker seems inevitable, move it to the backlog.
Later on, I became part of the larger team. This team has both iOS application and PHP developers. This made things complicated. We already had so many people on each team. But this wasn't the problem. These teams also had two sprint boards and separate project managers which made things difficult to manager in terms of keeping the sprint board on and sync it with forthcoming updates.
The final decision we took was to ignore sprint boards for stand-ups. We also made sure to update the board post-stand up to reflect the current status of tasks.
If you're going to use the former strategy, I would strongly advise buying a big monitor so that everyone can get the glimpse of things.
7. Be concise in updates also means be specific
When I say be short and concise in your updates during standups, it does not mean you purposely have to filter valuable information. It's all about improving the quality of the content.
But what do I mean when I say be specific?
Explain the feature title you're working on, mention teams or the people you're waiting to hear from, or talk about the bugs and incomplete requirements that are blocking you. What you want to convey is things in progress, blockers and people and team involved in the process. Later time can be reserved to include more people and go in specific details
8. Say Chan, it's a fun way to end the stand-up
I reserve the fun part for the last. Here's the definition of Chan from UrbanDictionary.com
Chan
a Japanese honorific, or suffix added to the end of one's name. chan is usually used when:
- the person is a small child, ie, younger sibling or friends sibling
- can be used on pet cats, dogs, etc..
Chan is basically that one word or sentences your team says together at the end of the stand-up. This is related to your team, the current project or theme of the day. As I changed teams, the way we used to create Chans also changed,
1. They could be a single word or sentence in context to your team or function
2. It could be ever changing. Like every day, a random person calls out the Chan
3. People submit their ideas in the box and scrum master picks them at random
4. If you run out of ideas, put all the Chan ideas on the sticky note and choose them befitting the occasion
5. Base your Chan off of big feature you are launching in the production or the event your company is celebrating
Saying Chan is not mandatory. I have been to teams where they don't say Chan at all. But it's a fun way to end the standup and promotes the collaboration between team members as coming up with Chan and saying it together signifies the unity.
These were some of my observations from the past and current experiences. What do you think about these thoughts? Did I miss anything or just put it in not so ideal way? Do you have something to add to this list too? Please let me know, I would love to hear the feedback from you!
