I've worked in many teams that used standups, the general feeling was that they were utterly useless.<p>Except for management, as standups are a simple way of keeping psychological pressure on developers and squeezing every last bit out of them.<p>I even saw once a developer on his last day throwing the speaker's token (a teddy bear) to the trash can LOL!<p>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.<p>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.<p>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.<p>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.
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.<p>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.<p>This of course only works if you actually stick to what the stand-up is meant for.
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.<p>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...
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).<p>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.<p>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.<p>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.
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.<p>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.
Daily Standups do make sense to some.<p>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.<p>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.<p>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.<p>You gave them your word, face to face, that you would work on something, so you better do, they are your people.
I think what you're against are the sync daily standups, not the async, usually written, ones.<p>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).<p>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.<p>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?<p>Disclaimer: I'm cofounder of the team communication tool <a href="https://www.happierco.com" rel="nofollow">https://www.happierco.com</a>
I've had daily standup calls spanning multiple time zones (US, India, UK) with 30+ people in which take an hour.<p>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.<p>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.<p>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.<p>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.<p>I've had enough of standups. I've switched to working afternoons only for my current client so I can avoid the bloody things.
How about we just stop generalising across each others projects, teams and environments?<p>This stuff is always highly context dependent and the ongoing efforts of everyone to pretend it isn't makes it extremely difficult to have adult conversations on the topic.
Completely agree with this. It just seems like ritual for ritual's sake. I tend to learn nothing from standup that I couldn't learn by checking Jira or just directly asking someone. And waiting a full day to raise blockers is foolish.<p>Sometimes things go a bit too far, with people delving too deeply into whatever topic, with a sort of side-conversation starting. Yes, these people should "take it offline", and often after a minute or so of back and forth, they will, but it still happens often enough that it turns into a waste of most of the team's time. "Be more disciplined!", you say? Sure, ok, wave your magic wand and make that happen, please.<p>The counter-argument I usually hear to anyone who wants to get rid of standup goes something along the lines of: "but it's great to get everyone together once a day, and sometimes people will spontaneously learn of something that they have useful input for, and save someone some time". Ok, so you want to waste 10-20 minutes of my time on the off chance that someone <i>might</i> randomly have a useful contribution that wouldn't otherwise come up? No, pass.<p>And regardless, this sort of attitude is actively hostile toward remote members of the team, who may be in different time zones and can't reasonably participate.<p>If your team really needs daily status updates, create a "standup" channel for your team on Slack (or whatever you use), and have people do a once-a-day post in there. No deadline, just when they get to it. But even that just feels like micro-management.
I like standups. They keep me updated on what's happening in the code base, and give us the opportunity to discuss what's going to happen next. The repo is vast and we're gown adults that don't need to be micro-managed because story A or B is taking too long.<p>The problem doesn't come from standups, but rather from dysfunctional startup culture.
What information does a standup monologue convey that couldn't be expressed more clearly and with persistent links to context than a comment on a Trello card?<p>My team don't do daily standups. They're pointless ceremony.<p>Yesterday I worked on… Yes we know. We can see the Trello card you worked on.<p>Today I am working on… Yes we know. We can see what you've currently assigned yourself on Trello.<p>I am blocked by… Why the hell are you waiting until <i>now</i> to bring this up?!
The hubris of the software profession never ceases to amaze me. You have thousand-word screeds about the injustice of being required to attend a daily 15 minute meeting to catch up with your teammates, while being paid six figure salaries. I suggest getting a job in food service, or even construction if you want to see how the average laborer works. Tech is the softest industry ever created.
I've long been sceptical of the three questions – well intentioned no doubt but way too prone to becoming an unhealthy exercise in individual self-justification. Much prefer to review the work "right to left", starting with work just completed, then work we can get over the line, then the bulk of what's in progress, and (if there's capacity), what's in the immediate pipeline. Now it's about what _we_ can do to finish the most important of what's in front of us.
They're called standups for a reason: you're supposed to do them standing up so that people whine if they go over five minutes. That tracks out to 25 minutes or less than one-eightieth of your week.
Daily standups while being mostly useless on the surface, have an implicit value of enforcing a daily face to face communication between team members who work remotely. In remote teams I often find that people who don't interact face to face frequently, but work on the same part of the system, are more likely to run into communication problems down the road - doing duplicate work, passive aggressive attitudes in PR reviews, poor communication in general which impacts the system in a very direct and negative way.<p>Here's a thing -- people rarely become friends over email or slack conversations, unfortunately. And a team of friendly people who trust each other and communicate efficiently (e.g. feel absolutely comfortable setting up a quick video conferencing call to talk about an issue) is a lot more valuable than a team of people who rarely talk to each other and mostly prefer texting over anything else.<p>Those are my findings when working with remote teams only. I don't think standups are necessary for colocated teams, which can sync at will anytime they want.
Well, I see the point of a senior: with enough practice you should not need rituals of this kind anymore.<p>Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it.<p>It's not like when you're junior, you've never done any standup and you don't know when you've been blocked long enough to switch task or ask for support, you've never done any poker planning if you're techie, or value estimations if you're product / sales, you've never prioritized by complexity / value score if you're manager - or equivalent.<p>For this reason, I think there's still value in such rituals when there are non seniors in a team.<p>However, I prefer text-chat based standups myself and feel like they produce the same value and cost less time.
The questions as presented strike me as something that is more suited in a 1-on-1:<p>> What did I work on yesterday?
> What am I working on today?
> What issues are blocking me?<p>At my job we have tickets on a physical board and we discuss them from right-to-left. There are magnets on the tickets with people's names on it and when you get to 'your' tickets you talk about what is happening with that ticket. This is a lot more concrete and relevant to the rest of the team.<p>At a previous company we went from person to person and they'd discuss what they were working on. This always struck me as a strictly personal accounting of their previous work day and I had a feeling that people felt like they had to boast or exaggerate what they were working on. It never felt relevant or interesting.
In my limited experience, one key to successful standups is making them as small as possible. The worst standups are the ones which contain over a dozen people working on a bunch of only vaguely related projects. The best ones are the ones that only involve the people working on things directly related to thing I happen to be working on. I you're a manager this might mean that you have to organize 3 or 4 standups instead of just one and keep track of who is working on what and being sure the right people show up to the right meeting. If it turns out that someone is being blocked by someone not at the meeting then either set up a new meeting with just the people involved in that problem or make sure that particular person is at the next meeting.
> I've had this feeling that the industry likes to treat development teams like a bunch of idiot teenagers.<p>The infantilisation of developers seems to be common in larger organisations. It's extremely tiring.
I work in a fully remote team and our daily standups are one of the highlights of the day as we get some actual "face to face" time rather than just the usual Slack chat. I think it's probably a bit reductionist to use a headline like "Standups are pointless" rather than just "I've personally not found them helpful".
For me daily scrum meetings were valuable when the team remains small and work on related stuff in a fast pace.<p>But for the last few years, it has not been the case for me. Standups have been organized for managers and scrum masters so that they attend only 1 meeting and participants were not working on directly related topics. Most did not care about what others were doing and issues they faced. We reduced them to bi-weekly or 3 times a week and re-focused them on synchronization topics...<p>Also my general feeling (maybe because I am an old developer) is that it is infantilizing,
and a way to maintain peer pressure.
>> Okay so, basically, the only unique point to standups is that they "keep everyone excited"?<p>Skipping right past the part about "flag team blockers" in what they just quoted. I don't much care for the other nonsense, but sometimes I'm stuck on a problem, and I'll keep working on it if no one else knows, but it's nice to just broadcast where I'm at and see who thinks they have helpful insight. That happens a lot in my stand ups.
Working remotely, the daily standups are the only times in the day where we meet up face to face in a video call.<p>Not only that but it's a time where we feel safe to say that we are struggling on something and ask for help to everyone at once: this often leads to someone in the team (not necessarily the manager) suggesting a pair-programming session to move forward more quickly.<p>Another thing is that we have several products developed independently but with shared libraries. The standup is the moment where we suggest appropriate usages of the shared libraries depending on what our teammates are working on. This increases code re-use and makes us faster.<p>In addition, we have what we call "Sharing time" at the end of our standups, which is a time dedicated to sharing anything we care about, mostly non work related. It's actually cool to see what our colleagues are up to outside work (one colleague is into model planes and 3D printing, another is currently traveling across Portugal, etc, etc). Very interesting stuff !<p>Our daily standup is kind of like the coffee break in a traditional office.
This type of article has far too broad a brush. It's like saying don't play 4-4-2 in football (soccer) because we just won a trophy using 3-5-1-1 so 4-4-2 killed your team's chances of success. It's so small minded it's incredible.<p>As a manager or as a team, you need to determine what will work best for your team and you will need to adapt.
This is absurd to me. Standups are quick and it is helpful to know what everyone is working on. And they can serve as a time when you are up front about being stuck on something and get some help from a teammate when maybe otherwise you might have just kept tinkering or hammering away in your own world. It’s just a little nudge to share your status and keep everyone on the same page. It prevents wondering what your colleague is typing up a storm about which is a natural human curiosity.<p>And the author says make it async, I agree! That’s not against the spirit of standups, I’ve worked on remote teams with an asynchronous standup slack channel.<p>The most common problem I’ve seen with standups is they can become more than status updates and end up a time during the day to brag about your accomplishments or justify your status within a team/project. Usually to keep management happy or angle for an agenda other than keeping the team together.
Yes, distractions are not great - but communicating with your team is important. Even if the manager is not there the team does it and they do it usually < 5 minutes. Some days I literally don't talk to my team except for that 5 minutes.<p>But as a leader you want to make sure the team is rowing the same direction - it doesn't matter if it takes you longer on a ticket but it also helps in a team to know what others are working on in case you end up working on it later yourself. (We discussed at standup to implement it X way because of Y factors).<p>Many engineers (myself included) don't like asking others for help. But guess what when someone says they are stuck - it is easy to point them to a person or direction and not waste time debugging a problem already solved in the past.<p>If they were so horrible and unproductive, managers (who mostly were engineers in the past would get rid of them).
Yes, daily detailed standups are not useful. BUT, since development teams tend to be slightly to very introverted, it helps ease 'department wide' communication and 'solutioning' that wouldn't happen otherwise. The underlying goal is to help personality types that often don't like to communicate outside of a small group, and often don't like to ask for help, and in some cases helps the few developers who 'cannot see the forest for the trees' that focus on trivialties when they need to look past them. Edit: It also helps product or leadership types who may not be well versed in technology.
Move the daily to just before noon: it does not stop you during work and people tend to keep it short because they're hungry. And you can have people coming in late in the morning and not be a problem.<p>They're a good way to handle people who don't communicate well: if it looks like a junior is blocked on something and does not like to ask for help another dev can easily propose a pair-coding session.<p>But you need to only have devs or former devs so you don't get the feeling you get judged because your "what have I done last day" is "mainly nothing, this ticket is not exciting so I'm going slow".
I can't agree more.
I've never done standups in the teams I managed.<p>But I chuckled a lot when seeing other teams/companies destroying the morale of their employees with this childish and borderline cult-like parade.
I've taken over management of a few scrum teams now, and in every case, I've also had to take over standups. One team had somebody who used a time tracker and showed me that the average length of standups before I arrived was something like 37 minutes. Another team, standup was run by the PM and they reviewed EVERY story in the sprint, triaged all new bugs, talked about new features and, worse, pressured developers who were falling behind at EVERY standup.<p>Given how badly many standups are run, I completely understand why most developers hate them.
I am a consultant working in a distributed team, often remote from our client. I find the standup format to be very useful, often delivered via a daily email.<p>While we use a formal issue tracker like Jira which handles approvals and estimates, from a project management perspective it's useful to have a summary email that is short enough for people to read and focused on business level issues.<p>"Today I worked on this" / "Next I plan to work on that."
This helps clients to see exactly what we are working on. It avoids miscommunication where we think they told us to prioritize something different, or they thought they told us to stop work on something, or they think we are finished with something and we are not. Having an email every day lets them tell us to stop work immediately if we are doing the wrong thing, avoiding surprise invoices the next month. It avoids them claiming that they didn't know that we were working on something.<p>"Here are the problems I am having / things I need from you".
This is very useful to keep track of delays caused by the client. This might be them needing to review and accept work, review specs, or pay their invoices. Issues stay on the report until they are resolved. It documents that we didn't get what we needed, so we can't be blamed for things being late.
> Jira, Trello, Asana, the stickies on your wall, or reach out on Slack<p>In a nutshell, the article claims that these electronic tools render a daily standup pointless and/or disruptive.<p>First, note how many different tools are mentioned. If your project uses one or more of them, you'll need to monitor them all to understand what's happening around you.<p>Second, the constant interruptions of Slack can be extremely disruptive to workflow, as has been noted in a few articles posted here.<p>Third, the article makes an assumption I've seen elsewhere and cannot relate to at all: that project members don't need a high-level snapshot of the project on a day-to-day basis. That it doesn't improve what they do and only sucks time away from the more important job of getting stuff done. As the author puts it:<p>> I'd argue the loss of your focus more probable than the benefit of knowing what someone else is working on.<p>This is a recipe for the entire team heading off a waterfall, each in their own hermetically-sealed, technologically sublime barrels. This is not to say that a daily standup can save you if the team is determined to do it. But getting that daily overview can help build consensus for changes in direction that simply can't come about by monitoring Jira.<p>I always wonder how effective team members showing the tendency to minimize the bigger picture while maximizing the importance of their own contribution will be on a team. The answer usually turns out to be "not very."
I strongly disagree and would like to apologise on the behalf of devs + managers that gave you this impression.<p>I was fortunate to work with people that ran proper stand-ups (5-15 minutes at the beginning of the day, actually standing up). Senior, junior, management, devs, it felt like we all benefited from a quick huddle before starting dev. Even if we Slack troughout the day and raise issues, having a quick sync session seemed to have a bigger impact.
Agree with the notion that turning standup into a static status meeting is a poor use of time. If you're blocked you should speak up. If the team wants to know the state of your work, they should defer to project management tool. That said, "standup" is less to do with what you did or immediate blockers. It's about planning for the day. "Here's what's going to get done today, and here's the relevant information for my team." It's a tool for synchronizing, getting on the same page, setting you and your team up for success on a daily basis.<p>If you don't feel like that's the case, you're probably right in that going async <i>would be a better use of your time</i>. I suspect this is a process dysfunction that has less to do with standup and more to do with a misunderstanding of the value proposition associated with a properly executed standup.<p>Edit: not everything is an immediate "oh sh*t" type of blocker. If you're working in a collaborative organization, you most like have "low tier" blockers or knowledge that can and should be shared with the team. Face to face makes this easy.
I get the frustration, I really do.<p>But I think part of the issue here is the idea that time is fungible like money. That saving time by looking at Trello cards instead of meeting face to face is somehow more effective.<p>It might be. It might not be. But simply saving a few minutes of time doesn’t necessarily equate to “more productive.”<p>This kind of optimization of behavior assumes everyone will consume information uniformly.<p>Ever sent up a smoke signal for help on a blocker in slack, only for the comment to be lost in a bunch of messages and you stay blocked?<p>Again, in a perfect world, we could just record everything and do it all asynchronously. Wonderful ideal.<p>But the stand up, in my experience, accomplished more than just cold task management.<p>It gives a point for each person to consider what they’ve done, compose it, and to raise in a higher resolution environment the blockers they have.<p>It’s silly to think that we can replace every interaction with an async version of the same interaction, at least on my team.<p>At the same time, I don’t recommend dogma in either direction. Don’t find value in the standup? Do something different.
I've had no issues with standups. Even in a small team I find them useful as a way to step back and see the bigger picture, plus they rarely take more than 5-10 minutes of my morning.<p>On the other hand, I've had friends who have endured 30 minute standups every day for the past few months. I think they started sitting after the first few sessions.
As a fairly new out of university and with my first startup job, I found the newly introduced daily standup a motivation saver & reduced stress in the group.<p>Our dev sub-group had no sync-meeting except weekly-meetings where we met the entire department that presented their progress that didn't give us any insight in what was going on at all. Didn't help that our sub-group responsible where the CTO, that was mostly absent for investor/customer/management meetings. Tasks where distributed really unevenly, some devs got isolated in their module/tasks for week/months and lost sight of where the development was at the moment.<p>standups seems to work pretty well when the person in charge have insight in to how each members work fit in to the overall picture, and would rather not manage the group much more than making sure people are not trailing off. It helps the group more than the managers, if done right.
Daily standups are not useful to me, but having just a periodic conversation with who you work with is more useful that both just standups and/or just checking issue lists.<p>A lot of times, there are plenty who simply don't talk about the projects they are working on unless prompted. This extends even to JIRA tickets, which can feel like bookkeeping than actual work. For me, this tends to be a constant problem, but adding more layers of protocol tends to scare people more than anything. This can be like a fear around saying you couldn't get anything done yesterday.<p>With simple conversations where I can just talk with team members for an hour or so is more revealing that trying to answer specific questions. The important thing is not to cover each detail. Instead, for me, is just conversing about problems where we all gain more insight in what we are doing that helps a lot.
As a grunt, hate them but as a team leader they really help make my life easier. In short, depending on team size, you are sacrificing the producers to make the manager's job easier and unfortunately this is a decision that the manager gets to make, so guess what decision is made all the time.<p>The problem is that as a manager I don't want to look bad in front of my manager and he he/her manager's and so on and so forth, so I have to do things that are suboptimal from a delivery point of view to avoid this, e.g. run a stand up to keep a close eye on what everybody is working on rather than say not and ensure that they guys (and gals) know that I'm here to help should they get stuck.<p>To be fair, they do help with managing people that are, for whatever reason, reluctant to look for help, but there are other ways of managing this
In the very spirit of agile, if standups are not providing your team value, then by all means stop doing them. But, if you are not able to perform a quick functional standup that informs your team about the important work each person is doing, their blockers, etc, might I suggest this is a sign of a deeper team disfuction, rather than some inherent issue with standups generically.<p>I'd go further to say that if your standups consist merely of parroting words verbatim from JIRA, you're letting your team down by not providing additional detail and context that could be provided more easily in person than on such a tool.<p>Lastly, reading between the lines of your text, you seem very much "over it". Not standups, but team engineering. Possibly time to find a new environment better suited to what you enjoy.
Reducing actual face-to-face interaction and communicating only over Jira is a way to de-humanize work.<p>Do work as a team of humans. Talk directly to your fellow team members. Using daily standups is a face-to-face way of syncing.<p>Don't work by sitting 10 hours in front of your screen and communicate only via chat channels.
Standups are only good if they're used for a very specific, time-critical task that requires coordination among several people. Ex: a major feature is being launched that requires a lot of coordination, but is going to be done in 10 days.<p>Standups should not be used as tack-on "agile" or as a way for management to keep up with what devs are doing or to pressure devs to do more. Ex: daily standup at 11 am.<p>The original purpose of standups in "agile" was to help devs get unblocked. But the expectation should be that others should help devs get unblocked whenever they hit a block, instead of waiting til the next standup! What are they wasting time being blocked when they can simply send an email or IM to a colleague?
In a recent client engagement I witnessed scrum-gone-badly-wrong.<p>It happened underneath the department manager in the line organization of a large corporate (not project manager, line manager). He managed about a dozen people doing about a dozen projects at any one time. A project was usually staffed by one person working it fulltime, and drawing support from the rest of the group here and there.<p>The manager held a daily standup involving the whole dozen people. With everybody doing a five-minute status report on their project, that meant five minutes of speaking time for everybody and 55 minutes of sitting through status reports on projects that you had zero involvement with, where you couldn't possibly have anything useful to say. I suggested numerous times that it would be better to have devs have a 1-hour blocker in their calendar without an actual meeting. They would do an e-mail update, and if the manager saw the need for any clarification he could use the 1-hour timeslot to turn up at their desk and talk 1-on-1. It would have been so much more efficient, but the manager didn't go for the suggestion.<p>Paying lip service to the scrum quasi religion, the manager repeatedly emphasized that the point of the standup was not to check on people's productivity or make them face repercussions for not meeting daily commitments. But he never missed an opportunity to make a passive-aggressive joke when a dev's productivity was called into question. Like a dev might say "I thought I would be able to do X yesterday, but didn't manage, because problem Y turned up. I solved Y, but X is still not done". The manager might jokingly say something like "Well, I hope you enjoyed your beachtime and will be able to finish X today." So not funny. I'm thoroughly convinced that shaming people was the method he was using to pressure people into doing overtime or otherwise doing whatever was necessary to meet daily goals every day, and that that was the real reason he wanted the whole department in the room. Because shaming is so much more effective when you shame somebody in front of a lot of people than just making a bad joke in a 1-on-1 situation.
I don't know if they daily standup is necessary, but there is some value in frequent synchronous meetings. Some people just feel more comfortable bringing things up during a meeting, despite the myriad ways they could otherwise communicate.
Standups can be great. And they can be useless. It depends on how they are designed and used. For example, the frequency should be matched to the needs of the team. It only makes sense to meet when there is relevant new information. For example, at the Broad institute at MIT, lab teams meet daily to discuss the output from the last day to identify bottlenecks. It’s important to identify problems quickly so meeting every day makes sense. In other systems, meeting every two or three days would make more sense. It’s not that standups are useless, but that poorly designed stand ups are useless.
I had the exact same feeling when we started having daily standups about 4 years ago for a green field project. Now that most of the original developers are no longer in the company I feel glad that I actually paid attention. It turns out that I have a very good knowledge about how and what every micro-service in our stack does. What's discussed in those standups might not be relevant for day-to-day work, but on a higher level it can help developers understand the architecture of a complex system better.
<i>"Your standups are killing your velocity."</i><p>"Velocity"?<p>It'll be hard to start a revolution while still using the enemy's terminology.<p>--<p>Gods, I'm miss PMI, critical path, the trilemma (time, cost, scope), quality, rationality.<p>And before any ankle biters whinge about "water fall", just stop. We were so much more iterative, nimble back when we acted like professionals.<p>The Agile Methodology is to argue about the Agile Methodology. Pop-biz psychology. Tech's own post-modernist rejection of anything older than a week. And just as useful.
I strongly disagree. People sometimes won't mention important things (e.g., blockers, possible misunderstandings) unless prompted and encouraged (you sometimes actually need to look at the person's face and hear the intonation). Async interrupts are bad (I don't have time to get into that one right now). I would have replace "Excitement" with "expectation management", "mental atmosphere monitoring".<p>I do agree that badly managed stand-ups are a waste of time.
I completely agree with this. Standups are pointless, you have just communicate anything that you need to communicate via chat. Standups in general are simply a pressuring mechanism.
I would not mind a stand-up once a week. In fact on a team that never had meetings, I suggested to my manager to have a half-hour meeting every week or two. And I hate meetings!
I usually take note of what I did at the end of the day to give me an idea of how productive / unproductive I was. On a previous time I got everyone to just post their standup updates on Slack. It was quick and asynchronous. If you wanted to follow up with someone you could just talk to them afterwards.
It also gives you a history of the past week, month, etc if interested.
Data is useful and daily meetings are often pointless. Let’s all evolve our standup routine.
The only time I have ever seen value in a daily standup meeting is when I worked in a blue-collar industrial job.<p>Everybody had to clock in by 6:30 AM, so there was none of this shit where it is time for the standup, and two or three people haven't dragged in yet, so you delay and waste time.<p>The foreman told each person what they were doing that day. And that was what they needed to get done.<p>If there was a blocker or a safety issue, you threw the shutoff switch and jumped on the radio right away.
I work remotely, have the last 5 years. I love daily standups. Here's why:<p>1. We do all of our work business async. (e.g. what did you do? what are you working on? All that stays in slack)<p>2. We use our standups for ice-breaker questions and company-wide announcements. (e.g. Everyone talks about what their favorite vacation was, which usually creates quite the conversation. And then afterwards, the team heads will give any critical updates they have, which usually are none)
it depends on the tone of the standup.<p>For a start they should be quick, and the team needs to be fairly small (about 5-6 seems ideal). and cohesive, mostly working on related or interacting code. Also I assume remote, as that's my experience.<p>The status update part should be extremely quick even perfunctory, unless there's an interesting lesson or important caveat or note-bene etc to share with the team.<p>The reason for the standup is to make sure everything is "joining up" properly, no new obstacles are looming, and possibly to plan meetings/pairing sessions/etc, for later that day, where required. ie like a football scrum where you agree the game-play for the day.<p>It's also chance for a bit of "team bonding" type stuff, eg to ask the whole team "are we all feeling good about this sprint", etc - ie, the kind of stuff that may not obvious from stats<p>If the standup just becomes a forced "status report", that's worse than useless, I agree, and just makes everyone feel "monitored" and under pressure.<p>I would guess they are also less useful (and potentially more stressful) where everyone is physically present, and might be seen as a trick to get everyone to the office on time.
I come to prefer standup over slack, 10:30amish everyday a 30 second message of.<p>-I did x yesterday and am doing y today.
- I am blocked/need a (answer, code review, dependency completed, ect).
-reminder of OOO or WFH.<p>This minor message keeps everyone in the loop and takes little time. If you feel pressure to deliver because of standup I would say that's a cultural issue... or a self performance one (aka why have you been working on x for 2 weeks).
> "Maybe its naiveté or maybe just being on teams where, remarkably, nobody knew how to do an effective standup (myself included)"<p>Nailed it. Please don't "ping me on slack" to find out what I'm working on. And please don't force me to document to the nth degree in JIRA. Let's just have a quick chat in the morning and move on with the day.
One way of doing stand-ups that I found least annoying was we went through the Kanban board and basically asked if you had any problems with your assigned item. If there was no problem then you were done. If no one had any issues it was done in a few minutes and there was no chance for it to descend into pointlessness or irrelevant tangets.
Agree with this! Standups are so much worse when you're remote and working different timezones too. It's so disruptive knowing you've got to set up a voice call at a certain time most days. It's completely against async working and takes away your freedom to work the hours that work best for you.
I wouldn't mind stand-ups (well, not <i>as much</i> ) if they actually stuck to their mission statement.<p>My biggest problem is that almost always someone (usually the product owner/manager) starts droning on and on about stuff that has little to do with daily work, usually by repeating stuff already said the day before.
To some extent I find standups useful for joining a team. It helps me understand how to team operates, who the experts are, the team's struggle points, etc. But yes, after a short while they do begin to feel mostly pointless.
Stand ups are the modern mashup of two great comedian quotes:<p>Pascal's "I have made this longer than usual because I have not had time to make it shorter"<p>And Carlin's "Have you noticed that their stuff is shit and your shit is stuff?"
The key to a good stand up is if you have nothing to add, or to say, just make it very quick.<p>They're useful for people actually working together and having a sit-rep. When it's business as usual, they just hinder morale.
It is hard for one to appreciate the value of a process that helps teams operate well in the long run, in the face of disruptions, pivots, failures, growth, etc. If you can do without standups, good for you.
Standups (as implemented) or another way management thought they can do the same work without hiring real developers.<p>You can come up with any process you want, if you don't have the people, you have nothing.
Stand ups had one real value for me - maintaining my accountability to my team.<p>Having to say "yesterday I was too busy arguing online so didn't do anything" was something helpfully painful.
We do standups, however the questions are more like<p>What task moved yesterday? (handover?)
What task is going to move today?<p>and the most important one:
What is blocked? (Who can help to unblock?)<p>I can recommend this format for everybody.
let me start with some piece of wisdom: scrum is not a silver bullet. It may not solve your problem, and create additional ones if done improperly.<p>Also, scrum is not written on stone. If something from scrum does not work for your team/company culture, don't use it. Dont like standups ? dont have them. Dont like poker planning ? Don't play it.<p>The process should help you achieve your goals easier and quicker. If the process is hindering your work, just don't follow it.
Refreshing take on standups: <a href="https://youtu.be/2u0sNRO-QKQ?t=105" rel="nofollow">https://youtu.be/2u0sNRO-QKQ?t=105</a>
I'm on your side. But some, maybe most people, prefer synchronous talking. And even with async, making a point of daily updates keeps teams focused.
We've been doing daily free-form standups for years. Initially, it was in-person because nobody was working remote. Recently, one of our people moved to another state and we decided to shift towards remote work to accommodate that, with the eventual shift towards enabling it for everyone.<p>That shift has meant that all meetings now have a video component. Our weekly meeting is everyone in a room, except the remote person who is on video. Daily meetings are all-video, everyone participating from their desk via video chat.<p>Previously, our "meeting" was really a chat session that we talked about work a little and other stuff a lot.<p>Now, our meeting starts with what everyone did and will be doing, working through some issues anyone has, and then talking about whatever until we run out of stuff to talk about, which is usually shorter than I expected, given our previous in-person meeting length.<p>We have 4 developers, and this seems to be working very well for us.<p>Without the daily meetings, we'd not get some of these issues resolved as quickly and we wouldn't have as much team-building time. We initially tried an afternoon meeting for that team-building time, but it didn't work for various people for a number of reasons.<p>The person writing this article seems very hostile towards the rest of the organization. They just want to be in their little box and not have to deal with others. They think everything can work out easily just by using Slack. I think they're terribly mis-guided.<p>What I've seen instead is that people tend to try to own their problems instead of asking for help, but daily standups give them a chance to easily mention their issue and for others to help off-handedly. Things that people previously held onto for days are now taking no more than a day to resolve.<p>I think the problem has 2 parts: Ego, and puzzles. Nobody wants to ask for help, and they'd rather solve it themselves. And puzzles are <i>fun</i>. Most of the great developers I've met love working through problems and figuring out a solution, even if it's not an ideal one. The best developers also work past these problems, but nobody is perfect, and standups definitely help.<p>tl;dr - Standups work for us and our team is closer for it.
So many things to say in response to this article but lets start here: "Your standups are killing your velocity."<p>Agile in general is about predictability first and measuring a predictable velocity. Predictable velocity answers a very important question for product management which is "When can we release".<p>Additionally, Agile Methodology touts Cross Functional Teams where each developer is not a specialist in any one area of the product necessarily. The daily standup is a good place to indicate that a dev has run into an obstacle and seek guidance from someone else on the cross functional team who may in fact be the in house expert on that issue.<p>Guidance in this case typically comes in the form of "Oh, XYZ Thing, I built that - the code you're looking for is in /secret/stuff and if you look in there I think you will find what you're looking for".<p>What guidance is not: "Im having trouble with XYZ - will someone else on the team TOTALLY DROP THEIR SPRINT COMMITMENTS AND DO MY JOB FOR ME".<p>Agile and its daily standups are not about increasing velocity. They are about ensuring predictable velocity at the cost of absolute velocity (the max the team may be capable of performing at which itself will vary from sprint to sprint).<p>Now, all that aside, the real value of the daily standup is obviously accountability. That little 15 minute meeting forces a slacker to stand up in front of the rest of the team and clearly indicate that they either are or are not pulling their weight. Used properly it can be a very motivating practice.<p>Perhaps the author works in a place where every team member is a one person gang capable of independently completing any task whatsoever in the bounds of a sprint. In such an environment Agile itself does become a bottleneck. In the prefect world Agile is absolutely unnecessary - but most of us live in a world thats far from perfect.<p>In summary, Agile as a whole and certainly daily standups can and do act as a drag on the velocity of a proficient team. However the purpose of these practices is not to maximize velocity but rather to ensure a floor for velocity such that a team may never achieve its maximum potential but will instead continue to reliably deliver a velocity that is constant and predictable. Think of this as a sort of Productivity Insurance Policy and it makes a lot more sense.<p>*Additionally - I know of no law that restricts a developer from reaching out for assistance/additional guidance immediately on discovery of a blocking issue. The daily standup is just a convenient place where you have a crack at communicating with the whole team in one place. Typically with some manager type lurking quietly on the call like a parent keeping an ear on the kids playing in the other room.
What a strange rant about blockers.<p>Standups are supposed to take a few minutes and everyone becomes aware of what everyone is working on or blocked by. The person that controls the gate should become cognizant that its effecting someone else, and then it gets solved.<p>I love this.<p>I hate when standups are long winded. That removes the usefulness.<p>People dont need to interrupt the whole team and fish out who can help with the blockage, it just comes up and out. Thats the point anyway.<p>I use logs of standups and git commits to track dev progress.
I agree @ stand-ups being useless.<p>I've been on both sides of them: to give information to managers and to get information from people I delegated.<p>Stand-ups tend to turn into a defensive justification for 'being busy', and distracts from the intended purpose of asking for help.<p>At my current job, our manager wastes more time interrupting people during their stand-ups to tell them that they are giving the wrong amount of info "that nobody else cares about", instead of listening or helping.<p>At my previous job, it was used as a way to get people in the office at a certain time.<p>Your peers don't care about what you're working on, they care about sounding busy.
I use standups to check in with everyone and... 1) inform everyone of why I'm making certain product decisions, so that everyone gets a "feel" for the problem space even though they're not directly talking to customers, etc. 2) Talk about a particular problem that wouldn't get discussed as a group if there wasn't time on the calendar every day, such as "where do we need to improve our telemetry" and 3) to just talk to each other for 30 minutes a day.<p>I don't like treating engineers as bug-closing robots and I don't think they like being treated as such. Standup gives everyone the feeling of being on a team of people working towards a common objective.