It was the best of times, it was the worst of times.
A Standup in Need of Help
20 employees stand in a circle. One by one each person in the circle indiscriminately goes through a list of bullet item accomplishments from the previous day. There are non-overlapping teams and some of these updates have no bearing on others’ work. People check their phones, they’re ready for this to be over with. No action items will come out of it. Standup has little value.
Some Thoughts on Improvement
Standups are a divisive topic among software development teams and software companies in general. Some teams happily gather each morning for standup and find real value in it, while others either skip standup altogether or, even worse, hold standups where individuals find no value but continue to partake because it’s easier than arguing against the status quo.
For any Agile, Scrum, Kanban, or little-a agile process, standups are a key component. The intention is to keep communication within a team flowing as well as to provide opportunities for team members to ask for or offer help. However, standups have a tendency to devolve into a mundane ritual practiced for the sake of process while serving none of the intended goals. At this point I am inclined to agree with those that say there’s no value in it. But that’s not to say that they can’t still be valuable – those teams just need to get back on track.
I recently asked Twitter whether they regularly hold standups:
Do you and your dev team do standup every day?
— Ryan Clark (@rypacl) February 26, 2016
I wish I’d also asked what people thought of the practice but still I did receive some comments. Most were something along the lines of “we do, but I don’t like it.” These are the teams where I think there could be some improvement. Clearly they’re committed to some form of agile process, but something is missing or has broken down. These teams just need a little help.
It is important to note that a main goal of standups is for a team of people working towards a common goal to share information and remove hurdles. It is not to update leadership or management on progress or the state of things, it’s not to discuss ideas or argue viewpoints. You’re there to paint a piece of the picture as it has changed from the day before and give a peek at how it will change today. If there is anything getting in the way of updating this picture, mention it but save any discussion for after meetup.
There are some key behaviors for extracting optimal value from daily standups:
- Keep them short.
- Keep them small.
- Keep them focused.
- Follow up afterwards.
1. Keep Them Short
There are a ton of resources out there that will tell you exactly how long your standup should be. I’m not here to do that and I don’t think there’s a perfect amount of time. I do think that anything over 10 minutes is excessive. Share what needs to be shared, identify topics for discussion or actions to follow up on afterwards and that’s it.
2. Keep Them Small
Something I see frequently as a company grows is larger standups. It’s important to be aware of the size of the group and who is attending. Is everyone present gaining value by being present? Are non-overlapping teams part of a large standup? If your company has grown to the point where you have definable departments, maybe it’s time to consider separate standups. This doesn’t mean that someone from sales can’t join the dev standup when they’re working on a feature of interest. That’s the beauty of well-managed standups. They’re there to provide value. Anyone can join, but they shouldn’t be mandatory for large, unrelated teams.
3. Keep Them Focused
Humans like to talk. It’s a fact. If a group of humans stand around without focus, they’ll talk until they have nothing more to talk about. That’s great, but not what standups are meant to be. Someone, ideally everyone, in a daily standup is responsible for keeping the conversation on track. There are three generally agreed upon questions to be answered by each individual at standup:
- What did I accomplish yesterday?
- What will I do today?
- What obstacles are impeding my progress?
These aren’t written in stone and I’m not here to ensure those are the questions you focus on, but they’re a great starting point. The third is arguably the most important, so some teams will lead with that. Try things out until you find a rhythm that works for your team. Don’t allow the conversation to veer away though. If there is a conversation to be had that is identified while answering these questions, note it and move on.
This is starting to feel repetitive, but it is important. Don’t talk about things that aren’t valuable in standup. The questions above are pretty open-ended. That’s not to say that everyone should go into detail answering each of them. As an individual, consider the work you did yesterday and the work you’ll do today and share the parts that make sense to share. Try to put yourself in your team members’ shoes and think about what they need to hear about what you’ve done and plan to do. Did you fix a bug that nobody’s been able to figure out? Great! Did you optimize an algorithm that’s been slowing everything down? Awesome! Refactor a huge mess in your codebase? Rockstar!
Sharing these accomplishments with the team should provide value if they allow the team to work better where the changes have been made. Other tasks that are not so beneficial to the team at large may not worth mentioning. Not that everyone’s work isn’t important – it is. But the point here is not to just talk about everything all the time. It’s to share information. An important thing to keep in mind is that you’re updating a distributed system on the big picture. Imagine each team member has an index of the state of the whole. Standups’ purpose is to update this index. Increasing the signal and decreasing the noise will amplify the value for everyone present.
5. Follow Up Afterwards
There will be an urge to go into detail about important, valuable work that’s been done. Fight that urge. Save the details for a lunch-and-learn or for conversation after standup. Same goes for work to be done – tackling a large chunk of feature work? Does someone else have some insight into how best to approach the problem? Make note of the fact that there’s more to discuss and wait until after standup. If there are any obstacles in the work you’re doing or will be doing, bring them up, hopefully identify who is best suited to help you overcome those obstacles, and be sure to follow up after standup. Whether it’s one person taking notes to dump into Slack afterwards or each individual keeping a mental note, it’s imperative to follow up. We practice standups so that we can identify these later conversations. It’s what makes them so valuable.
Conclusion
If it isn’t clear from this now-long-winded post, I find well-implemented standups hugely important for the health of a team. The impetus is to keep them well-implemented. It’s an active endeavor. Standups do not provide value without conscious effort from the team. Each member is responsible for contributing by not only answering the appropriate questions, but also by keeping an eye on the value. If it feels like there is a decline in benefit, ask “why?”, out loud! Work with each other to identify ways to improve. That, again, is what it’s all about.
An Improved Standup
A team of 6 developers stand in a circle. Each member’s update is concise and valuable to the rest of the team. Items are identified to take offline after the standup. Each member walks away with a better understanding of the state of their project, ready to take on the day!
