Hacker News new | past | comments | ask | show | jobs | submit login
Are Daily Scrum meetings worth it? (valuemotive.com)
75 points by klemola 8 months ago | hide | past | favorite | 118 comments

Daily stand-ups have two formats, one is Round Robin that has origins in Scrum, other is Walk the Board that is more Kanban. I highly recommend you switching from "did yesterday/do today" to "walking the board" as it is less about checking what each employee delivered in a day but rather what the team can do to move tickets through the board. It is also more inclusive allowing quiet/introverted/non-native English speaking members of the team to participate in the meeting rather than rehearse their updates in their heads ignoring others.

I agree with this, I found that if you go for the Round Robin format, often, people are just thinking about what are they going to say next, and how to make it sound like actual valuable work rather than listen to the colleagues. It gets akward when some people get a lot done (apparently) and others not, also not everyone knows how to "sell" their work, and IMO it can create weird dynamics.

Walking the board is much more helpful for the team and retrospectives and one to ones can be used to talk about productivity differences, individualities and other issues.

I also noticed this.

We came up with a variant to fix this. You have to say what the next person in the circle said they'd do yesterday before your talk.

This forced everyone to pay more attention as you don't know who would be standing next to you tomorrow. It wasn't easy to do but I think it did make people more aware of what was going on.

This sounds horrendous. It doesn't really feal like it would achieve much either except making standups even harder.

This is a terrible approach for the fact that instead of addressing the problem of people not listening because of stuff not relevant to them said from others, it ensures you must listen to that irrelevant stuff.

So instead of wasting some people time, you are now wasting 2x that time.

Make the meeting relevant to everyone, make it tight (time-wise). Hiding the problem under a tarp ensures it doesn't get any improvements.

Why is this voted down? Stand-ups are supposed to be about increased team cohesiveness and this helped their team achieve that.

wow this would suck in a 20 person standup

Literally everything would suck in a 20 person standup.

can confirm

Why would you have 20 person standups?

because government project? although I imagine this happens in non-gov settings too, this is just my experience.

Here's the reason: managers are so spread thin that they don't want to be in 5-10 standups all morning, so they combine around organizational structures rather than product(s)/deliverable(s). Another case of the software delivery matching org structure...

Of course the next question in line is "why is a manager involved in the standup?"

> because government project? although I imagine this happens in non-gov settings too, this is just my experience.

Why not split into smaller work groups? What's the advantage of 20 person teams?

organically this is what happens to actually get things done. but mind you, these small work groups are successful despite the large standups. life finds a way...

Well, yes, a 20 person standup is a little more than twice the maximum size conventional wisdom holds is appropriate, so it is going to suck to start with and much advice for normal 5-9 person stand-ups will be counterproductive and make it worse.

I know we tend to have little control over this as ICs, but I think the party line here is that 20 is too many people to effectively make use of most agile/scrum ceremonies. Do you actually need to know all 19 other persons’ updates?

Individuals don't, but the managers, who may be well meaning, feel the need to.

I agree with this. By far the least useful of the standard standup questions is "what did you do yesterday".

Focussing on the work to be done puts the emphasis on teamwork and skips the pressure on people to justify themselves or play politics by showing off.

That's assuming everyone is doing the work and they're being trusted to do the work. If that's not the case, then you have bigger problems than the format of your daily standup, and standup is not the best time to address them.

