Hacker News Reader

Comment by vfc1 | Hacker News Reader

I've worked in many teams that used standups, the general feeling was that they were utterly useless.

Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.

I even saw once a developer on his last day throwing the speaker's token (a teddy bear) to the trash can LOL!

Everyone on the teams I worked on seemed to think that standups where useless, this showed clearly through the team body language and tone in those meetings.

Its an interruption on your work just when you just got started in the morning, now you have to stop and go to a meeting.

What people are working on is usually unrelated and of no interest to each other, and if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that.

It's hard to come up with different things to say on the meetings, as there aren't many things that have changed since yesterday.

View on HN

Back when I first started doing daily standups at jobs almost 20 years ago -- when agile/xp was first starting to buzz -- it honestly felt like a breath of fresh air and explicitly something that management would _not_ want. Quick, informal, brief checkpoint with your coworkers, then back to work. We had a group of almost 20 engineers & QA people in a circle, but it went quickly and inobtrusively... nobody spoke for more than a few seconds. We all knew what everyone else was doing, and could go offline and have a discussion afterwards if necessary.

It was a meeting for ourselves, not for management. There were no status reports to management, no gantt charts, no percentage estimates of completion, etc. Just: here's what I'm doing/not doing.

Fast forward a decade or two and I've seen good and bad use of this meeting form. But I still think it's a good idea, it just requires discipline to stop people from hogging air space or veering off into tangents.

"It was a meeting for ourselves, not for management. There were no status reports to management, no gantt charts, no percentage estimates of completion, etc. Just: here's what I'm doing/not doing."

That's my understanding of what a standup is supposed to be, and it's what my experience of them has been. THIS is useful. It's in particular useful if you have devs on the team who tend to get kinda "wound around the axle" on problems rather than speak up or seek help.

There will always be devs who think any meeting is by definition a waste of time, and you can't make those people happy, but a true brief standup meeting as described here is SUPER useful.

