Riffing About Stand-ups


I recently had an experience where my team’s stand-ups were taking almost half an hour to do. They should never go on that long. Thankfully, several people noticed, spoke up about it, and we as a team took steps to resolve the issue. This made me think about stand-ups. I figured, why not write a blog post about my stand-up thoughts and experiences?

For most of my programming career, I have participated in stand-up meetings, or stand-ups. Stand-ups serve as a way for members of a team to update the rest of the team on what they are doing in a concise manner. People stand in a circle, going around and saying what they did. Some people participate in a formalization of this process, referred to as “daily scrums”, taken from the Scrum agile methodology. In Jim Shore’s The Art of Agile Development he explains that participants in a daily scrum answer three questions:

1. What did I do yesterday?
2. What will I do today?
3. What problems are preventing me from making progress?

Stand-ups don’t have to be a once-a-day deal. I have worked in places where we had two stand-ups a day: one in the morning at a designated time and one right after lunch. I’ve also worked in places where we had one stand-up in the late morning once all of the team members arrived in the office. I’ve even worked on a team where we had four 2-hour pairing sessions per day and had a stand-up before each pairing session. It’s all about doing what works for you and your team.

An arbitrary member of the team gives their status update first. Then go around in a circle (clockwise, or counterclockwise, it doesn’t matter) and have each other member of the team give their update. I’ve worked on teams where the developers give their updates first, then QA and business. I don’t like this idea because I think it suggests that somehow devs are more important than QA and business. I don’t believe that at all.

It’s very important that all members of the team stand up during the stand-up. This discourages stand-ups from going on for too long. If people have to stand for a long time, they get tired and want people to wrap it up.

It’s also important that stand-ups are brief. They should consicsely deliver information to the rest of the time and no more. Jim Shore suggests about 30 seconds per person for giving their update. 10 minutes for the whole team is a good max time to shoot for. They really shouldn’t go longer than that. They should not feel like meetings, except that everyone is standing. Personally, I like to keep a “work diary” where I enter the work I’ve done, along with any challenges or triumps I’ve experienced. This helps me remember what information to deliver during a stand-up.

Try to keep non-stand-up-related chitchat before a stand-up to a minimum. While I do think it’s great for team members to shoot the shit with each other (I think this promotes jelling, which is terrific for a team), it increases the time length of the stand-up, taking away from it’s briefness.

There are times when managers of different sorts attend a stand-up. If they tend to have long announcements, it’s important that they go last. That way, members of the team can decide if the information is important to them and stay, or if it’s not and get to work.

Feel free to share your stand-up experiences.

Related Posts

Build, Clean, and Rebuild in Visual Studio

The Dreyfus Model and "It depends"

Release With Less Stress

Lessons Learned From Sandi Metz's Practical Object-Oriented Design In Ruby (The First Half)

Closures in JavaScript

Functions In JavaScript

Breaking Down Syntactic Sugar With The Saliva Of Curiosity - The foreach Statement In C#

My Thoughts and Experiences on Pair Programming - Challenges

My Thoughts and Experiences on Pair Programming - Benefits

My Thoughts and Experiences on Pair Programming - Intro