Top 5 Tips for Effective Stand-ups
When talking to colleagues and friends in software, there are always mixed reviews on agile. Basically every company/engineering team claims to do agile development, so sometimes it's hard to have an accurate opinion on the main patterns when they may not be implemented effectively for everyone. For example, I love retrospectives. I think they are one of the most valuable tools that agile gives us as developers, teams, and members of the bigger business our work contributes to. There are a lot of people (the majority of people I interact with) that would whole-heartedly disagree and say that retrospectives are a waste of time. I believe this has to do with the effectiveness of the process, not exactly the process itself. One other thing I see a lot is that people get really frustrated with their stand ups. This baffled me for a long time because I had always been on teams where stand ups were fairly effective. I didn't really understand how excruciating they can be if they are misused until I was a part of the team where each standup inevitably took 30 minutes, sometimes longer, and the leaders didn't try to make sure that it stayed on track of time or on topic.
If you read that and thought, "oh well I'm not the team lead that controls meetings so I can't do anything about it" - WRONG! Anyone on your team can help redirect the conversation, keep it timely, and keep it focused on the task at hand, which is a status update and a chance to escalate issues if they exist.
In my career I have worked at 3 companies and, within those companies, 9 different teams. Each team has had a different method of implementing agile (as they should) since the team makeup, dynamics, and actual work is different. That being said, I have experienced a wide array of stand up practices, and I really believe that if you aren't doing scrum as intended, it will become a burden for some, if not all members of your team. These are the tips that I have found, regardless of your team or other practices, make all stand ups more effective.
Learn how to give an effective update
My number one piece of advice for effective scrums is to learn how to give an effective update. The basics of an update are: what did you do yesterday, what will you do today, and what impediments are blocking your progress? Hear me on this: do not overwhelm your team with technical details of your task unless there is a very, very, very specific impediment you need help with. If you are stuck on a technical task, use standup not to explain it in detail, but to issue a cry for help to your team. A good rule of thumb is that your update should be no longer than a minute. I have been in standups (through fault of my own) where updates have dragged on for upwards of 5 minutes. It is excruciating for the people involved in the meeting, and often it is not relevant for all the members of your team. The best advice I have for getting better at these updates is to first and foremost talk about it with your team in a nonjudgemental way. If you have a problem with how one person gives their updates, don't make it about them: make it a learning opportunity for your team. You can give a quick brown bag on effective scrum updates and ask your team if you can start trying to keep updates short, sweet, and relevant to the whole team.
Embrace the phrase: let's take it offline
Inevitably, there will be updates that trigger massive conversation. It is software, it is normal, and all we need to do is learn about how to deal with these tangential explosions. As I mentioned above, typically when updates stretch out longer, it is rarely relevant for everyone on the team and then they feel that scrum is irrelevant and they don't need to be there. WRONG - everyone on the team is an important and valuable member of the meeting, and if the conversation starts to veer in the direction of going-down-the-rabbit-hole, no matter what position you find yourself in, whether it is relevant to you or not, the phrase "let's take it offline" is your best weapon. I am known as a fierce protector of the agenda of meetings. Even if there is a conversation that I am deeply entrenched in and that we uncovered a gaping hole in what we were doing, I am the first to recognize and pull us out by just saying we'll take it offline and schedule another meeting/powwow time. It can sometimes be perceived as rude to interrupt an intense conversation between other members of your team to interject they should take it offline, but it is often the saving grace of standup. Hone the tangent instinct to be able to recognize when we may be veering off topic in standup (aka the conversation is no longer about progress and impediments).
Use it as the forum to unblock team members
The most important function stand-ups serve is to make sure your team is able to do what it needs to do when it needs to do it. If your team is very up front with problems each person is having and how the team can help, great. In my experience, a lot of developers can be a bit too prideful to ask for help (nothing wrong with that, but it makes it hard to catch problems early). Once you know your team well, you can start prying into those corners to see if there are any risks and issues that someone else on the team can help with. For me, I have removed the words "Do you need help" from my vocabulary with certain members of my team because I know their gut reaction is "no, I don't need help I'm good enough to do this myself". It is important for me to be able to offer my assistance, whether that is brain power, test writing, test fixing, debugging, in a way that makes my team members feel like they are completely capable of doing it on their own while still being there to support them. Every team will have a different dynamic here, so start trying to ask if there is anything you can do to help in different ways to see how it is received. Sometimes, there aren't any fires to put out so you won't need to help, but it is so important to get your team in the mindset of asking for help when they need it, and not waiting until it's too late.
Sprint Health Check
Another thing that is so important, especially if your organization is new to agile, is to keep a pulse check on how your team is doing. Generally, the goal for the sprint is to finish all the tasks you have pulled in for that period of time. Stand up is an important time to ask, if not every day then at least once every 2, if the team is confident in being able to finish the tasks on time. If anyone has concerns, standup is the time to resolve the concerns by either pulling tasks out, reallocating team members to help on different efforts, or escalating an issue to a higher level. I always like to ask about the sprint health starting on the first Friday of the sprint then every day until the end of the sprint. Sometimes it is easy to wait until the day before the sprint is over to do this, but by then it is honestly too late as everyone is already gearing up for Friday. One thing my teams have done in the past is have a reward for finishing all the tasks we started with, which was milkshakes on Friday before our retrospective meeting. Our sprint health checks then turned into "Milkshake health checks". Yes, it was 100% manipulation and bribery, but turns out everyone loves a good milkshake and it's a great motivator to ask about how things are going and solving issues earlier rather than later.
The final thing I have found very useful for quality assurance people on my team is to estimate when tasks will be ready for QA. This is typically a problem for all teams who pull in 10 tasks, and 9 of them get to QA the day before the sprint ends while nothing happened the last 10 days. This can be really hard and frustrating for QAs because they can't finish all of the tasks in a day and then the sprint not finishing on time becomes their fault. This is 1) not true, it is the team's fault, and 2) can be avoided by making sure the tasks that are pulled in can be staggered in QA. This means there may be a mix of tasks, ranging from small, quick fixes to larger efforts so that they reach the QA at a staggered pace throughout the sprint. In standup, always check if those estimations are on point, and if they are not, treat it the same as you would any other deadline slip: reallocate resources if necessary, and get the task to a complete state and in the QA's hands on time. This makes the team run like a well oiled machine, and helps the team take failure as a team instead of blaming the bottleneck of QA since it moves the responsibility of the QA to the developer to get the task to QA at a certain point in the sprint.
I hope these tips have been helpful for you, whether you are a scrum master, a developer, or in an industry that uses the concept of a standup to keep on top of delivery. These experiences have helped me facilitate great stand-ups regardless of my role!