Dreaded daily standups

Popular to bash on daily standups as a waste of time. Yet, my experience, after literally thousands of standups run in half the world, is contradictory to that.

Different teams work well with different approaches. May it be 40 person standup under 15 minutes sharp, or a team 5 including a half an hour problem solving.

Yes, you read it correctly, I am stating it can even work with 40+ people. Just with different objectives, e.g. when you want to coach many people over months of work about how to be best involved with digital products.

Of course it did not start with a 15 minutes standup, but an hour long ones at the beginning.

If you feel you standups are a waste of time, consider these:

• The goal of the standup: it is not a status meeting per se, even if it includes status updates, what my set goals were just as an engineer: do I understand where I can help the most for the project’s success? Including if I can offer a quick solution to a marketing pain or an insight for a business metric, or a solution to a user experience issue.
• The content of the standup: while the usual what did yesterday - what today - what impediment and similar methods are useful, don’t forget that those are just helping advice and pointers to start out. If you don’t learn anything about the goal, then ask questions, listen for clues where someone may be stuck and ask for a five minutes extra to assist them, maybe just if you want to learn a new thing. The point is to push people to change their content they bring.
• The format of the standup: some prefer talking and conversations, some prefer writing, this heavily depends on the team members so discuss it, bring it to a retro which supposed to be safe space to adjust team’s processes to their preference. Learn to bridge the two ways. Early in my career, I always had written notes for my standup content as I prefer writing, and read it out loud. After a few months, a year, I could leave out the written notes. To be honest, I still have daily notes just on higher level and can adjust the message on the fly.
• The channel of the standup: be it in-person, online call or any written format, stick to a consistent format and enhance it with the another. Team may prefer calls, but should accept written versions if a member can’t make the call, e.g. life crosses. May prefer to do a written stand-up and only jump on a call when needed, figure out what works for your team and don’t be afraid to experiment.
• The timing of the standup: start at an early enough time that most of the team have the majority of the day to act on the new information. But don’t start too early so half the team can’t make the standup in time. Being an early bird, I liked the standups between 9-10 as I could already work 2-3 hours before to get enough info ready for my team, e.g. list of priority bugs and issues, designed architecture and product features, new requirements clarified to the point a dev could work with. Again, experiment what works for your team! One time slot that worked for a few months may be totally wrong for the next few months.
• The composition of the standup: even if you tried everything above, you still may miss key people who should have a priority on the project and are too disconnected from it. For example, you need to work on a close integration with another piece of software and the engineer representing that never on the standup. You will have misunderstandings, changed interface without knowledge, no matter what, bring that person in. If the project is strategically important, bring in higher leadership and they have to provide equally what they gonna do for the success. Adjust over time, you may need legal to be there for a few weeks daily then you not need them for a while.

I like daily standups, not because I like to talk, but to understand where is the team and how can I be most helpful, how can we push forward to success.

But process and rules are secondary. While prefer to bring problem solving to smaller circles and just identify the problem in the larger group, a few topics are important to all to hear and able to react. It is a way to mine the collective experience of all participants.

What not to do:

• Impose time constraints early on: in the team’s formative period (forming-storming) avoid enforcing process and focus on the content. Experts should feel confident to bring challenges to the open, not be afraid that they take too much time. You can always coach someone 1-on-1 to be more efficient with words, but cutting short a key meeting (which to be honest should be the only meeting a day that counts or pulls in the whole team).
• Paying no attention or checking out: everyone can learn about the other professions at least a bit enough to understand what they are struggling with and how they approach solutions. Engineers should understand product and business goals so they can offer better solutions. Marketing has to understand engineering challenges so they adjust offerings without compromising security, compliance or just incurring enormous costs. And so on.

Everyone needs to show some patience. Honestly, it worth it to make a business leader understand why your shiny 1000 line deployment script worth the day to fix (e.g. to have less bugs, less downtime and more customers buying or happy).

And you practice a life-long worthy skill: able to communicate value and impact.