Introduction
Hello, developers! 🚀
In this issue, my battle against going async for everything when working remotely takes another step 😃: I will talk to you about Daily Stand-up meetings!
This practice is one of the most used (and abused) among all the Agile practices, and it has been misinterpreted and misused for a lot of years (the usual example is that it becomes an update meeting) - and now that working remotely has become very common, a lot of tools that implement an “async” stand-up are used by a lot of teams, adding another misuse of the practice.
Today, I will try to describe what purpose such meetings are supposed to achieve, and why they are important, going back to what I think is one of the most underestimated objectives of Agile: collaboration!
Since I came up with the idea of this post from this post on LinkedIn, and some comments below, you should have a look at it before reading this - I will still make a short intro through it anyway.
The real purpose of a Daily Stand-up meeting
The Daily Stand-up Meeting is one of the most used among all the Agile practices - and also one of the most abused, misused, and misunderstood.
Let’s start with a generic definition: the daily Stand-up is the practice of grouping the team 15 minutes per day in a meeting where everyone takes the word for a minute, typically responding to 3 questions:
-
What did I do yesterday?
-
What will I do today?
-
Do I have any blocker or issue, or do I need any sort of help?
We can sum up the goals of this practice into two things: status updates (question 1) & planning the day (questions 2 and 3): the purpose is to sum up what each of us did yesterday, and then plan the new day of work together.
Over the years, I’ve seen and heard of multiple common anti-patterns in daily stand-up implementation, doesn’t matter if in person or remotely:
-
too much focus on the status update: people simply recap what they did yesterday and what they expect to do today, mainly talking to the PM to let him know and eventually discuss blockers
-
too much focus on individual work: people are only focused on their moment of speaking, but have no interest in listening to the other members of the team because the work is intended to be individual
-
too much focus on the timing: respecting the time frame (typically 15 minutes) becomes more important than achieving the goal of the meeting
-
putting it in the middle of the day: as in the LinkedIn post, since people tend to get tired of stand-ups when they are only used as a status update, they start finding solutions to make it less tedious for the team; moving it in the middle of the day typically helps to achieve this, because people thinks “I already hate enough having a status update every day, at least do not force me to arrive early in the morning and talk as a first thing in the day” - understandable, since the meeting is completely non-sense when only focused on status updates.
-
going async: a different response that remote teams have to feel tired of status update stand-ups is to make them async; using some online tool, people can send their update at any time and in multiple formats (some use text messages, some use short videos, etc..) without the need to enter a sync meeting; that would be a good idea if the goal of the standup was the status update - but as I already said, that is not the main goal, is just a small part of it.
Those anti-patterns are typically the consequences of a non-ideal approach to Software Development: teams that don’t approach Software Development as a team effort. What most team still does today is to work as individual contributors on a shared codebase: each team member gets a ticket assigned by the PM (doesn’t matter if the P stands for Project or Product here) and works on that for the time required (at least some days, typically). Once they are done, they open a PR, discuss it with others (typically async via GitHub comments), and then merge it.
What Agile, XP, and Lean suggest, each in their way, is a different approach: Software Development works best when done as a team effort work. People should work more closely together, integrating their code more often, and in general, collaborate continuously during the day to ensure the Software achieves business results.
With this in mind, it’s easier to understand what Daily Stand-up should really be about: the main goal is to plan the day.
Async is good for status updates, not for planning and collaboration
If you accept that the goal of the Daily Stand-up is to plan the day and see things from the perspective of a team that closely collaborates to achieve business success, it makes a lot of sense to state that:
The Daily Stand-up should happen in sync and at the beginning of the day.
First of all, having the Daily Stand-up at the beginning of the day is a perfect match with the target of planning the day: it becomes the tool to trigger the “work is starting” message to our brain; thinking about where you left yesterday, and then planning what you need to do today to progress is ideal as first thing in the day.
This meeting is the practice suggested to also set up the collaboration we need among the team for today: for example, this is typically the moment when Agile teams set up pairing or mobbing sessions for the day, or ask for a sync PR review on the latest changes, or set up some additional refinement or customer feedback moment, for example.
On the other hand, there is the need for synchronicity: async communication is a better choice in some cases; for example to collect ideas, share status updates, or any kind of data in general, especially when a wide audience is interested in reading them - but, sync communication is far more effective than async when we need to brainstorm solutions, ideas, work together and collaborate. And this should be what Software Development teams do continuously every day: work together and collaborate.
When a team works mostly async, in the configuration of multiple individual contributors working alone most of the time and then putting the code together when done, typically after days of isolated work on a branch, then I’m sure that the standup is probably just a status update for you, and going async can probably improve your day in the immediate. But I have to say that I think this is not an ideal way of working in software: we can achieve more freedom and flexibility differently and still collaborate a lot during the day.
If you are more open to considering working together, I strongly suggest that you focus on improving your Daily Stand-ups by focusing mostly on the planning part: spend a few words on what you did yesterday just to sum up and start the talking, but move fast to planning today. To improve even more, start asking someone to pair with you, at least when you are doing something hard or very important - this will not only reduce the time for PR reviews but also make the Stand-up quicker.
Bonus point: once you move to collaboration and pair or mob most of your time, you might even not need the Daily Stand-up or reduce it to 5 minutes - because the team will be much more aligned and working together, therefore the need to orchestrate will be minimal.
What if you really want to go async?
The best tip I can give you is to do whatever it takes to focus on planning today way more than updating on what you did yesterday. If I had to run an async stand-up, I would suggest the following things:
-
Use a template: with a template we can make it faster to write (or say, if it’s audio/video) the message, but also easier to read/listen to it for the others; should take no more than 30 seconds to read/listen the message to the others, so that going through all the messages takes around 5 minutes and the cognitive load remains low.
-
Make it video: I would favor a video format, with a webcam + shared video on the board highlighting the tasks while are discussed; video format favors communication because spoken + face works far better than written one and makes it also easy and fast to say if we need some support.
-
Define an ideal time limit: I think it would still be important to have it at the beginning of the day; it can be a problem if you are totally async, but generally speaking the working hours might be different but are similar; for example, asking to submit our daily message before 10 or 11 am looks reasonable to me.
-
Define how to set up collaboration for the day: I would still try to force this stand-up moment to focus on setting up the day way more than being a mere status update, so I would decide a way to ask for some collaboration/help.
An example to favor collaboration after an async standup would be to have a tool where the person in need of help would start a conversation (it can be something like Stackoverflow for teams or simply Slack); the conversation starts in an async way, but everyone should be ready to go in a sync meeting as soon as needed, immediately if people are available, or scheduling a meet asap; the expectation would be that the person asking for support open the conversation leaving all the info in the first message, mixing text, video, and screenshots - as I said, collecting ideas and sharing info in async is a good idea, just ensure that people are happy and ready to move to sync communication as soon as required.
Until next time, happy coding! 🤓👩💻👨💻
Developing Software is an activity that works best when the work is treated as a team effort. Consider this every time you decide to add some async flavor to the work: we have to find the right balance between collaboration and async.
Yes, there is a trade-off there so make sure it’s an intentional one.
Go Deeper 🔎
📚 Books
-
Extreme Programming Explained: Embrace Change: this book doesn’t talk about stand-ups in general - but we can use it to reflect: are we respecting the values and principles of XP with our current stand-up? If yes, keep improving - if not, either fix it or remove it.
-
The Async-First Playbook: Remote Collaboration Techniques for Agile Software Teams: I’m not a fan of going async, as you know; “async first” make some sense, “only async” makes no sense at all, IMHO; but this book comes from Thoughtworks so it’s worth reading it and taking inspiration from it if you work remotely.
📩 Newsletter issues
-
A Quick and Easy Slack Hack to Augment My Team’s Daily Standup
-
Choosing Wisely: When to Go Sync ⏳ and When to Go Async ⏰ in Software