We have been trying to show what we did code-wise (or explain if it was something that didn't end up with code). The goal however, is to show some coding practices or new functions created that other team members might find useful, as well as working as a brief "review" of the code itself.

The goal is not to explain what you did. Happy with the approach because knowledge is actually spreading across the team currently. Meeting do get much longer though (1 hour usually), but time is recovered mostly on code reviews which become shorter. Usually lot of discussions sprouts out of this, leading to better code overall.

It should be noted that the "round robin" format has an important aspect which is to enable each team member to air his/her personal grievances regarding anything related to the project.

I would rather have this kind of discussions in the retrospective. It is a dedicated time for the team to discuss pain points, and to take actions to heal them.

I think the sooner the team is aware about issues the better.

I'm going to assume the GP meant blockers rather than grievances. Grievances are more like injustices and shouldn't really be aired at standups in a healthy team.

I think putting this in terms of "grievances" isn't helpful. Blockers, problems, observations, are all useful to report.

"Worked on adding discounts to the shopping cart page. Went over to talk to Chris in billing about that, and he mentioned in passing that they are planning to move on to SAP next year."

That could be incredibly important information for the team! It doesn't come up as naturally when working through stories as in a round robin.

Grievances should relate to a ticket on the board, if not then make a ticket for it, if not that then is the grievance important?

> Grievances should relate to a ticket on the board, if not then make a ticket for it, if not that then is the grievance important?

That mindset is precisely the reason why these meetings are important, because these grievances might not necessarily reflect or deserve a ticket. They might be nothing or they might be something. What's important is that these meetings create a space where they can safely be addressed without creating any burden on the team and on the individual reporting them.

I've read somewhere that these meetings work as therapy for the team. Perhaps by putting it this way you might better understand the issues these meetings solve.

This stuff goes in a retrospective. Airing of non specific grievances, therapy, etc. A scrum should be as short as possible.

There is a simple solution to this. After the board is done someone can just ask "Has anyone got anything else to add?"

>>There is a simple solution to this. After the board is done someone can just ask "Has anyone got anything else to add?"

That doesn't cut it. Being expected to talk about stuff doesn't put you on the spot, and purposely requesting the team to address a concern makes you stand out as the one creating problems where none existed.

If team members need to be directly asked if they see problems otherwise they won't do it themselves, then there is a much bigger trust or "safety" issue at play.

> rather than rehearse their updates in their heads ignoring others.

Personally, I always try to take quick notes ahead of time in order to be able to listen to others during the meeting. I'd highly recommend this to everyone to help focus on what others are saying.

I like to alternate these. One day we do a round robin, the other we walk the board. It helps to have different perspectives on the work you're doing.

Also like this method. Walking to board every day isn't always necessary, there shouldn't be that many changes from one day to the next. But by only using round robin every other day, people actually have something to say.

Walking the board is effective to have all team members in the same page of what's going on. But if the amount of tickets on kanban boards is huge, it could be time consuming. I'd rather have weekly "walking the board" meeting than a daily.

Genuine question - how big is this team and how many work in progress tickets are there? For a 7 person team I'd question how many in progress tickets you genuinely could be working on, unless you are breaking down to a very very low level of task.

The last few teams I've worked on moved the daily Round Robin into slack. You would have to fill it out an hour after signing in and before you left for the day. Accountability was key and having it in the dev-chat saved a lot of time.

Our 'walk the board' process was saved for tuesdays and thursdays and involved product and project managers. We set a 45-minute max so noone would rabbit hole on any one ticket.

This has been my favourite process so far because this was the highest level of team accountability I've experienced and you would only spend 1.5 hours a week in meetings.

Gotta try to "walk the board" in place of a daily someday soon. Sounds nice.

This kind of daily meetings make me feel like I'm standing trial for my crimes. Especially if I've had a bad/down/unproductive day, which happens.

Maybe it's better when you take away the power relations. And reduce the frequency during non-critical periods.

Making classic standups useful and comfortable definitely requires psychological safety. You need to feel like you can occasionally say "worked on X, didn't make any progress", and a manager or a rival isn't going to pounce on you for it.

If you don't have pervasive psychological safety, there's a lot of stuff from XP that isn't going to work.

Exactly what I was about to say. There are many things that are dismissed in team culture because of the fear of feeling exposed or blamed but that is an issue of culture and/or insecurity, not a disadvantage of using agile methods.

This reminds of this scene:


From "The Dictator", where Nuclear Nadal is reporting on his progress.

My 2c - the key is that the focus should be on delivery and not some justification for the work you did yesterday. The idea being that you are standing up looking at the work in front of you and the TEAM itself should be focused on how to move things across the board (ie delivering it to whatever definition of done makes sense for you)

> Focus should be on delivery

But if I wasn't productive yesterday, I'm not delivering today...

Also, the fact that someone _says_ the focus is on delivery doesn't mean the dramatic focus of the situation is not on whether or not you've "been good" yesterday.

>Maybe it's better when you take away the power relations

What do you mean by this? Are there significant issues with the management or other devs? This really should be a time where you bring up the issues you're having, and options for others to help you.

Sometimes, tickets just get way underpointed, and I've definitely felt the "on trial" frame of mind, but that's more me putting more pressure on myself. It definitely helps when the rest of the team is asking "ok, you're in a rough spot. What can we do to make it easier?"

> Are there significant issues with the management or other devs? This really should be a time where you bring up the issues you're having, and options for others to help you.

Any issues with the management an engineer brings up are issues readily solved with a pink slip for the engineer. "Reading the room" is essential -- understanding the company culture -- before you speak. And even then, you might be wrong.

Wow, I really feel sorry for whatever situations you've found yourself in.

> What do you mean by this?

I mean, if there isn't a manager who can give you orders and personally decide whether you get fired or not. Of course that's not very realistic in a privately-owned, hierarchically-managed commercial company.

I skipped some meetings randomly (I was busy on the phone), so that's the escape hatch. But alternatively one might argue that if it's mandatory nobody will come.

I don't have a good argument for the second part, except that I'd attend it to be up to date whenever I could.

For me, they are. More so in my current role with a fully remote company. All calls are video calls, with RingCentral, Slack or Google Meet. We get to see each other face to face, get some social time and chit-chat a few minutes before diving into the standup.

Other teams do async standup via Slack, via Standup Alice. It seems to work for them.

I also really like the addition of an "open forum" in my team. Is there anything you've heard from other teams that will probably have an impact on this sprint's tickets or ones in the queue for the next one? Its also a good time for the PMs to relate any relevant conversations had with other PMs that we should know about.

The real key to this is there's no power play involved, and to have a good sense of scope about what's appropriate to bring up and what isn't. We're also a hybrid core/product team, so regular checkins are beneficial overall.

I think they are worth it for remote teams. Most of the work comms can be easily done in slack, but there’s definitely a benefit of making people talk to each other and express emotions at least once a day.

Normal offices accomplish that with water cooler talk and informal chatter, but you miss on that with remote teams. There might be a better way to solve the “loosing of esprit de corps” thing but dailies are the easiest thing I’ve seen do that.

Personally I don't like the daily scrum meetings need a coordinated time. For the company I currently remotely work for, it's fine for my colleagues if I just write down in Slack what I worked on during the day at whatever time is convenient for me.

Why not weekly? Or twice a week? Advantage of remote is that you can prioritize incoming information and everybody is onboard with asynchronous communication by default.

It's not about information sharing, dailies are crappy for that anyways. You should always have async information centre so people can get up to speed.

The idea is to be able to share the squishy emotional human bit of working with a team of people.

Without it I've seen people just slowly drift apart. You'd see a comment from a coworker on your PR and be like "argh who is this guys think he is! He's totally wrong" but if you can talk with him about it in video it becomes a lot less confrontational. You can apologise and be apologised to.

A jira board is just a means to have some shared concern to talk about. And done properly can leave you with a feeling of being part of something bigger, rather than a lonely coder talking to a computer.

> You'd see a comment from a coworker on your PR and be like "argh who is this guys think he is! He's totally wrong" but if you can talk with him about it in video it becomes a lot less confrontational. You can apologise and be apologised to.

Unless that doesn't happen. Perhaps he digs in his heels that he's "right" when he's demonstrably wrong? Or 'he' is the team lead, and it doesn't matter whether he's right or wrong, we all now move in that direction "because". Having to have video/f2f in situations like that adds more stress.

Dealing with this situation now, and it's bad.

Well one thing that "How to win friends and Influence People", "Never split the difference" and "Non Violent Communication" in general has thought me is that it's very hard to "convince someone you're right". Dealing with people successfully to win them to your cause is a very hard skill to master, one that I'm struggling with myself.

A better strategy I think is to try to get emotionally in sync with the other person first. Win them as a friend so to speak. And visual queues in that case become paramount. Co-location is even better, but we're talking about remote now don't we.

People sadly don't usually listen to the facts, especially if there's an argument, and double that if the argument is public (more than two people involved). It requires enormous emotional courage to admit someone's right before a lot of people, so we hardly every do it. That's what most of the advice from those books is to get to know people first, gain their trust and talk to their emotions rather than the facts.

Dailies are not meant to fix that I think, more like keep the team working in the long run if it had a good start, and help leaders find out about problems quickly and address them elsewhere.

Going off topic a bit though but in your example - a team lead that's going off to a demonstrably wrong direction - well they have more things on their mind than that particular thing probably, "does my team listen to me" might be one of them or "other business consideration that we're not privy to" is another.

One way to approach this is to support them publicly but have a one-on-one with them and express your concerns, without personal judgement and the like. After which you can ask them to help you with a particular task, preferably one that you know will hit the problem where you've thought the direction would be bad. And never say "I told you so!" Help them through the arising situation and bam! You will have them on your side plus the project would be moving in a good direction.

Also a lot of times it might turn out that this direction was actually preferable. You'll get to say "yeah you were totally right" and win them to your side as well, and learn a new thing in the process!

> It requires enormous emotional courage to admit someone's right before a lot of people, so we hardly every do it.

I've got a couple of current situations where... the other person is not wrong (charitably "right"), but the timing and prioritization is poor. Or, they may be 'right' but for wrong or bad reasoning. (yes, doing "foo" in the code is good because is helps with code readability, but no, it doesn't bestow another layer of security to the project, and no, it's not a 'performance boost').

These are even harder situations to deal with, because, again, technically, the idea being presented isn't "wrong" or "bad" in an absolute sense, just... strategically, it a step in a demonstrably bad direction wrt to project progression and hitting deadlines.

> or "other business consideration that we're not privy to" is another.

I've been on teams of up to 50 people - divided in to multiple smaller teams - company in the hundreds of employees. Yes, there may be reasonings that I'm not privy to - completely understandable (expected). I've been on teams of 3-4, talking to an end client multiple times per week about goals/deadlines/etc. There should not be any reason for info siloing with respect to anything at that level (save, perhaps, financial considerations like salaries, contract amounts, etc).

Agile is about moving things fast from left-to-right. Way too many people do not put their hands up when they get stuck, they just keep soldering on. The daily is the chance to either unstick or to put difficult tasks back into the pot - something the Scrum Master will be more qualified/willing to do to unblock than the developer will be assuming it will make them look bad.

Q. Are daily scrum meetings worth it?

Programmers: no.

Project managers: Why can't we do this twice a day?

> Usually the better the project is going, the less you need the daily.

That quote sums it up pretty nicely. To bad of a naming for this type of meeting. Hard to negotiate to do a "daily" less then daily.

Agreed - whether it should be done daily or not is a decision based on a wide number of inputs.

When it's work best anecdotally, is when we hold regular retrospectives ON our agile ways of working. EG: Is the standup working for us? What should we stop/start/continue in our standups?

When this 'retro of agile' (rather than just project/product retros) take place regularly you quickly come across a format and cadence that works for the team.

Tools are just tools, they should work for us, not the other way around.

I'm sorry, stand ups are literally a psychological trick played by middle managers to put pressure on devs. They undoubtably lead to higher turnover from devs fleeing chickenshit and I've never seen one actually lead to better code.

I would wager that 'better code' isn't the main (or even a major) objective of standups... getting the project done is. But both are important

In a past life as a Product Manager, one of my top devs rarely attended standups. One day, she rolled into the office mid standup, went over to the coffee machine, and prepared a cup. Never looked in our direction, and proceeded to begin her work.

Later during our 1-1, I asked her what the issue was, and she bluntly told me that she thought standups were useless.

I never brought it up again, as she was an amazing developer, and her documentation was absolutely pristine. After that, I myself stopped seeing the value in universal standups. If a person is good, they make it known in other ways.

That isn't the point at all. The standup isn't to make her a better developer, it is to make the team work more effectively. What happens when someone is taking a long time to do something that she knows a shortcut for but they won't know because "she doesn't need to come".

It's a sad culture when a developer thinks they don't need the team or when, for some reason, they don't have to come to standups.

I think she said standups are useless, not that the team is useless. I completely agree. I've never found any use for them in years of being forced to do standups. They are 100% for managers. If someone has an issue I can help out with, they message me directly or post in a channel and we work on it. That's what happens. Very simple. They don't have to wait until the next day and they don't have to bother everyone else with their likely-irrelevant issue.

Also, how can standups be designed to make the team work more effectively? They essentially steal some of the best development time in the day by insisting on being the first thing done in the morning, when most people are fresh and ready to go. There's no way in hell this was designed to be anything but a manager's control tool designed to slow down the team in bureaucracy and bullshit. And it does a great job at that.

> Also, how can standups be designed to make the team work more effectively?


* NO MANAGERS. The standup is for the scrum team to organise and help itself. It is not there give a status update for the manager. The manager isn't in the team, and people have trouble talking freely when the manager is around.

* Do an issue based standup. Discuss the status of each issue on the board from the right to left. The primary question is "What can we do to keep these issues moving along through the process?".

* At the end you can ask "Does anyone have anything else important to add?". Maybe people have to leave early today etc etc.

That's it.

I know you mean well with your comment, but I secretly suspect that you are actually saying that you like your team and think this is jerk behavior. I have never seen how a standup actually helped team cohesion. Being called to stand in front of the middle manager and say your spiel about how soon you'll be done doesn't help team cohesion, unless you mean by simply submitting to the same crap the others are. Team cohesion is just flat out more complicated than 10 minutes of parrot and nod.

If your standup meeting is "stand in front of the middle manager", you're doing it wrong(tm). As with all things "agile", many places love the labels, don't understand the ideas. In my (limited) experience, standup meeting involving leaders only work if the leader is clearly part of the team (and e.g. the pressure to get things done comes from outside).

Of course, that doesn't help you if you're stuck in an organization doing it badly.

It doesn't matter if it's a manager or your peers, you shouldn't have to justify your work every single day.

It's childish and immature and if you for some reason need to do it to be able to communicate, learn how to communicate properly, don't foist your miserable way of working on others.

Why does a standup have to be "justifing your work" (it's not supposed to be), but other communication about status not?

The very article linked shows the 3 questions.

"What did you do yesterday".

How is that not a loaded question?


Anyone encouraging standups is just contributing to the poor mental health of programmers.

That can become "justify your existence", but it doesn't have to. What you did yesterday can actually be relevant information to your coworkers.

It sounds like either your work culture is somewhat toxic, or else you are rather defensive.

Actually, the dev has exactly 0 input on how the standup goes. The middle manager sets the true goals and the dev is either in or out of step. Whether anyone else in the meeting gets anything out of it is strictly a side effect, and not relevant to the manager. I've never been able to make a stand up into what it's supposed to be when the manager makes it about meeting deadline and not hearing about problems, regardless of whether you have any problems. Maybe you have worked in great places where this sort of dynamic doesn't happen, but I've worked exclusively for cold capitalists and it's always been about justifying what you are doing and feeling the pressure to get done faster.

When I tell my team what progress I made yesterday, that's not to justify my existence, it is so they know what has and what hasn't happened. Which is why the among equals, not towards a manager, bit is important.

Wow, I didn't think my comment would be so contentious. Just to clarify, I did not say that she felt she didn't need the team, nor am I sure where you got that impression.

She was quite communicative in other ways -- just didn't see the need for standups. Due her effectiveness, I had no reason to try to change that behavior. She got shit done, and everyone knew it -- with our without a standup.

Edit: And please note that I said "universal" standups. I feel we often want to apply a one size fits all to developer mindsets. Maybe she was shy. Maybe she felt pressure from the ceremony. Maybe she did just feel it was a complete waste of time. Either way, my job as PM was to get products built, and a big part of that was understanding the individual mindsets and capabilities of the engineers on my team.

> This will interrupt programming flow.

This for me is the biggest drawback. When you are in the zone and interrupted it takes long to get back in the flow again.

Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me. This is hard to explain in Agile with a PM/scrum master present.

Edit: PM/scrum master because we have mixed environment.

> This will interrupt programming flow.

This is why you do the standup first thing, before people have started working. There is no flow to interrupt.

> Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me.

If you're doing XP, or any kanban-flavoured variety of agile, you pick up one story/feature/etc and work on it until it's done. You might jump around in the codebase to build that feature, but you work on one feature. That's easy and natural to describe in a standup.

If you're not doing that, then indeed, it's going to be hard to talk about what you've done.

But to be honest, what you're doing is almost certainly not very effective, so maybe stop doing that?

Having it be the first thing in the morning seems to be the least efficient option possible, way worse than being interrupted in flow. This is the peak working time for most people, peak alert time for the majority of the population, and therefore the most productive time for many people, even many of those who are not prone to waking up early. Starting with something that's mostly useless to the developer and taking focus away from what really needs to get done that morning sometimes kills the entire morning. I'd rather be interrupted mid-flow and I'm certain I'm not alone considering the majority of the population actually is most alert in the morning (along with the other peaks of energy throughout the day). The optimal time for such a meeting would probably be either right before or after lunch, with lunch being variable and taken based on the workload of that day.

> But to be honest, what you're doing is almost certainly not very effective, so maybe stop doing that?

You most certainly don't have enough information to make such a recommendation.

> This is why you do the standup first thing, before people have started working. There is no flow to interrupt.

That requires all the people to come to work at the same time.

This point is dealt with in the article. People have different traveling arrangements. In my case sometimes I have to drop off my child at school and head in after the morning rush hour. So daily stand up is not first thing in the morning.

I worked on a project where we had the daily scrum (by conference call) at 4pm, precisely because people all started work at different times. All that that achieved was to mean that I was unproductive from about 2pm because I was thinking "if I get into something now I'll get interrupted before I properly finish it"

There's no PM present in the Scrum daily. In fact, there's no PM in Scrum.

Jumping between different stories before finishing them is fine in solo projects, but if you're working with others, it means more code conflicts. That said, it is absolutely possible to work on multiple stories in Scrum.

I work Business Intelligence (BI) using SQL and a reporting tool of choice. There are times when I just cannot write another peace of SQL. I can tell what I am churning out is long winded and likely to be slow. There are always other tasks such as setting up stylesheets, setting my templates, distribution lists for reports and so on. The problem I have is I don't know when I will be tired, typical issue is always the data quality that results in complex SQL.

The one true benefit that i remember from my time working in scrum was when we moved the scrum meeting from morning to 12 o`clock. And the benefit? After the meeting, everyone was already standing, so we went straight to lunch as a group without any further delay. Saved a lot of time and effort to organize everyone.

Personally, I like the slack message standup over the meeting, but that's mainly because I'm a terrible listener, at least with text I can go back and see what a certain person has decided to mention. I also feel like it's easier to mention someone that I might need help from during the day

The problem I have with the Slack model is that it becomes opt-in. Lots of Devs simply won't read the channels because they won't care what other people were doing even if that knowledge helps people to skill-share, coach, encourage or take part of the work off of someone else.

I don't like or dislike daily meetings much personally, but I think they are needed - mainly for scrum master and PO. Daily can't be replaced realistically with bug tracker dashboard because 80% of daily time is not bug status discussion but let's say mostly human problems. Also I believe there is zero correlation between success of the project as a whole and a need for daily, none at all. People suggest async text in chat but eventually harder and more detailed issues will raise a need to actually talk and while it will save 20 minutes time of each participant who now don't have to listen to other people's issues it will also isolate people from potentially useful information and prevent them to suggest their ideas or ask for clarification , basically limiting in-team collaboration.

I think they are needed - mainly for scrum master and PO...[but] there is zero correlation between success of the project as a whole and a need for daily

So, basically, what you're really saying is they're not needed and you don't need scrum masters or POs.

No, I mean that when project is successful a need for daily (or other detailed sync) doesn't diminish. You are still making decisions, plan complex features and communicate with the same humans, only company account has more zeroes, that's all difference.

PS: in our case SMs and POs are actually doing useful work and we aren't holding any worthless meetings which are solely to entertain people not doing anything. If that was what you implied.

> Another variation would be to do the daily on Slack which can even be asynchronous.

That is exactly what I do. Every morning answer 3 things in Slack. It is also good way to say "Good morning, now I start to work on X, yesterday I did Z and I need some help on Y.

The thing with dailies is not that you share your updates, its more that you’re forced to listen to everyone else’s.

Granted you can always snooze a bit and pretend, but that kind of bad faith is usually indicative of other deeper problems with the team.

Also this can become a drag if you’re “held accountable” rather than “helped in need” but smart leaders would recognize that and attempt to fix the problem in the team, and a daily like that can be a tool for them to diagnose problems like this.

> you’re forced to listen to everyone else’s.

This seems to be an overlooked aspect here in the comments too. Yes, nobody likes to be forced to do something but in this case it's worth it. We have enough distractions as it is so taking 15 minutes to focus on what's important to our colleagues can bring forth valuable connections of ideas and people.

Face to face communication, and thus listening to others, is the whole point of the daily scrum.

Regular updates on the bug/task tracking systems together with notification and Q&A on a more stream based async system like Slack work well for us. Lack of activity is usually a sign of an issue, usually someone being stuck, a bit down or on a roll. All need a check-in, even the on-a-roll person as sometimes they get carried away without letting people know about changes. We tend to have weekly in-person synchronisations meetings.

This does really vary hugely from team to team and even project to project though. I fear "agile" methods have forgotten the meaning of the word they are based on at times. Regular re-factoring also applies to development and operational models I find.

The point of a stand up is to get everyone face to face to enable quick interactions and collaboration, and to do so in a very lightweight way.

Doing it as you suggest is simply doing daily update reports and negates the point of a daily scrum.

I feel often Agile principles are taken as buzzwords without really trying to understand the point. Now, whether the point works for you and your team is another question.

As so many things with scrum, a lot depends on the attitude of the scum master. If the scrum master is an ambitions person and focusing on results, stand-up meetings can be become a drag. If however, the scrum master has a focus on the team and it members, it can become a source of cooperation and encouragement. Many companies that want to implement scrum, do not want to pay the cost of hiring people who are good at being scrum masters (and are not necessary software engineers), but decide to assign the role to some existing people in the company, which, often results in people who see it is a stepping stone to a management position to opt for the role of scrum master.

I agree with the importance of Scrum Master in the meeting but from a different perspective. Without a dedicated Scrum Master the meetings often feel either flat or take an off-topic life of their own. I believe that sort of communication is also important but should then be done outside of the Daily.

I see the value in daily communication and the general topics (yesterday, today, blockers) of the dailies, but at the same time the daily standups show how the in general much of the modern work and communication has moved to asynchronous methods but the text book example still requires the events to happen in a synchronous way (eg. standup at 9 am) which obviously causes issues.

Then you move forward to move say the dailies in Slack, at which point they just get posted whenever people see fit, which sort of works unless the problems themselves need to be solved synchronously, as it is with many cases and they easily just end up being status reports instead of actual planning.


I know you're being facetious but basically yes. Some developers are great at working together and communicating with no formal structure in place. I have found over my career that maybe 50% of developers are absolutely appalling at doing so, and prefer to continue stumbling round in the dark. This applies even to developers who are reasonably technically competent. For these people, the enforced daily standup solves that problem.

You joke, but the "engineers engineer until ready don't break flow" trope is one of the most dangerous things that can happen to a project which is why putting emphasis on _daily_ communication (not just communication) is kinda important.

Don't lemmings turn round when they hit a wall?

You're thinking of a Rhoomba :P

I think they're absolutely worth it. The interruption of flow is minor, because they're predictable. You can plan around them. If you're working on something really complex and urgent, I don't mind if you skip it occasionally (but don't make that a habit).

I think it's good to start the day together, with some idea of what everybody is working on. It helps to detect some issues that otherwise might be ignored or detected too late. Generally, communication is good, and short communication is better.

Yeah, nothing worse than finding out that someone has implemented something that you've already done somewhere else because you didn't know it was being worked on.

Short is definitely good as is the chance to chip in a bit of unsolicited advice from one dev to another ;-)

I haven't found a way to make daily standups work in my team which is fully remote and spread out on 3 continents and 4 time zones (so there is no "start of day"). Instead I have a weekly sync with everyone and 1:1 with each person on a weekly basis.

Kanban board gets reviewed weekly for assignment and direction (and I keep an eye on it thoughout the week). Blockers get addressed asynchronously in dedicated discussion spaces as soon as they arise. If a solution isn't found in chat then it becomes a topic on the sync meeting. But generally, there's no "spinning wheels" as everyone is mature and doesn't need a short leash.

Which leads me to trust. Everyone in our team has a decent amount of experience. They all know when they are stuck and they all know where to ask for help. I've always felt that trust is empowering and that's what I wish for everyone on my team.

But in this context, 1:1 are very important and I try my best to make them safe spaces for people to bring up issues which would be more uncomfortable to bring up in a group setting, especially for introvert personalities.

Ideally, pick what works best for YOUR team. Experiment and try new things. What works today may not be the right thing in a year. These are tools, not dogmas. The worst process is the one everyone follows but nobody knows why nor how/if it helps.

Yes, they do but it depends on the context. In my previous company (web agency) they were solving several issues at the same time:

- Project Manager (Proxy Product Owner) is communicating with the client on a daily basis and is getting some important updates about the progress of the Sprint;

- if there are some unexpected developments (for example, some User Stories appeared to be more complex) the Team and the PO can make a decision about it together, discuss various options, etc;

- the distributed team has a chance to see each other (we were encouraging video calls via Google Meet).

However, there are some certain rules which should be followed in order to make Daily Scrums effective:

- video (or at least audio) conferences for distributed teams – it can actually be slower to have this meeting via Slack;

- they must be timeboxed (15 minutes max);

- stay pragmatic about what you are discussing and ask the feedback of your team about it.

In my experience, daily scrums are without value. A well-functioning team already knows what everyone else is working on, what problems they're having, and etc.

If a team isn't well-functioning, then daily scrums could have some value -- but I think a better approach would be to fix the team.

When I was put in charge of a new team for a new project at my previous company, we did the most agile thing there is. We got together and asked ourselves (all of us having previously been on teams that had daily standups): "So, what do you all think, is the daily standup worth it? No? Alright, let's try without it."

It worked great. We ended up doing a quick meetings 1-2 times a week to sync-up and get the idea of where we are. Any blockers would be brought up informally (through Slack or in-person). We all knew each other well, so trust was high to begin with. Also, it was a relatively small team of 5 people.

I guess the point is that "having daily standups" is not agile. Regularly asking yourselves if they are or would be useful (whatever the answer may be) is.

Every article:

Title: Is [x] better than [y]?

Article: Depends on context

Well, isn't this how the world works? If yes, then x. If not, then y. I'm happy to live in a non-binary world.

For a small remote company like ours, it would be exhausting to do daily scrum meetings. Instead, we have an hour-long weekly scrum meeting on Monday and it's more effective.

Can you give a little more context about why it would become exhausting for remote workers? I'd seen terrible stand ups and good ones, but the location of those taking part has rarely been a deciding factor.

It is a waste of time. Whatever you need to discuss regarding the tasks can be discussed once a week and then once the tasks have been assigned and discussed, trust the team to work at their own pace and time and deliver it by next Monday instead of micromanaging the team every day.

But why is that especially exhausting for remote workers? Why not local ones too?

You also foucs on assigned tasks rather than a team working together to get stuff done. Sounds like Software engineers, not product engineers. If you are pre assigning tasks and working separately then yes a daily scrum has no value.

But that isn't the point of a daily scrum, or scrum/agile at all. The focus needs to be on getting value to a customer together as fast as possible - not individuals doing a task each to build to a pre-defined whole. Iteration not increments.



i loved the dailies. it was the best way to earn money without doing any work. i always tried to prolong the meetings as much as possible. ah, i miss those days.


Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact