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.
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.
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.
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.
> 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 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.
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.
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.
> 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.
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.
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.
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.
> "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.
> 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.
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.
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".
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...
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.
"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 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
Don't agree with this assessment at all, we do stand-ups and it rarely takes more than 5 minutes. It help immensely with production as your colleagues often help keep things from falling through the cracks. (I.e. someone forgets something). Or they might be able to help you out, or further along because they've done something similar. When they do, you don't do it during the stand-up to not disrupt that.
Overal I don't think it's disruptive at all to do a short stand-up, constant nagging however is very disruptive. That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again. If you're working on something complex that can mean it takes an additional 10 minutes before you're back on track. That's the kind of disruption stand-ups can help prevent.
This of course only works if you actually stick to what the stand-up is meant for.
It's a bad article. Standups shouldn't be disruptive at all. Just a couple of minutes to get some idea of what everybody is working on. Standups are in my experience much more effective at signalling blocking issues than slack. Nobody is going to spend their day checking what other people are doing on Jira, so the standup is the perfect time to inform everybody efficiently.
If any issues come up, you can discuss them immediately after the standup.
Long meetings are terrible, but short meetings are great. That's the whole idea behind the standup. If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day. It only has a measurable impact on your velocity if you're only a working an hour per day. And even then I'd guess it's useful to have a quick refresher about what you're working on.
It sounds like you and your coworkers are failing to use your tools, and falling back to having a periodic meeting instead of fixing your process.
>Standups are in my experience much more effective at signalling blocking issues than slack.
Your messaging tool is not good enough to communicate urgency? You cannot send a message and say "this is urgent" and have somebody read it and respond in a timely manner? You would have better luck waiting until the next standup meeting?
>Nobody is going to spend their day checking what other people are doing on Jira
Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?
Here's how it works when you use your tools:
1. You have an urgent issue. You message the involved parties. Your message should communicate the urgency of the issue. They read it and respond / take action within an appropriate amount of time.
2. You want to know what your team is working on. You look at your issue tracker to see what everyone is working on. If you are curious about the status of any work in particular, you look at the details for that work. If there is insufficient information about its progress, you send the assignee a message (see #1).
It's not a bad article if it reflects the reality a considerable number of people face with this kind of cargo cult methodology.
A five minute meeting is not five minutes out of your day. Any scheduled interruption takes at least thirty minutes, probably more like sixty, out of productive time, as a flat cost, over and above the actual time of the meeting. It's all the time that you don't start biting into something worth doing because you look at the clock, and say "Oh fuck, I've got this fucking standup meeting in 20 minutes - I can't even get started on this before that rolls around and interrupts me." And it it all the time afterwards where you have had a bunch of shit laid in your lap that you have to spend some time following up on and frigging around with before you can get back to the work you already had planned to do.
You can't put 10 people in a room for a meeting for just a couple of minutes, that does not exist. The time people spend before the meeting not working just chatting around waiting, the natural inertia of the group it takes time to get everyone in a room.
Count the whole overhead time, from the moment people stop working normally waiting for the meeting, till the moment people come back to their seats, add up the extra coffee pause that people take afterwards that people would not usually take.
You are looking on average, at easily 15 to 20 minutes per person minimum a day, probably more.
Perhaps they shouldn't be disruptive, but in practice they were a daily drain. I'd be happy to never go to one again. Now every day I can come in to the office, can grab a coffee and get to work. Far more relaxing.
> Standups shouldn't be disruptive at all. Just a couple of minutes to get some idea of what everybody is working on.
That's disruptive!
> Standups are in my experience much more effective at signalling blocking issues than slack.
If you are using Slack, you have already lost the battle for productivity.
> If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day.
Literally any interruption destroys your focus. A pending appointment destroys your focus. If you use Slack or E-Mail notifications, people never even attain focus, so in that sense it's not a loss.
> And even then I'd guess it's useful to have a quick refresher about what you're working on.
To a first approximation, nobody cares what you're working on. Nobody should care what you're working on. If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work.
Daily standups pre-suppose that there's always stuff to communicate and that everyone is always involved, but only once a day and only briefly. This is complete nonsense. You need to be able to adapt to the situation. You need a meeting? Have a meeting with whoever is concerned. Have a follow-up meeting. Take your time and focus on the issue, then nobody will even feel like time is being wasted.
> Don't agree with this assessment at all, we do stand-ups and it rarely takes more than 5 minutes
I do agree with it, because everywhere I've worked that does a daily standup does it wrong, and I think OA is more about those organisations.
For many old-fashioned companies, "doing agile" means waterfall + standups. Apparently that's all you need to reap that sweet agile-y goodness. The guy running the meeting doesn't enforce any structure, doesn't stop people rambling on for 10 minutes, doesn't try in any way to note or act on the points people raise. It's just about micro-management and cargo-cult development.
I'm sure with the right company a standup is a very useful tool. But wherever I've worked, it's been all about micro-management and a fundamental misunderstanding of what I actually need to do dev work (usually: a quiet office, no interruptions and time).
You are just counting literally the time the first person starts talking till the last person ends, and even then its going to be closer to 10 minutes.
If you add up the time people have stopped working while waiting for the meeting, the time you take to gather people to a room, wait for the last one to arrive, start, go back, it's been 20 minutes total, and when standups derail and people start talking a lot it goes over half an hour.
You need to count the total overhead time. I mean come on, 10 minutes before the standup you are not really working full steam, right? You know you are about to have a meeting, so you are chatting with colleagues and checking email instead of working on your main tasks. That time should count too.
It's not even about the time, either. I do my best work in the morning. Almost every morning on my last project went like this: Get into work, grab a glass of water, bring up my todo list, start polishing off the first item, make 5 minutes of really good progress and the bam, standup.
The comparison isn't between the benefits of a good standup and nothing, it's between a good standup and whatever productivity you lost by interrupting the entire team (same as any meeting). You need to make sure it's worth it.
> 10 minutes before the standup you are not really working full steam, right?
Some colleagues don't 'work' at all between getting to work and standup (opting for soft tasks like email).
Wasting 15 minutes for 5 people a day costs the company almost 6 man-weeks a year, or really a week per person. Providing that week as PTO/leave would probably result in tangible productivity improvements.
What? Every engineering team I've been on has done standups at their office/desk/bullpen. It literally takes exactly the amount of time of talking. Then we sit back down and resume work. You don't have to make it a full blown meeting. In fact, you shouldn't.
Yeah same here. Everywhere I've worked standups have been really beneficial and usually only last about 5 minutes. I think the issue here is maybe the team size and stand ups dragging on for too long?
Agreed. Keep them short and focused. We use ours to review new PRs for the day and new requests that have come in from other parts of the company, in addition to covering blockers.
The PRs cover the “what did you do?” questions while getting eyeballs reviewing the work and for larger PRs we will schedule something. Keeps things moving well.
The inbound requests reviews keep us from having to have backlog estimating meetings as often since we are keeping up with it as they arrive.
If the time isn’t useful, find a way to make it useful.
> That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again.
Walks in? Yes. That should be discouraged always.
Spamming on Slack? If that is a problem, you're doing Slack wrong. It's an asynchronous method of communication. Don't be buried in it or feel the need to respond to every message as it comes in. Check it during natural breaks or stopping points.
If something actually is urgent and requires your immediate attention, then they can break the above rule and walk up to your desk (or call you if you're remote).
Some of my colleagues had a hard time with this. They would actually ask me to come to their desk whenever I had a question, and come to mine when I didn't answer fast enough (only after I had gotten them to understand I really preferred slack. Seems they never got the why though, despite making it very clear...)
> This of course only works if you actually stick to what the stand-up is meant for.
This is my big problem with agile, scrum, and friends. It's like communism; it only works if you "do it correctly." Russia? China? Cuba? Yea, they didn't do it right, but if it's done right, it's really really great.
I have only ever read about agile and scrum being done correctly. Obviously, I'm just one person, and my experience is limited, but at every company have I ever worked at or consulted for, the practice of agile and scrum is very different than what I read about.
I have experienced the less than 10 minute standup maybe a dozen times ever. Not that there is usually much to talk about. "Yesterday I worked on on X. Today I will keep working on X."
But somehow enough people in one place just seems to create so much friction. There's always a tangent. A: "By the way, how long do you think until we finish X?" B: "I don't know. Kind of depends on Y and Z. I never did Y before." C: "Oh, I did Y before, it's easy, you'll have no difficulties" and on and on.
I can see two possibilities:
1) My experiences have been not been representative of the industry as a whole. On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
2) My experiences are representative. In this case, agile/scrum is so difficult for the average company to pull off, that it's kind of a rare occurrence.
The fact that angst-ridden articles like this one are such a regular occurrence on HN kind of makes me suspect that it's #2, not #1.
I'm just an engineer, so project management is not my area of expertise, but my layman's opinion is that an actually good project management system should "fail gracefully," as it were. You shouldn't need a 1 in 1000 level PM to pull this stuff off.
> On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
Not a chance -- your experience mirrors mine over the course of the six or so companies that I've worked for. It's definitely #2.
They all fail in very similar ways: story points become hours/days; stand-ups devolve from status updates to daily team discussions; the backlog becomes irrelevant because new stories are created for each sprint; and, in companies which report velocity to senior management, story-point inflation.
Also, I've noticed that Agile transformations always create Agile zealots within the organization which seem to act to quell dissent. I'm not sure why this is, maybe the transformations are tied to bonuses or something, but it's a universal thing. There's always somebody running around telling you that you're team is Doing It Wrong when you bring up any legitimate criticisms of the process.
See:
> It's like communism; it only works if you "do it correctly."
“It help immensely with production as your colleagues often help keep things from falling through the cracks.”
But your job as a developer is to not have this happen. It’s nothing something that would be a nice to have, you’re supposed to always keep your team informed about potential gaps. The standup is designed to catch gaps but really that should be something you should already be doing.
Daily standups are often a panopticon for those who mine story points and their wardens that micro manage them. Anyone not coding (RE, BA, managers of any kind) usually don't need to justify their contributions to the team. It fits extremely well in the story point driven "agile" world where working on stuff that does not provide immediate business value, like code quality and technical debt, is highly discouraged.
I have seen so many dysfunctional standup cultures: Places where you had to showcase and exaggerate how much stuff you had to do and people were looking at you funnily when you said what you are doing in under a minute, places where discussion that only interested a third of the team were started and standups took half an hour, places where the managers interrupted and asked why stories took so long...
I’ve worked at two of the FAANGs, and some of my teams had daily stand ups and some didn’t. Some teams had stand ups but didn’t track points or velocity of any kind. Others did.
When we were working to disambiguate deliverables or working on design or implementation, stand ups were useful. They held everyone accountable, when folks weren’t making progress because of some issue, it was super obvious - it gave management a really good insight into where things are and what blockers are.
Your characterization certainly doesn’t represent my experience. We went through phases of launching a products or services and focusing on them and then going back to pay off some of the tech debt until product management, engineers, and leadership arrived on the next set of big features.
"The panopticon is a type of institutional building and a system of control designed by the English philosopher Jeremy Bentham in the 18th century...[It] allows all prisoners of an institution to be observed by a single security guard, without the inmates being able to tell whether they are being watched."
Standups hurt more than help. As someone who managed fully remote teams in the past, what worked very well for us is a set of rules around in-house built task management system (something like Jira could work too).
1) Aim to take 2-3 tasks, do not take more, take 1 if the task is large, but usually, it's a sign of an overblown story.
2) Every day at the end of the day, write a "current status" comment. These comments are visible in the master panel, and I could take action the next day to help developers resolve roadblocks, if the resolution is taking longer, they can work on other tasks they claimed.
This effectively eliminated the need for standups, the whole team could sync using task "current status" updates, and chime in with help or advice. I was able to see the progress and issues without forcing people into a mess of a video call, and everybody could still stick to their preferred schedules and have personal lives.
This is my preferred method as well when leading a team.
Standups as intended are too brief to discuss the important details. This is why they end up ballooning to 30+ minutes at most companies, because anything shorter is of little value.
They also end up as a catch-all meeting for any topics that require the team's input; I dislike this because people are expected to provide input on the spot without really making any thoughtful considerations. If we want to have a discussion on a UI component, that should be done in a dedicated, prepared meeting, not at 8:30 in the morning when people are unprepared and said developer can take advantage of unpreparedness to obtain the consensus they want.
When I provide up-stream status reports, I like to have the developer's notes in front of me for a quick refresher. Plus, they serve as a good reminder on topics that need followup.
Ours take 10 minutes, we use them to update people on how our work item is going (e.g. if smth is taking longer than expected) and specifically to give a sense of citizenship and culture. Otherwise we might as well remote in from various corners of the globe in shadowy rooms and talk using voice modulators. Sure, not everyone works like that but I personally like to put names to faces and gain a sense of personality behind the names in a git blame.
If you don't value those things then just be low key in your input, its literally 10 minutes of your day and has the potential to present an avoidable issue. To discard it as "management trash" is IMO a massive amount of disrespect toward your fellow team members. They can help and the stand-up opens opportunities for help. There's design work, review work, product management work, scheduling, triage, retrospectives. There's ample opportunities for efficiency gains in these areas during a stand-up outside of just writing code. If you think your job is just writing code then I can see how you might think they're useless but nobody's job is, we all work in teams.
Even if the meeting itself was instant it would take more than 10 minutes. You would have to stop whatever you're working on, even if you're in the middle of a valuable flow state. Then after the meeting you have to get back into whatever it was, which alone can take you more than 10 minutes depending on the depth of your work.
If that's not bad enough then what you talked about in the meeting can also linger. You'll think of problems others have had and it causes your mind to lose focus, now you have thoughts about your problem mixed with other problems. These meetings also tend to happen during the mornings, smack in the middle of the most productive hours of the day.
No, a daily standup takes much more time than 10 minutes.
Your job is more than just code. Your job is other people too. Live in a box all you like but you're completely discounting the value of ensuring other members of the team know what's going on with you over your current work item.
FWIW, imagine how a greenhorn might feel working on a team with you. If you feel like giving them some time of your day is a waste or that listening to their problems is a waste they're not going to feel enthused working on your team. Sure, that doesn't necessarily influence your current work item but it might contribute to overwork later if they leave for a team that actually makes them feel like they matter.
Breaking my state of flow is also something I don’t like about stand ups. And yes, they tend to be in the morning when I have my most productive hours.
One solution I found is to write a quick status in the chat and excuse myself from the stand up.
Sometimes I finish 20 minutes before the stand up and think about what to do next. I usually won’t go into deep work but plan something, write my todo list on paper or review some PR to make use of the amount of time that’s to small to get into flow.
You should be able to figure out a good daily time for your team that doesn't involve breaking out of the middle of a flow state. Maybe when everyone is expected to be in the office, or even right after lunch?
Literally, it's not 10 minutes. Count the time that you have stopped working and people are chatting waiting for the meeting, checking their email when they would not otherwise do so, not working on their main tasks.
20 minutes to half an hour of time not usable for main tasks is a more typical estimate.
In an ideal world everyone would be perfectly professional and not need any supervision at all. In the real world some times you might be in a rough period or have some other problem that makes concentrating hard. In an ideal world the thought of getting a paycheck would be enough motivation. Sometimes it isn't.
A daily standup, if done well and short, helps one to focus on what's important, sets the tone for the day, and unites the team as a tribe.
When one is not motivated enough by looking a big fat dashboard with tickets pending, or the though of getting another paycheck at the end of the period, one can be motivated by the thought of not failing to their tribe, their peers, their coworkers.
You gave them your word, face to face, that you would work on something, so you better do, they are your people.
That's the rub, though. Despite best intentions, sometimes things just go off into the weeds. It happens more often than I'd like, and it's happened on every team I've ever been on, at every company I've ever worked at. Sure, you can say, "well you're doing it wrong", but that's not helpful. Process should support how the team works, not define how the team works.
> helps one to focus on what's important
If you need to refocus someone every day, you've made a bad hire.
> sets the tone for the day
That's my job. I know what I'm supposed to be working on, and set my own tone.
> and unites the team as a tribe
Ugh, gross. We're not a "tribe", "family", whatever.
We're a team of co-workers working on a variety of tasks, who are not children and can be trusted to communicate adequately with the rest of the team, and honor our commitments. If you have someone on the team for whom that's not the case, again: you made a bad hire. Don't punish the rest of the team because you have someone who can't do their job.
I get that some people get off track sometimes. It happens, even to the most senior of people. The solution to that is called management. Regular 1:1s, making sure your team keeps their tickets updated, and getting regular (individual, asynchronous, as-needed) status updates. If someone is having an off day, or an off week, that should be addressed individually, not by preemptively assuming the worst of everyone on the team and instituting a daily standup.
This is closely related to one's self-assessment and the question of being right and doing right thing.
If one is right, stand up do not matter. If one is wrong, they help greatly.
You say : why should I suffer for unprofessional and weak team member who is wrong?
But you forget to note that the same person could be right sometimes and doing great things and be utterly wrong and solving wrong problems some other times.
Edit: a also wanted to add, that input from peers and peer pressure is not to be underestimated. Management is be wrong as often as any of us.
> In an ideal world the thought of getting a paycheck would be enough motivation.
We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
> > In an ideal world the thought of getting a paycheck would be enough motivation.
> We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
I agree with you. It was mostly to curtail the capitalist view of "a paycheck should be motivation enough."
I think what you're against are the sync daily standups, not the async, usually written, ones.
If I was an employee, I would prefer you to let me self-manage my work however I feel comfortable using whatever tool suits me and my team, instead of constantly interrupting on Jira, Trello, etc. And I'll keep you updated at a frequency we agreed on (daily or weekly).
It's also great to read daily updates of others on the team, and even other teams, to learn about what they're working on without having to check at multiple places or interrupt their work. It's usually a great way to discuss, give and receive feedback, asynchronously.
Also, it's strange that you're suggesting "reach out on Slack" as an alternative. Doesn't that promote the "incessant messaging that Slack allows" you're decrying at the start of the article?
That’s my biggest gripe with stand ups. Management has as much if not more access to all the project management tools the developers do, so if they need a daily standup they should be able to get a sense of what’s going on simply by correctly using the tool.
I've had daily standup calls spanning multiple time zones (US, India, UK) with 30+ people in which take an hour.
I've had in-person standups which regularly turn into design meetings between two people, which everyone else has to listen to for half an hour.
I've had 5 minute 9:30am daily standups which always start between 5 and 20 minutes late, thus are significantly disruptive. Arrive at 9, get a drink, try to pick up where I left off yesterday, oh it's time for the standup. Not yet? OK, where was I? Oh now? But Dan is on the phone? Alright, in 5 mins? ...First hour of the day down the toilet.
I've had standups where people are told off for trying to communicate any sort of useful information - so people just list the people they need to talk to that day.
And of course in a small company there might only be 8 developers, often working on 4 totally separate things for different clients, but there has to be a standup with everyone just because management can't figure out how to use Jira properly.
I've had enough of standups. I've switched to working afternoons only for my current client so I can avoid the bloody things.
Readit News
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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".
Did the scrum master not feel able to intercede? Protect the process etc.
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...
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.
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
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.
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'.
Early enough for the 6-3 worker might be well before the end of the day for a lot of others.
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?
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.
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
Deleted Comment
Overal I don't think it's disruptive at all to do a short stand-up, constant nagging however is very disruptive. That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again. If you're working on something complex that can mean it takes an additional 10 minutes before you're back on track. That's the kind of disruption stand-ups can help prevent.
This of course only works if you actually stick to what the stand-up is meant for.
If any issues come up, you can discuss them immediately after the standup.
Long meetings are terrible, but short meetings are great. That's the whole idea behind the standup. If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day. It only has a measurable impact on your velocity if you're only a working an hour per day. And even then I'd guess it's useful to have a quick refresher about what you're working on.
>Standups are in my experience much more effective at signalling blocking issues than slack.
Your messaging tool is not good enough to communicate urgency? You cannot send a message and say "this is urgent" and have somebody read it and respond in a timely manner? You would have better luck waiting until the next standup meeting?
>Nobody is going to spend their day checking what other people are doing on Jira
Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?
Here's how it works when you use your tools:
1. You have an urgent issue. You message the involved parties. Your message should communicate the urgency of the issue. They read it and respond / take action within an appropriate amount of time.
2. You want to know what your team is working on. You look at your issue tracker to see what everyone is working on. If you are curious about the status of any work in particular, you look at the details for that work. If there is insufficient information about its progress, you send the assignee a message (see #1).
A five minute meeting is not five minutes out of your day. Any scheduled interruption takes at least thirty minutes, probably more like sixty, out of productive time, as a flat cost, over and above the actual time of the meeting. It's all the time that you don't start biting into something worth doing because you look at the clock, and say "Oh fuck, I've got this fucking standup meeting in 20 minutes - I can't even get started on this before that rolls around and interrupts me." And it it all the time afterwards where you have had a bunch of shit laid in your lap that you have to spend some time following up on and frigging around with before you can get back to the work you already had planned to do.
Count the whole overhead time, from the moment people stop working normally waiting for the meeting, till the moment people come back to their seats, add up the extra coffee pause that people take afterwards that people would not usually take.
You are looking on average, at easily 15 to 20 minutes per person minimum a day, probably more.
That's disruptive!
> Standups are in my experience much more effective at signalling blocking issues than slack.
If you are using Slack, you have already lost the battle for productivity.
> If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day.
Literally any interruption destroys your focus. A pending appointment destroys your focus. If you use Slack or E-Mail notifications, people never even attain focus, so in that sense it's not a loss.
> And even then I'd guess it's useful to have a quick refresher about what you're working on.
To a first approximation, nobody cares what you're working on. Nobody should care what you're working on. If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work.
Daily standups pre-suppose that there's always stuff to communicate and that everyone is always involved, but only once a day and only briefly. This is complete nonsense. You need to be able to adapt to the situation. You need a meeting? Have a meeting with whoever is concerned. Have a follow-up meeting. Take your time and focus on the issue, then nobody will even feel like time is being wasted.
I do agree with it, because everywhere I've worked that does a daily standup does it wrong, and I think OA is more about those organisations.
For many old-fashioned companies, "doing agile" means waterfall + standups. Apparently that's all you need to reap that sweet agile-y goodness. The guy running the meeting doesn't enforce any structure, doesn't stop people rambling on for 10 minutes, doesn't try in any way to note or act on the points people raise. It's just about micro-management and cargo-cult development.
I'm sure with the right company a standup is a very useful tool. But wherever I've worked, it's been all about micro-management and a fundamental misunderstanding of what I actually need to do dev work (usually: a quiet office, no interruptions and time).
If you add up the time people have stopped working while waiting for the meeting, the time you take to gather people to a room, wait for the last one to arrive, start, go back, it's been 20 minutes total, and when standups derail and people start talking a lot it goes over half an hour.
You need to count the total overhead time. I mean come on, 10 minutes before the standup you are not really working full steam, right? You know you are about to have a meeting, so you are chatting with colleagues and checking email instead of working on your main tasks. That time should count too.
The comparison isn't between the benefits of a good standup and nothing, it's between a good standup and whatever productivity you lost by interrupting the entire team (same as any meeting). You need to make sure it's worth it.
Some colleagues don't 'work' at all between getting to work and standup (opting for soft tasks like email).
Wasting 15 minutes for 5 people a day costs the company almost 6 man-weeks a year, or really a week per person. Providing that week as PTO/leave would probably result in tangible productivity improvements.
A few elements that I think contribute to long standups:
* A very large team (I've been in a marged team of 14 people once...)
* Getting too much into technical details: don't do that; have your technical discussions after the standup with only the relevant people
* People sharing their opinion (frustration) about blocking issues and that developing into a discussion. Again, leave it until after the standup.
When standups drag on for too long, it's time for the scrum master to step in and get people to keep it short.
The PRs cover the “what did you do?” questions while getting eyeballs reviewing the work and for larger PRs we will schedule something. Keeps things moving well.
The inbound requests reviews keep us from having to have backlog estimating meetings as often since we are keeping up with it as they arrive.
If the time isn’t useful, find a way to make it useful.
Walks in? Yes. That should be discouraged always.
Spamming on Slack? If that is a problem, you're doing Slack wrong. It's an asynchronous method of communication. Don't be buried in it or feel the need to respond to every message as it comes in. Check it during natural breaks or stopping points.
If something actually is urgent and requires your immediate attention, then they can break the above rule and walk up to your desk (or call you if you're remote).
This is my big problem with agile, scrum, and friends. It's like communism; it only works if you "do it correctly." Russia? China? Cuba? Yea, they didn't do it right, but if it's done right, it's really really great.
I have only ever read about agile and scrum being done correctly. Obviously, I'm just one person, and my experience is limited, but at every company have I ever worked at or consulted for, the practice of agile and scrum is very different than what I read about.
I have experienced the less than 10 minute standup maybe a dozen times ever. Not that there is usually much to talk about. "Yesterday I worked on on X. Today I will keep working on X."
But somehow enough people in one place just seems to create so much friction. There's always a tangent. A: "By the way, how long do you think until we finish X?" B: "I don't know. Kind of depends on Y and Z. I never did Y before." C: "Oh, I did Y before, it's easy, you'll have no difficulties" and on and on.
I can see two possibilities:
1) My experiences have been not been representative of the industry as a whole. On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.
2) My experiences are representative. In this case, agile/scrum is so difficult for the average company to pull off, that it's kind of a rare occurrence.
The fact that angst-ridden articles like this one are such a regular occurrence on HN kind of makes me suspect that it's #2, not #1.
I'm just an engineer, so project management is not my area of expertise, but my layman's opinion is that an actually good project management system should "fail gracefully," as it were. You shouldn't need a 1 in 1000 level PM to pull this stuff off.
Not a chance -- your experience mirrors mine over the course of the six or so companies that I've worked for. It's definitely #2.
They all fail in very similar ways: story points become hours/days; stand-ups devolve from status updates to daily team discussions; the backlog becomes irrelevant because new stories are created for each sprint; and, in companies which report velocity to senior management, story-point inflation.
Also, I've noticed that Agile transformations always create Agile zealots within the organization which seem to act to quell dissent. I'm not sure why this is, maybe the transformations are tied to bonuses or something, but it's a universal thing. There's always somebody running around telling you that you're team is Doing It Wrong when you bring up any legitimate criticisms of the process.
See:
> It's like communism; it only works if you "do it correctly."
But your job as a developer is to not have this happen. It’s nothing something that would be a nice to have, you’re supposed to always keep your team informed about potential gaps. The standup is designed to catch gaps but really that should be something you should already be doing.
I have seen so many dysfunctional standup cultures: Places where you had to showcase and exaggerate how much stuff you had to do and people were looking at you funnily when you said what you are doing in under a minute, places where discussion that only interested a third of the team were started and standups took half an hour, places where the managers interrupted and asked why stories took so long...
When we were working to disambiguate deliverables or working on design or implementation, stand ups were useful. They held everyone accountable, when folks weren’t making progress because of some issue, it was super obvious - it gave management a really good insight into where things are and what blockers are.
Your characterization certainly doesn’t represent my experience. We went through phases of launching a products or services and focusing on them and then going back to pay off some of the tech debt until product management, engineers, and leadership arrived on the next set of big features.
"The panopticon is a type of institutional building and a system of control designed by the English philosopher Jeremy Bentham in the 18th century...[It] allows all prisoners of an institution to be observed by a single security guard, without the inmates being able to tell whether they are being watched."
Learned a new word and concept today. Thanks!
1) Aim to take 2-3 tasks, do not take more, take 1 if the task is large, but usually, it's a sign of an overblown story.
2) Every day at the end of the day, write a "current status" comment. These comments are visible in the master panel, and I could take action the next day to help developers resolve roadblocks, if the resolution is taking longer, they can work on other tasks they claimed.
This effectively eliminated the need for standups, the whole team could sync using task "current status" updates, and chime in with help or advice. I was able to see the progress and issues without forcing people into a mess of a video call, and everybody could still stick to their preferred schedules and have personal lives.
Standups as intended are too brief to discuss the important details. This is why they end up ballooning to 30+ minutes at most companies, because anything shorter is of little value.
They also end up as a catch-all meeting for any topics that require the team's input; I dislike this because people are expected to provide input on the spot without really making any thoughtful considerations. If we want to have a discussion on a UI component, that should be done in a dedicated, prepared meeting, not at 8:30 in the morning when people are unprepared and said developer can take advantage of unpreparedness to obtain the consensus they want.
When I provide up-stream status reports, I like to have the developer's notes in front of me for a quick refresher. Plus, they serve as a good reminder on topics that need followup.
If you don't value those things then just be low key in your input, its literally 10 minutes of your day and has the potential to present an avoidable issue. To discard it as "management trash" is IMO a massive amount of disrespect toward your fellow team members. They can help and the stand-up opens opportunities for help. There's design work, review work, product management work, scheduling, triage, retrospectives. There's ample opportunities for efficiency gains in these areas during a stand-up outside of just writing code. If you think your job is just writing code then I can see how you might think they're useless but nobody's job is, we all work in teams.
Even if the meeting itself was instant it would take more than 10 minutes. You would have to stop whatever you're working on, even if you're in the middle of a valuable flow state. Then after the meeting you have to get back into whatever it was, which alone can take you more than 10 minutes depending on the depth of your work.
If that's not bad enough then what you talked about in the meeting can also linger. You'll think of problems others have had and it causes your mind to lose focus, now you have thoughts about your problem mixed with other problems. These meetings also tend to happen during the mornings, smack in the middle of the most productive hours of the day.
No, a daily standup takes much more time than 10 minutes.
FWIW, imagine how a greenhorn might feel working on a team with you. If you feel like giving them some time of your day is a waste or that listening to their problems is a waste they're not going to feel enthused working on your team. Sure, that doesn't necessarily influence your current work item but it might contribute to overwork later if they leave for a team that actually makes them feel like they matter.
One solution I found is to write a quick status in the chat and excuse myself from the stand up.
Sometimes I finish 20 minutes before the stand up and think about what to do next. I usually won’t go into deep work but plan something, write my todo list on paper or review some PR to make use of the amount of time that’s to small to get into flow.
Literally, it's not 10 minutes. Count the time that you have stopped working and people are chatting waiting for the meeting, checking their email when they would not otherwise do so, not working on their main tasks.
20 minutes to half an hour of time not usable for main tasks is a more typical estimate.
We have six people in the stand-up.
If you're so sad about being interrupted then maybe you're taking on too much work?
In an ideal world everyone would be perfectly professional and not need any supervision at all. In the real world some times you might be in a rough period or have some other problem that makes concentrating hard. In an ideal world the thought of getting a paycheck would be enough motivation. Sometimes it isn't.
A daily standup, if done well and short, helps one to focus on what's important, sets the tone for the day, and unites the team as a tribe.
When one is not motivated enough by looking a big fat dashboard with tickets pending, or the though of getting another paycheck at the end of the period, one can be motivated by the thought of not failing to their tribe, their peers, their coworkers.
You gave them your word, face to face, that you would work on something, so you better do, they are your people.
That's the rub, though. Despite best intentions, sometimes things just go off into the weeds. It happens more often than I'd like, and it's happened on every team I've ever been on, at every company I've ever worked at. Sure, you can say, "well you're doing it wrong", but that's not helpful. Process should support how the team works, not define how the team works.
> helps one to focus on what's important
If you need to refocus someone every day, you've made a bad hire.
> sets the tone for the day
That's my job. I know what I'm supposed to be working on, and set my own tone.
> and unites the team as a tribe
Ugh, gross. We're not a "tribe", "family", whatever.
We're a team of co-workers working on a variety of tasks, who are not children and can be trusted to communicate adequately with the rest of the team, and honor our commitments. If you have someone on the team for whom that's not the case, again: you made a bad hire. Don't punish the rest of the team because you have someone who can't do their job.
I get that some people get off track sometimes. It happens, even to the most senior of people. The solution to that is called management. Regular 1:1s, making sure your team keeps their tickets updated, and getting regular (individual, asynchronous, as-needed) status updates. If someone is having an off day, or an off week, that should be addressed individually, not by preemptively assuming the worst of everyone on the team and instituting a daily standup.
True. Happens in every meeting. In which case anyone present can (and in my view) should get the meeting back on track.
“This is off topic”, “can you/we discuss this later”, “this has nothing to do with why we’re here for”.
Having strict time limits, a clear intent, and of course people enforcing it does make it possible.
>> and unites the team as a tribe > Ugh, gross. We're not a "tribe", "family", whatever.
Agreed. This stuff makes me gag.
> Ugh, gross. We're not a "tribe", "family", whatever.
To each his or her own
If one is right, stand up do not matter. If one is wrong, they help greatly.
You say : why should I suffer for unprofessional and weak team member who is wrong?
But you forget to note that the same person could be right sometimes and doing great things and be utterly wrong and solving wrong problems some other times.
Edit: a also wanted to add, that input from peers and peer pressure is not to be underestimated. Management is be wrong as often as any of us.
We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
> We'll just have to disagree on that. In my ideal world, getting a paycheck would be a natural byproduct of doing something interesting, that matters, and about which one would care.
I agree with you. It was mostly to curtail the capitalist view of "a paycheck should be motivation enough."
If I was an employee, I would prefer you to let me self-manage my work however I feel comfortable using whatever tool suits me and my team, instead of constantly interrupting on Jira, Trello, etc. And I'll keep you updated at a frequency we agreed on (daily or weekly).
It's also great to read daily updates of others on the team, and even other teams, to learn about what they're working on without having to check at multiple places or interrupt their work. It's usually a great way to discuss, give and receive feedback, asynchronously.
Also, it's strange that you're suggesting "reach out on Slack" as an alternative. Doesn't that promote the "incessant messaging that Slack allows" you're decrying at the start of the article?
Disclaimer: I'm cofounder of the team communication tool https://www.happierco.com
I've had in-person standups which regularly turn into design meetings between two people, which everyone else has to listen to for half an hour.
I've had 5 minute 9:30am daily standups which always start between 5 and 20 minutes late, thus are significantly disruptive. Arrive at 9, get a drink, try to pick up where I left off yesterday, oh it's time for the standup. Not yet? OK, where was I? Oh now? But Dan is on the phone? Alright, in 5 mins? ...First hour of the day down the toilet.
I've had standups where people are told off for trying to communicate any sort of useful information - so people just list the people they need to talk to that day.
And of course in a small company there might only be 8 developers, often working on 4 totally separate things for different clients, but there has to be a standup with everyone just because management can't figure out how to use Jira properly.
I've had enough of standups. I've switched to working afternoons only for my current client so I can avoid the bloody things.