I’ve been practising agile methodologies for some time now. The most common ceremony that I’ve seen agile teams do is stand-up also known as daily scrum meeting.
I’ll not go into what stand up or daily scrum is and what value does it bring. I appreciate the value it brings and would encourage teams to follow this ceremony religiously.
Every team that I’ve seen having this meeting does it in a similar fashion. They stand around in a circle and everyone gives their updates. This method sounds good but when practised, has a lot of problems.
I’ve listed some of the problems that I’ve seen.
Stand-up is a meeting. Everyone joins in-person or on-call regardless of convenience. Someone might prefer a meeting later but everyone else might want it at 9 am. Pushing that meeting to later time can be a challenge. Why? Read the next problem.
Stand-ups tend to become the start of a day. Every team that I’ve worked with had this problem. Most of the team members came to the office just before the meeting or mid-way. Even if they came early, they don’t start work as they know there is a meeting in another 15mins or so.
People might forget important updates as they showed up at last minute or late and aren’t prepared.
Anyone who doesn’t show up will miss everyone’s updates. And everyone misses their updates.
Stand-ups take a lot of time. They are intended to be short but generally go beyond the time limit. I’ve seen small teams dwelling on updates and large teams having too many people with vague updates.
Not everyone is interested in everyone’s update. This is especially true for larger teams.
People start solving problems or spark discussions in stand up meetings. Someone might know a solution to a blocker and they feel compelled to explain it. Someone might use it to discuss new ideas. An issue can cause people to replan things in the middle of the meeting.
One can argue that all these can be solved by one or the other way. But all those methods are difficult to implement and requires everyone to be on their toes.
One other way to fix all these problems is to use an instant messaging application like Slack.
Create a group or channel where everyone will post their updates as bullet points or checklist.
Some benefits that I see.
The biggest, one less meeting to attend.
The flexibility of when to share/read updates. One might want to share update at the end of the day, easier to remember what you did. Or while taking a morning dump.
No start of day ritual. Those extra minutes of everyone add up to a lot.
People don’t forget updates when writing down, they get time to think.
No one would miss anyone’s update.
Members who were on leave can also read older updates and get on speed.
One can skim through irrelevant updates.
No one’s time is wasted with long meetings and untimely discussion.
Members can use Slack for discussion over updates. Also, sometimes those updates and discussions are important and now you have a place to look back.
There are Slack bots as well to streamline this process. You can explore them as well. Or you can post updates as messages.
This is how a thread in Slack looks like. People can reply and discussions can happen.
Creating threads for discussions clears the clutter and make reading the updates a breeze.
I haven’t tried using Slack for stand up. But I’ve fantasized whenever a discussion kicks-off during stand up meetings.
Do you face similar challenges during your stand up meetings?
Would love to hear what’s working for you.
If you enjoyed this article, please share to help others find it! Feel free to leave a comment below.
Top comments (11)
My main issue with this approach is that I think stand ups should be focused on the ongoing work, not on the particular individuals partaking in the process. The everybody says what they did yesterday, what they are going to do today and if there's anything blocking them approach is a waste of time because people feel compelled to justify their use of time and talk about irrelevant details so that nobody thinks that they were wasting time.
My preferred way of running stand ups is to gather around the board and then go through all the tasks that are in process, for each task, everybody who has relevant information shares it, we check that we know how to move forward and that there is nothing blocking us, and then we move on. That's substantially harder to do on slack. It could potentially work, but only if people are participating synchronously, which defeats the point of your article.
I kind of like the stand up meeting as a daily kick-off, it's convenient to have everybody there to talk about important stuff, plan what we are going to do today and, if there's something urgent, decide how we are going to handle it.
I have only observed the cons you mention about stand ups (dragging on and on, people failing to show up on time consistently, nobody working until after the stand up, talking about irrelevant stuff...) when either (a) the meeting is not effectively facilitated or (b) there is something wrong in the team dynamics. Moving to slack solves neither issue.
👍👍👍 Agree with this
We've tried a few (a lot!!) different methods with our daily scrums and we've recently settled on what we call 'Walking the board'. This is more focussed on moving tasks across the board rather than everyone giving individual updates and so far we've found it a more enjoyable and effective.
We've also started rotating the role of 'Scrum Master Lite', who makes sure daily scrum is started on time and pops a summary on slack for team members who were in meetings/unavaiable etc.
Lots of different approaches, so I guess find one thats good for you and don't be afraid to try something new 😃
What do you think about creating a sort of a "minute" of the meeting after it takes place?
If it's valuable for your team, I don't see why not. In our stand ups I think I can fill in anybody who missed the stand up easily, plus most of the important stuff is on the board anyway, so I don't write notes for it, but I write them for other meetings and it's quite useful.
Thanks!
We do minutes for all meetings and it's super helpful.
Yeah, I suspect they are. It's a good way to have a log of what happened and to help anyone who might be missing for any reason to catch up.
My exact thoughts, I've been working with agile teams (and kind of a mix of methodologies) and have made most of the mistakes mentioned in the article, but I've actually managed to solve them all through some very simple "hey, check your tasks before the meeting", or an even simpler "aaalright, you guys go talk about that later on, let's keep the meeting going".
I've checked Basecamp's approach on asynchronous daily updates, which works very similarly to a Slack bot, but it brings up other issues, specially cultural ones. To mention one of them, written daily updates tend to be even more concise than in a daily meeting, which may lead to someone not mentioning something important, which leads to people asking for more details, which on it's own raises the old email-thread issue, where a single topic takes hours/days to be settled, when a 2min talk could've solved it.
And please, agile mindset is all about being practical and solve issues that matter while taking people in consideration more than processes and tools. If a daily meeting is not working, change it, try new dynamics with the team, schedule a daily meeting in the coffee table.. Anyway, there are simpler ways to solve problems such as these.
One doesn't just speak about changing Scrum rituals in public, you can be stabbed for this.
The Scrum priests are everywhere., you're not safe.
Even if I hate these procedures, I think if you remove the "sync" part of the meetups, its value will be less to 0.
If you use and update the tasks, all the info from the standup can be found in the current tasks also, so the information by it self is redundant, what matters is the act itself.
The most value I found in these "rituals" was a result of "sync", because we were in a room, forced to talk about our blockers, and other team members (that weren't involved directly) could help in finding a solution.
My guess is that, many of the team members will ignore most of the info that is not strictly related to them. Which you can do anyway in a project management solution already.
Also from the managers point of view, a big result of having a mandatory meeting at the first hour is that forces ppl to show up at work, at time.
We recently started using Teams for our daily stand-ups, and we've found similar benefits to what you outlined. It's also super easy to link to tickets or mention someone, and I use it for time tracking reference if I'm having a hard time remembering what I was working on that day. I'd highly recommend digital stand-ups over in person ones.
There are a lot of specific points that I would like to cover, but that would be an entire blog post by itself! I'm seeing common frustrations for an engineer when dealing with 'organizationally imposed Agile' vs 'team driven Agile'.
Remember, the team is the fundamental unit of a good Scrum implementation. Not the organization and not the individual team-member! This kind of frustration seems to come from broken Agile implementations that start emphasizing "processes and tools" over "individual and interactions" Scrum is a process. Standup is a tool. (I'll just leave this here agilemanifesto.org/ :D)
To echo some things from other commenters and expand on them: 'What I did, What I will do, blockers' by itself will not work. If the entire team comes into the room like robots, mechanically follows a formula and leaves, then you're not getting anything out of that meeting. A highly communicative team probably already KNOWS most of these things about each-other before they enter the room.
Others have mentioned alternative ways of performing the meeting (Task-focused, not individual focused), but like a lot of things in the Agile world, you have to look at the intent of the ceremony, not just the mechanical process.
The intent is to have the team QUICKLY gather together, start a conversation about any work that needs to be talked about and then conclude the meeting, with the ability to continue more in-depth conversations with only the people needed, and let everyone else get to work.
If your standups are taking longer than 15 minutes, then you need to change how the meeting is conducted (side conversations may take longer, but only if needed, and definitely not including the whole team!) If you have 15 team members that gives everyone a full minute to update the team. If you have 15 people in a standup, you probably need to think about splitting up the team and creating a smaller unit anyway!
Another intended aspect is absolutely as a 'kick-off' to the day. A 'Scrum' in rugby is basically a restart where the two teams huddle together and work for possession of the ball. Once possession is established the game continues. The stand-up is establishing 'possession' of the 'ball' for the day, and allows all members of the team to have a chance to break off into teams or have necessary discussions before they get hours into something that would have changed had they known 'X'.
Regarding 'wasted' time. 15 minutes before a meeting is the time to come in, get your computer set up, read emails... all those administrative tasks that might distract you from actually writing code. It may not be coding, but it is part of your work, and a valuable part too. Doing these things before standup, going to standup and then getting into the code-level work feels like a great 'flow' to me, but other teams might feel differently.
Finally: DO WHAT WORKS! That's the beauty of a mature Agile team. If your team has been running like a fine-tuned machine and YOUR TEAM thinks Slack for standup would be better than your current practices, try it (and measure the impact)!
Frameworks are there to facilitate an Agile approach, not enforce it. Once the team has their heads around working together, and you see the signs that you've created a working and high-performing team, changing how you do any of the ceremonies is really just a tweak to your process, with the intent of working more efficiently. There is no one 'sacred ceremony' in Scrum. Once you've mastered the basics, do what works for your team!