(Daily's probably too much though.)

Like many things, if it works for you and doesn't turn negative, then that's great and more power too you.

Personally, when I lead a team, I keep abreast of what people are working on and ask them if they need help, or tell one of the more suited senior guys to offer a hand if it's an area I can't easily help in.

I imagine the standup helps more when you're lead is a non-technical scrum master guy who doesn't have much of a personal relationship with the team.

On the latter point I typically buy my team members fancy coffees and the occasional lunch, and it's easy to get on with them if you care about their careers, so I've never needed a standup.

That's the point: the stand up is for the team, not the manager. She/he should stay out of it.

That's a difficult argument? Is the manager not part of the team? Depends on the org, I guess.

Either way, I'm not so sure the statement means much. The point of agile is to do what's helps, so if a standup is useful for the above reasons, it's entirly possible that another approach solves the same problem, negating the need for the standup.

Not every group interaction requires every member of the group, not sure what's hard to grasp about that.

The manager has plenty of other ways to gather status updates and feedback as you note.

> not sure what's hard to grasp about that.

Your tone is slightly rude considering you're essentially agreeing with me.

You'll need to note the entire thread for the context of my discussion. I was specifically saying a good tech lead and other senior engineers can help engineers get unstuck without actually necessitating a standup.

For me, standups are fine if the team actually want to do them and find them useful, but 9 times out of 10 they're enforced by someone non-technical and require the entire team listen to people drone on justifying what they did yesterday.

Personally, I find the assumption that I can't communicate with fellow engineers without such a thing pretty insulting, but do understand that some of us do struggle with this thing, so it's different strokes for different folks.

It definitely depends on the structure of the org. But I do make a distinction between management and team lead. On some teams the management is technical and involved in daily tasks. In others, less so.

But the key thing is that the daily standup is NOT a status report for management! That should not be its purpose! It is for the team members to sync with each other, not a daily report for task management.

I don't disagree and for the record I'm an engineer. I don't think my points are actually counter to yours. :)

Yea, the minute the managers stick their beaks in the whole vibe turns sour

I seem to remember a time when standups did not necessarily involve the product owner. I feel like a lot of things have changed in Scrum that have progressively brought more of management into its ceremonies in ways that have actually disrupted a lot of the early goals of the process.

Interesting, yeah, we were doing something closer XP, not Scrum. I've never done Scrum. Haven't done "agile" in the last 10 years, as it's not really a thing where I work now.

But yes, in XP, the 'customer' or 'product owner' would not attend a daily standup. The purpose of the meeting was for developers to sync and maintain velocity and social and work cohesion.

Meeting with customer/PM was something that happened at the end or start of iteration.

What use is knowing what 20 other people are doing today? Are you interacting with all of them? Interesting to know what projects they're working on, but I can be told that once a month if I haven't already got that while chatting to them at the coffee machine. A 20 person meeting for each to speak for a few seconds is to me very theatrical - drop a sentence in a chatroom. If I'm not working directly with you I'm not going to read it, nor listen to you in a stand-up.

In an 'agile' process people should only be working on any particular 'story' for 3-5 day period. Everyone on the team should be interested in what they other people are doing, because they may in turn be pulled into work on some part of it next. In a healthy team everyone should be invested in the success of the product, and have some knowledge of most aspects.

Frankly, once things scale beyond that, where you have large teams of people disinterested in what's happening beyond their choice of specialization -- "agile" starts to not be a good match anymore.

> What people are working on is usually unrelated and of no interest to each other

I think this is the key difference between teams that like stand-ups and teams that don't. In the teams I've worked in, our work was highly relevant to one another, so knowing daily where everyone was with their tasks is usually interesting to everyone.

I second that. I've founf that when the work of other people is relevant, you might have some inputs having worked on a related thing earlier that might help them.

But as the article points out, knowing daily where everyone was with their tasks isn't something that needs a formal meeting. I've worked in highly integrated teams, too, and easily got by with one team meeting a week.

Depends on the size of your team. Once you get to 10+ people in a team, it's hard to spread information effectively with 1:1 communication. What I've liked about standups in teams of that size is the opportunity to kick of unexpected brainstorming because you mention what you're working on and someone mentions they have expertise/ideas in the area that you didn't know about.

There are of course many ways to run a productive team.

On the other hand, the Scrum Guide[1] recommends that teams have 3-9 people in them, and that more leads to poor coordination. Seems like an inverse "Goldilocks problem", Scrum standups are best when there are more than 10 people and less than 10 people in the team.

[1] https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum... - page 7

I am absolutely not a believer in anyone who talks about agile techniques as having 'Rules'. That is a trademark of agile gone wrong to me.

Small teams are better, but not always possible. Agile is about having team mechanics that make your specific team more productive and changing them as your team changes.

That aligns with my experiences, we aimed for 6, with a max of 8, with a min of 4.

I will say, Scrum was really helpful for us, but only because we took "iterate on your process" seriously, and had a culture where teams could experiment with their process.

In the end we outgrew it, but Scrum helped us reach the point where we could do so.

What’s the point of knowing what the rest of 10 people are working on? You won’t remember all of it anyway. There is no need to add so much cognitive load to your brain every single morning. Engineers should imho start their day with clear mind.

To give ideas based on your experience. To raise questions that might not have been considered. To build a team instead of a collection of independent cogs. To know what expertise your teammates have so you know who to go to with a question in the future.

It really shouldn't be much cognitive load to listen to what other people are working on for 10 minutes. If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.

You can either have 15 minute quick standup or you can have a meeting to give ideas, raise questions and know my teammate's expertise.

> If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.

Or maybe the problems other people are working on will take more than 10 minutes for any reasonable input.

IMO standup shouldn't be where the conversation takes place, it's where the conversation starts, to be picked up after standup/in a separate meeting.

Bingo - the whole idea of any meetings before lunch is absurd. Your brain does 90% of its best thinking between wake up and lunch... why waste that on meetings? Sorry for the sidebar... I’m loving this thread. I’ve been telling my wife for years that daily huddles are a scam that manipulative management types do “to maintain momentum” or the appearance of it at least.

In our experience, scrum teams couldn't scale past 8 members without becoming less effective. The effective communication required for a high performing team suffered, people would tune out in stand-ups etc.

I've done standups (not scrum, just standups) with up to 16 people and it was quite effective. It just required a concerted effort to keep it short.

The nature of the work probably also helped because tasks took a long time so on any given day only a handful of the people would have substantive updates.

In my experience, 10 is way too many for daily standups! Thats when they start getting dragged out from 5 minutes to a 45 minute snore-fest, hearing every little needless detail from someone elses problem that I have no need for!

I find the team needs to be at most 6 people, otherwise you probably need to split the team for daily standups to work.

That wasn't my experience, but it definitely takes an emphasis on brevity to prevent that. We found two techniques that helped with bigger teams:

1. Everyone explicitly has the responsibility to say "this is going too deep, let's continue it outside of standup" when needed.

2. Having a timer visible that resets after each person's update. This makes it clear when one person's update is taking too long. We were able to get rid of the timer once we had the flow down.

Also, it's crucial that everyone on the team feels comfortable saying: "these standups aren't a good use of our time, let's make a change". That's how those techniques were introduced.

How about when your PM who doesn't understand Agile in the slightest combines two 5-10 person teams in a single, painful 3x-weekly standup.

I consult and I've been at places where a 4 person standup take a half hour. Usually then I start telling people "We don't solve problems in stand up."

I've also worked at places where a 20 person standup took < 10 minutes and helpful b/c sometimes someone not on your team will know how to fix your blocker and just help you out afterwards.

I think as long as you have a standup czar or just post your updates to slack, then it's a super useful meeting. If it ever goes over 10 minutes then whoever is running it is just making everyone late for work.

> Depends on the size of your team.

Why does it depend on the size of your team? Teams involved in agile development (where they do the whole daily standup kerfuffle) are supposed to not get to 10+ people. That's like the third thing on the agile coach's slide.

Besides, why does it take a full-team standup to find out someone has expertise and ideas in an area that you didn't know about? Are the lead developers/managers sleeping at their desks? Guiding and bringing people together is one of the things they're paid for. They should know who's good at what, and steer the right people (or the right tasks) towards them. If they aren't doing their job, what the team needs is people who do, not one more thing that developers have to figure out on their own time.

As for brainstorming -- it shouldn't be unexpected in the first place. Not on a regular basis, anyway. If a developer needs that brainstorming session, they should have the means to make it happen, with only the interested people attending. If they need it, but don't know they need it -- especially common, and especially excusable for junior developers -- that's why we have lead developers and managers.

And meetings are not the only way to spread information! If a team has 10, 15 members or more and it's spreading information by word of mouth alone, whether 1:1 or in meetings, that's already a problem. At that point you should have things documented. New members should have an M that they can RTF and ask experienced team members about. If a team got to that size and the only way to spread information is in person, that's something they should remedy, not keep doing!

Lead developers and managers can't keep track of all the minutae that people have worked on in their careers.

For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software. But if I mention that in standup, it will immediately be clear if anyone has expertise that is valuable.

I've never seen a high performing team that didn't regularly have ad-hoc brainstorming sessions (i.e. you say what you are planning to do and someone says "have you considered this"). Like I said, there are many runs to run a productive team, but standup can be a good place to start that discussion.

> Lead developers and managers can't keep track of all the minutae that people have worked on in their careers.

Keeping track of people's skills and expertise is part of their job description. If they don't, how are they going to help them develop and steer their careers? Not knowing every single thing they've worked on is one thing, but knowing (as in your example) who is likely to have used that piece of software, or who has experience troubleshooting performance problems involving that piece of software's functionality, is definitely their responsibility.

> For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software.

Certainly -- but that doesn't justify having a stand-up meeting every day. It's not realistic for managers/lead devs to know if anyone on the team experience with a particular piece of software, but it is realistic for them -- or for any developer, for that matter -- to be able to find that out without dragging everyone from their desks for half an hour or more.

It's a matter of effort for reward. I get the sense from you that you find standups to be miserable so any way to get rid of them is worthwhile, even if it's less efficient (and having managers/lead developers track who is working on what specific piece of software and organize conversations to make sure the right people are talking to each other is not efficient).

In my experience, standup has almost no cost and is generally enjoyable - people typically like talking about what they are doing and getting thoughts/advice. But if your standups are "half an hour or more", they clearly don't have much in common with the standups I've done. I would propose that maybe the problem is your standups are poorly run, not that the concept itself is bad.

I find stand-ups pretty fun, too, but that's all -- and it's definitely not an experience that everyone finds enjoyable. We all like to talk about what we're doing. Some of us, myself included, gladly jump at every chance to do it, including stand-ups. Others, though, see the whole standup thing in terms that are closer to herding people into a meeting room and prodding them until they start talking.

As for timing: if you have a 10- or 15-people team, allowing for even just two minutes per person -- which is barely enough to cover a non-trivial problem -- easily gets you to 20-30 minutes. It gets shorter if all updates are in the form of "no news is good news", but then the meeting could have just as easily been an email. It also gets shorter if the problems really are so trivial that fifteen people can describe all of them, and their solutions, in a couple of sentences, so that no one talks for more than 30 seconds -- but then are these problems really so big that you need to hold a meeting that everyone attends, every single day?

I don't think the concept itself is bad -- just that the arguments for efficiency aren't convincing when it comes to large teams. I doubt that you can really disseminate useful information in this format, and even if you could, there are way more efficient ways to do that.

Edit: If these meetings are held just to make sure all updates are given regularly, often, and in the open, with all the consequences this has (good ones, like everyone being on the same page, and bad ones, like opportunistic managers taking the chance to use this as a way to pressure their team), that's great, but let's be frank and admit it.

With the amount of churn that there is in a lot of companies, it's unreasonable to expect anyone to do much of anything except bail water and try to keep things going within a handful of compass points of the correct direction.

My company is blessedly stable, but for instance at my wife's employer, there are teams that have had 300% turnover in the two years she has been there.

I think this kind of endless short-term firefighting is part and parcel with the micromanagement that daily standups embody. When nobody actually has any experience, or built any trust over time, the whip lays on heavier to keep people in line and pulling in the same direction.

If your "standup" is half an hour or more, it's not a standup, it's a status meeting that your org just happens to call a "standup".

A real scottish standup is a few minutes -- 5 or 10 minutes. 15 max if there are lots of people and lots of things to cover.

This was all in the context of large teams, larger than the Agile methodology recommends.

How much useful stuff do you think a developer can fit in 20 seconds of speech -- which is about all they get if you want to fit a 15-people meeting in a ten-minute timeslot?

Once a team grows past a certain size, either you keep the discourse substantial -- and end up with 30-minute meetings -- or you cut everyone short, and end up with ten minutes of smiling and saying the right buzzwords.

> How much useful stuff do you think a developer can fit in 20 seconds of speech

1. What did you do yesterday?

2. What are you doing today?

3. Any blockers?

I second the above comment, this is indeed the difference between a team and what shouldn't be a team. If people at a standup are talking about unrelated things then they indeed shouldn't be having standups, much less be considered a team in the first place. What's happening in standups and probably other meetings are symptoms of a structural issue people are either not seeing or failing address.

My rule of thumb for assessing a team is based on two simple questions: 1. Do people in the team work towards the same goal? 2. Do people in the team depend on each other? If the response to both questions is positive then by all means, have standups. In other cases, have a good look at whether it makes sense to call them a team in the first place.

unrelated is relative. If I'm working on bug A and bob id working on bug B, I don't give a shit that bob is having to go talk to cathy in accounting about something.

They're unrelated tasks because there are no dependencies between them, and there is absolutely no reason why I should have to sit through bob talking about his day.

But the point of these, at least to me, is that someone on the team may know a way to get the problem solved without talking to Cathy in accounting. Sure, sometimes you listen to unrelated tasks, but many times (in my experience), somebody on the team can offer a bit of advice that helps everyone move faster.

EDIT: Spelling.

and now the "standup" has devolved to a design session, and I don't want to have to stand there while bob and betty have a discussion about it.

It certainly can. We try to take those types of discussions offline though--Bob and Betty can have that talk after the standup.

And to clarify, I also find daily standups to be tedious and generally unhelpful. Once or twice a week seems to be the sweet spot (for me/my team).

right, Bob and Betty can have that discussion elsewhere. all of it. We don't need a standup for Bob and Betty to figure out they need to have that discussion.

The point of the standup is to figure out you need that design session, not to conduct it then and there.

Take ownership of the standup, don't just passively sit there and then complain afterwards what a waste of time it is.

> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.

I haven't ever felt this kind of pressure from management in my stand ups. We very rarely have anyone from management present anyway. The stand up exists for the benefit of the team, not management. It is not a status report for management.

A lot of HN commenters have a tendency to project what ever experience they have with poor management onto all management in general. Poorly run teams have problems, poorly run projects have problems, poorly designed apps have problems... But well runs teams exist, and they use a lot of the same management tools as the bad ones. I’ve had both great and terrible experiences with standups. In a well run team, I love them. But in a poorly run team, getting frustrated with the idea of standup is about is misguided as getting upset with Jira for your managers shortcomings.

It is a status report in companies doing "Scrum" - usually after CTO paid an Agile-with-a-capital-A consultant.

I've been a bit of volunteer agile coaching in my area, and yeah, one example that always stuck with me was that the product managers and BAs just got renamed product owners, and they sat in every retro and attended every stand-up.

Funnily enough they were never available to the team during planning. They had important meetings on a Monday...

I tried to empathise to them that "stand-up and retro are solely for the team", but no dice. They still wanted that command and control.

For some people, the manager-employee relationship is a strictly adversarial one, to the point that they make it a self-fulfilling prophecy by viewing every act of their manager (or employees) as malicious if not a perceived slight.

We started just doing our daily "standups" via slack. The whole point (imo) of the meeting is to identify blockers and/or slowdowns for what you're working on, and getting help if necessary. Reporting this status async over slack is great because it fulfills these needs without wasting anyone's time.

If you need help or are block, you report that. Otherwise, no need for a "status update". It also helps that we do this in our eng-only channel, where no product/upper management are in, so only our team is privy to the information.

The one downside is that it can be a bit more difficult to get help on something highly important if everyone is tunnel-visioned. Luckily, we have a great engineering manager who helps orchestrate help in those situations or steps in personally if someone is blocked.

> What people are working on is usually unrelated and of no interest to each other

If that is the case, then why are you even in the same scrum team? What you have there is not a team by the sounds of it.

> "It's hard to come up with different things to say on the meetings, as there aren't many things that have changed since yesterday."

If you're still working on the same issue, then just say that. Keep the standup short. Of course this can also be a good time to notice a lack of progress; if you're spending days on an issue with little progress, are you stuck? Was the story badly defined? There could be very good reasons why it's taking longer, but again, the standup is a great time to notice these things and check if there's a way to help the issue along.

This just sounds like a bad/inappropriate use of a tool. I wouldn't think that a team of people working on unconnected items should have any meetings at all, let alone a daily stand-up.

As others have said, when you're working on a team where there is significant interplay or varied, related experience, they're really useful. We work on an OS and have members of the team who happen to have experience using infra and tooling. There's no way you would necessarily know this without saying "Oh, I was struggling with this bit of stats collection infra" and somebody else says "Yeah, I worked on that on x project, y years ago. Let's chat after stand-up."

There are obviously other ways to seed this kind of thing, but brief stand-ups seem a good way of doing it.

The other thing that we tend to do is just say "Oh, I did x that doesn't really relate to the project yesterday, but that's not very interesting" and leave it at that.

> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.

Spot on. In many companies standup are used to put people on the spot and pressuring them to show progress and so on.

It's amazing how many people on HN don't realize that.

> It's hard to come up with different things to say on the meetings, as there aren't many things that have changed since yesterday.

If you can't find something to say for a minute about a day's worth of work then you probably need to be rethinking how you're spending your days.

> Its an interruption on your work just when you just got started in the morning, now you have to stop and go to a meeting.

> if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that.

I thought part of the reasoning for standups was to synchronize your interruptions, so instead of breaking people's flow throughout the day, you can line up all the cross-cutting concerns at the beginning of the day.

"What people are working on is usually unrelated and of no interest to each other,"

It sounds like you are not a team in the sense of a coherent body creating added value, but a line organization mandated agglomeration of talent under a specific manager.

When actually working together quick stand ups make sense, but for individual contributors they add very little added value.

However, the only way to know if the dailys are unnecessary or not, is not how they feel like, but what happens when you remove them.

All coordination work feels unproductive. But after a specific complexity is reached coordinated efforts of communication are the only way in which a large body of talent can function in a sensible way together.

when really working together, standups are superfluous.

I’ve seen standups with 20 people where 2 or 3 talked for more than 10 minutes. That’s not what it’s meant to be.

While I would also like to do the daily status email, I see value in doing a synchronized standup. It helps planning for the day.

Not all people are great communicators and I’ve seen lots of developers spend days on tasks which should take 1 or 2 hours max. Standups highlight these issues, but you need to listen and go to these people in private to understand their problems. And you should absolutely take up people if they offer to help you.

I tend to bring pen and paper to remember what I wanted to say and to note when I here something that’s relevant to me.

Standups with more than 6 people will already create a meeting of at least an hour. I mean, standups help is small teams to keep everyone excited (if you all agree on it!), and nobody likes meetings, so if it looks like a meeting and people need a 'token' to speak, then the point of the get-together is already far gone.

Why not join the meetup with afterwork drinks? That way you can really say what blocked you ánd talk about the things that you'd do in a standup...

Why not join the meetup with afterwork drinks?

Mandatory after work 'fun' can be highly controversial.

> Why not join the meetup with afterwork drinks?

That excludes certain segments of your workforce in ways that make HR sweat. Parents, alcoholics, people of faith... you've made attending the meetup more difficult.

So the way to fix dysfunctional meetings is not to split them into manageable sizes, but rather shift them into some sort of impromptu unpaid overtime, and bribe your staff with alcohol in hopes that they won't notice?

> Standups with more than 6 people will already create a meeting of at least an hour.

Not my experience, teams of that size I’ve been on do standup in 10-15 minutes.

> I’ve seen standups with 20 people where 2 or 3 talked for more than 10 minutes.

Did the scrum master not feel able to intercede? Protect the process etc.

The scrum master shouldn't exist.

I agree, when the team is working, everyone's a scrum master :)

Its highly dependent on personality of course, but Ive also seen this. A person that REALLY likes to talk for 10 minutes about details... which nobody really cares about. He even understood that it was not what anyone else wanted, but he thought "the standup is useless unless I get to say something elaborate and long-winded!"

He could not understand that "I had not trouble yesterday, and today I will keep going on my task" could be a useful update to the team. I mean, in general it isn't but when something unexpexcted happens you are supposed to say it, not something unique for every day. 90% of my dailies are basically: "I am still working on X, and its moving forward, continuing today".

I commented on another post a while ago that the simplest way to "do Agile right" is to give the developers more power. There's just no other way. Whether that means: ownership, reporting direction, I don't know, but people can feel it, power is power.

I don't mean to imply this is a panacea. "Doing Agile right" is one thing, but business is about more than software development, and an engineering-led organization can of course ignore financial or marketing realities.

But there's an expertise-for-the-job phenom going here. Managing software development is a skill. It requires "navigating ambiguity," that favorite phrase of managers. It requires being able to expect and roll with punches, and chart a new course---every few minutes to every few months, depending on the context.

I suspect the best thing would be for boards to take a more active interest in their company's SD activities. Bring the CTO in, figure out the tech landscape the company is confronting. "Giving devs more power" is probably a no-sell, but "boards taking software seriously" might fly. And when you do that, you unavoidably become the devs who already have power.

I know, a digression, sorry. But it's just night-and-day, the diff between technical and non-technical management.

> I even saw once a developer on his last day throwing the speaker's token (a teddy bear) to the trash can LOL!

Are we talking adult employees here? :D Anyway, if I ever become employed, and will have to work on-site, I want the comfort token to be a stuffed baby gnu.

https://shop.fsf.org/gear/stuffed-baby-gnu

I like that symbolism - it's the optimism of the open source community being soiled, manhandled, and molested all in an effort to please management.

"What people are working on is usually unrelated and of no interest to each other, and if you need help you ask it anyway on the spot, there is no need to wait for the next standup for that."

Exactly this... I couldn't care less what dev-no-3 is working on since its not impacting me and I could bet no one cared much what I said except the scrum-master.

I wonder if an end-of day stand-up might have benefits.

A chance to briefly set out any blockers you anticipate for tomorrow/stuff you will need from other people.

But just as important; an end of day marker 'we're done - piss off home now - no working late'.

I feel that end of day is more variable than start of day, especially if end of day means "Go Home!". Some people have kids to pick up from school/day care and leave at 3, while others like to come in later and/or take a long lunch and work until 6-7. Saying everybody must be in by 9.30 is probably easier to coordinate that saying everybody must stay until 5 and then go home at 5.15.

I've done both and I personally prefer beginning of day. Standups are usually (in my experience) the beginning of a conversation or a brainstorm and that works better when there is time left to continue after standup. If they are just reporting what you did then end of day might be better, but that sounds like a bad standup.

I worked in a Boston based team from Budapest. I did EOD standups all the time. It was nice I did not have a hard time remembering what I did during a day. I usually had one hour to short out any blockers before I finished working.

There are just as many issues with that as the beginning of the day, IMO. What constitutes the end of the day, for example? It isn't unusual for teams to have someone who comes in really early and leaves early. Or someone else who comes in late and leaves late.

Early enough for the 6-3 worker might be well before the end of the day for a lot of others.

>> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.

So true. At the last company I worked, the daily standups became absurd. We were forced to use a physical board which was always out of synch with GitHub and we were just repeating the same stuff that we already knew everything about.

Also, we had scrum retrospectives in which the new scrum master was throwing a yellow ball at someone when it was their turn to talk. WTF?! Does management think our brains stopped growing after the age of 5? You have a room filled with potentially brilliant engineers and you're treating them like toddlers. Do they seriously think that this is the right way to build a company which will make an impact on society?

What the hell is wrong with managers these days? Is there some kind of virus going around which is turning them into idiots or is there a global conspiracy to only promote idiots into positions of power?

> Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.

When I was a manager, I always found it to be far more effective to have team members apply psychological pressure to their peers, rather than apply pressure from the top down.

Standups are best avoided by managers. I never felt the need for yet another meeting. In fact, an excessive number meetings are one of the main reasons I got out of the management business.

> Everyone on the teams I worked on seemed to think that standups where useless

It sounds like a bigger a problem then standups; if everyone feels they are useless why is there no forum in which this meeting is being discussed and removed or recalibrated? It sounds like the team doesn't own their own process or doesn't talk to each other about process

Reply on news.ycombinator.com