13 ms·

Why your daily stand-ups don't work and how to fix them

177 points by lucasfcosta 4y ago

ggm 4y ago
I don't agree entirely that the did/doing/next dialogue is bad. It's a well understood phenomena that declaring intent, and reflecting on achievement and pace influences how you approach the problem. This list is good, but it reads like the product of a person with focus and a low tolerance for others with a different pace and style. I can imagine them getting intensely frustrated with slow speakers, rambling PMs (me) and the like. Does this inherently make them "right" or "more productive" -Yes, at the cost of possibly burn out, and the lack of cohesion from ideaologues who cannot listen or engage with others in their problems unless on the kanban, declared as blockers. Its intruding another formalism for the one they don't like. "don't talk to me this way" is a poor basis for mutuality. Maybe its "a little from box A, and a little from box B" ? if 10 minutes of engagement with others causes this much angst, there's a bigger problem in play.
- lucasfcosta 4y ago
  Author here, thanks for your comment, I thought it was really thoughtful and well structured. I don't think the rambling itself is a problem. It will inevitably happen sometimes, and that's fine. It's part of making everyone feel safe. What I'm advocating for in this post is that we shouldn't create structures or formats which actively encourage rambling that does not add to the discussion. Furthermore, if those structures are inefficient (i.e. encourage rambling) and instil fear, you won't have 10 minutes of engagement with others, you'll probably have something like 30 minutes of unproductive technical discussion, which will cause the whole team to stop believing in the stand-up's purpose. That's not to say I disagree with you. I do agree we must find a balance, and that's why I add a few caveats to each of the recommendations, it's just that some practices are more prone to lead to inefficient meetings than others. Thanks again for chiming in with such a detailed and thoughtful piece of feedback.
  - bigiain 4y ago
    FWIW, I mostly agree with your article, but I did find myself rolling my eyes a little when you started out reminding us of the origins of "Agile" and its principles, and criticising the rigid frameworks and practices it's metastasised into, but then the first piece of advice about how to "do it better" is to assume a Kanban board... For me, the "What did you do yesterday? What do you plan to do today? Is there anything blocking you?" questions work pretty well, with the expectation than nobody spends more than about 90 seconds answering all three. (This might just be because places I've recently worked haven't had well groomed or curated Kanban boards, but have had a mid and senior-heavy dev demographic?)
  - ggm 4y ago
    Another side of this is that I hate Jira, which is the kanban I am directed by work to use, so 'talk to the kanban' doesn't work for me personally. I do know highly effective PMs who are living it, and it works for them. I truly believe to do what you propose, you probably have to be a high functional unit workwise. If you are, and you know you are, your suggestions are a laudable goal.
lostdog 4y ago
There is a very easy way to fix standups: Do them twice a week or even once a week. I've never been on a team that was so disorganized that we needed to have a standup every day. I've also never had tasks where you could always make progress in a single day. Meeting once or twice a week matches the meeting frequency to how often things really need communicating (beyond chatting in slack), so the meeting gets used effectively. Meeting every day just trains people to filibuster, and that's a big reason that the meetings stretch out to hours. I do believe there are teams that get blocked on each other every day and who have tasks that take a few hours to finish. Never been on one myself, but I'm sure Scrum works great for them.
- gonzo41 4y ago
  This has been my experience too. Also when working as a manager, It doesn't hurt if your wanting to do standups to just do a 5 minutes catch up with each team member individually before 11am to get your finger on the pulse of whats happening. If they are hitting issues you can do your manager thing.
- jackbrookes 4y ago
  Generally agree, but in my experience there are plenty of times when there are minor changes have been implemented in <1day e.g. changed the behaviour of a button or interaction. The standups let the team know that the change has gone through and the behaviour is intentional
  - mgkimsal 4y ago
    How much overlap between people are there? Last several years, the 'agile' stuff I've worked on with various teams was always individual people working on individual things. Whether my button changed behaviour or not was usually of no concern to anyone else except the product owner, and you can talk with them directly. Spending dev time talking about stuff (or hearing about stuff) you had no control over, or involvement in, was usually time wasteful. This waste wasn't always just the time wasted, but the X minutes before and after to transition in and out of 'meeting' mode. 'Daily standup' of '15 minutes' usually cost me an additional 30-40 minutes of mental time of getting back in to the 'zone' (when I was there).
bergenty 4y ago
Talk about your goals and not your work. What does this even mean? Standup are a report to make sure things are going to be done by the end of sprint. They’re a place to bring up roadblocks and any revisions to estimates. They work really well for what they are.
pressurefree 4y ago
saidinesh5 4y ago
For the last 5-6 years, sending this automated message, once a day, in hipchat/slack/Microsoft teams is what worked well wherever I worked - both semi remote and fully remote places: Good morning! Don’t forget to post your update in thread. Be sure to include: 1. What you worked on yesterday. 2. What you plan on working on today. 3. Any blockers or risks you have identified. People usually reply there whenever they start working, and everyone knows what everyone else is working on. In case of blockers, people who can help get a nice reminder of an upcoming meeting, so they can plan their day accordingly. Honestly, the blockers bit was the only useful thing for most of us there, but it is nice to know what others are working on. Then we have a 30-45 minute video call stand up/review/meeting once every week/sprint, to summarise things and to accommodate for the much needed rambling.
- torvald 4y ago
  I've also have good experiences with this approach. Async by nature, writing it down often helps you actually articulate your problems precisely, and bonus; other teams or stakeholders can skim through the messages getting a situational awareness of what's happening.
- randomdata 4y ago
  > People usually reply there whenever they start working ... Honestly, the blockers bit was the only useful thing for most of us there What kind of blockers were did you find appearing at the start of work for there to be usefulness derived? I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.
  - monster_group 4y ago
    >> Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.
NotTameAntelope 4y ago
Walk the board! If you go person-by-person you’re feeding into the worst parts of standups. Go story by story. If someone isn’t doing anything story related, they’re there to help others if something comes up (and need to be listening) but otherwise would just waste time talking about what they're doing. Be listening to what other people say! See if you can remove or prevent a problem they mention. Say things that matter to others! Give people a shot at clearing your path/making your life easier. If you don’t want a daily standup it’s because you don’t trust your team to be able to help you (or you don’t want to help your team), and that’s a highly solvable problem.
- deleted 4y ago
  [deleted]
- asplake 4y ago
  Walk the board right to left, closest-to-completion first. Focus on finishing!
  - ant6n 4y ago
    This can’t be repeated too much!
- BlargMcLarg 4y ago
  >If you don’t want a daily standup it’s because you don’t trust your team to be able to help you Next up in "Holy generalizations Batman": if you don't use dark mode religiously, you're a terrible programmer. I don't like standups because I trust people to capable of asynchronous communucation and independent, not the other way around. Universal standups are exactly the bandaid I expect from teams unable to figure things out themselves (excluding situations teams want it themselves, hence 'universal'). Let's stop treating people as 'deficient until proven otherwise' for not agreeing with a barely supported methodology, please.
  - deleted 4y ago
    [deleted]
  - 4y ago
paskozdilar 4y ago
The "event-based" paradigm is a useful way to orchestrate software. I wonder why it's not used to orchestrate people. A rule of thumb would be "every meeting must have a reason - an event that lead to it". Why do we even have to have a fixed, recurring meeting? That's equivalent to polling a server periodically and asking "hey, any event happened?" - which is extremely unscalable, and should be done only in situations when malfunction of event-driven mechanics is expected. Same with people - if an employee is trusted, meetings with them should only happen on an event - when there is a change of plans, some new work to be done, et cetera. We have asychronous communication - so why not asychronous organization?
- js8 4y ago
  Because project managers, who invent these things, don't know enough computer science. The next question you might asks is, why other people need to know immediately what other people are working? Why cannot there be a dedicated thread (aka PM) who collects this information and makes it available? Project management would benefit by bringing concepts from operating systems such as scheduling or task switching.
  - paskozdilar 4y ago
    > Project management would benefit by bringing concepts from operating systems such as scheduling or task switching. I agree. Perhaps this is a good time for a Free Software organizational tool, built on such principles.
  - nprateem 4y ago
    Ha ha almost. It should be: Because project managers, who invent these things don't want to make themselves redundant. It's only by pushing the falsehood that the team is so incompetent as to require handholding from someone who likes moving tickets around that they're able to stay in a cushy job.
    - pantulis 4y ago
      Was Agile invented by PMs?
bob1029 4y ago
We have been to all ends of the earth on this sort of thing. The final conclusion I have arrived at: The amount of process and ceremony required is inversely proportional to the trust level on the team. Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant. Team members began to realize that others would simply reach out as needed. Everything is much more async now. Only 3rd party interactions require explicit scheduling these days. Prod down, vendor integrations, etc. Other observations: We seem to somehow spend more time on adhoc calls than our prior scheduled calls, but A Lot More (tm) is getting done regardless. Stress levels seem down as well. Weird how you can have cake and eat it too sometimes. I don’t know if I would sit here and proclaim that process is exclusively a bandaid for lack of trust, but it certainly seems like one indicator of this condition.
- woutr_be 4y ago
  I've had a similar impression in my previous company, this was a large multi-national bank who proclaimed they want to go agile. Spared no expense in hiring agile coaches and scrum masters. It even went as far as some people having two standups a day, one with their own scrum team, and another with the "leaders" of other scrum teams. Our scrum ceremonies were always stretched and highly moderator, except for the one that mattered, the retrospective. This was always hijacked by the agile coach, who pushed his agile believes and wouldn't listen to the actual developers who were trying to improve the process. Obviously following agile to the letter, caused a lot of frustration amongst developers, and lead to almost every project failing. But at least the coaches got paid well.
  - nprateem 4y ago
    IME it's just scrum masters trying to prove their worth. Since they're either non-technical or not close to the tech, they're reduced to robots asking "do you need me to escalate that?", or "so can we move it to done?". I'm sure most scrum masters could be replaced by chatbots. It really gets quite tiresome, especially since if I needed something escalating I'd have asked them already, and I'm perfectly capable of moving a ticket myself. Instead I just disengage for the hour and half of standups I have per day (yes, I know)
pydry 4y ago
I always find standups degenerate into status update meetings no matter how hard I try. The antipattern keeps crawling back. Not sure if it's a quirk of human nature or the protestant work ethic or whatever but the only time I've managed to inhibit it was by being the most senior person in the room and repeatedly pulling rank. An ordinary manager's presence will pretty much guarantee it happens and make it impossible to avoid. Whatever the next iteration of the agile cult is I hope it somehow manages to account for human nature and the nature of typical organizations.
Xcelerate 4y ago
I’ve only worked for two companies in my career as a data scientist. The first one was a large, non-tech company, and we had mountains of “process”—Jira, Agile, stand-ups, training sessions on scrum, etc. I found it difficult to be productive, and I think my teammates did as well. The second company (that I still work for) is a large tech company, and there is almost zero prescribed process (at least for the teams I’ve been on; can’t speak for the entire company). Counterintuitively, everyone seems to be vastly more productive. In terms of process, the most we might do is to put together a loose project roadmap in a Google Doc or something, but that’s about it. There are no stand-ups. Superfluous meetings are discouraged. I have a weekly 1:1 with my manager to ensure my work and goals are aligned with the team priorities. It’s really nice because I feel like I actually have room to breath and get things done rather than attempt to “have something ready” for the standup the next day. At my first company, I arrived there as early as I could in the morning and left after exactly 8 hours. At my current company, I don’t have that desire to finish up the work day as quickly as possible. Although that might also have something to do with the second company rewarding performance and impact much more heavily than the first company—hard to tell how all of these different incentives influences employee psychology and behavior.
- oifjsidjf 4y ago
  Similar experience. We have 2 meetings per week, all in the same day. The rest is intra-teams communication without management butting in. Everyone is extremely productive. Why people think that daily standups are useful is beyond me. 95% of the things in the 2 weekly team meetings that we have is already useless for most people (but having everyone there is useful since otherwise you're just waiting to ping someone to respond, you zone out anyway if the topic is not to your relevance).
- salmonlogs 4y ago
  I briefly worked for a large non-tech corporate in between two FAANG jobs. What really surprised me at the corporate was how much they love to TALK about Agile. We had Agile Coaches, an Agile Centre of Excellence, dedicated Scrum Masters (literally their entire job), Agile Squads to try and improve the Agile Process, mandatory Agile Training and we constantly talked about how things were Agile and if we could be more Agile. They even experimented for a quarter by adding a mandatory agenda item to every single meeting to review how Agile we were and what can be done to be more Agile. We got absolutely nothing done. Progress was glacial, decisions took months, it was painful to do anything. In contrast, at both FAANG tech companies I'm not sure I've ever heard someone say the word Agile directly. It just happens by default, no ceremony and rigour required. Shit gets done, at pace, and people are excited and motivated to do it.
jukvalim 4y ago
Stand-ups and other Scrum rituals are for a team kind of like routines and habits of a person's life; tinkering with them until they help you and make you happy is well worth the trouble. They can also serve more than one purpose. I'm the SM/tech lead of our team. Here's how we do stand-ups. It's mostly a result of me suggesting things (I'm also soliciting ideas from others, but they don't seem to have quite the interest in tinkering with these things I do), trying it out with the team, seeing the results, getting feedback and iterating. 1) Before the stand-up, we all write a few sentences on team chat about what we've been working on, what we plan on doing today, and problems/things to discuss. This means we avoid "the round" and the problems associated with it, gives a broad picture of the situation to team members and provides a nice log for later if needed. 2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around. This is on purpose, which I haven't told the others. It's not like it's a secret, it just hasn't come up. It's to make the team comfortable with each other and provide light social interaction, which is important in a remote team. Also to make the whole thing a bit more fun, which is a shared interest of everybody. I try to make everyone feel included here. 3) At the beginning I usually go quickly through what is overall situation, based on the chat messages. I note problems and things to discuss that are written there. Then we go over them together relatively quickly; if they don't need to involve the whole team and take more than a few minutes to discuss, they're usually tabled off for the relevant people to discuss after the daily. Before moving on, I also ask if there's any other issues to talk about, and we treat those the same as issues written out beforehand. Once we run out of things to talk about with the whole team, we end the daily. Usually it's pretty short, less than 15 mins, but if it takes longer, it will not be because of boilerplate; it will be because there's things we need to discuss as a team, and since we're already together, might as well do it immediately. 4) After the daily, we often continue interacting, just not everybody together; after all, it's a break in coding flow/focus anyway, so might as well batch the "meetingy" things together. One common thing we do after daily is a live code review over video chat, if anybody happens to have a PR ready. It has different pros and cons than an asynchronous code review; we mix and match both. We also don't do the daily on Wednesdays and avoid scheduling other meetings on that day - it's our "deep work day". This way of doing things works for us; the daily stand-up provides cadence to our work, allows us to coordinate and share information and to interact as people. But if one of us has an idea on how to do things better, we can try it out and keep it if works. This works for us; for another team and situation, something completely different may be in order. Complaining about stand-ups is a common topic among developers, but I wonder how many try to change the way their team does them? Scrum provides the sprint retrospective as an opportunity for all to improve the team's ways of working; that's what it's for. Maybe your team is incapable of change due to authoritarianism or top-down process thinking, but that's a conclusion you reach after you've tried and failed to change things using your social and political skills. These skills include expressing your concerns clearly and avoiding blame, listing the potential benefits of the new way of doing things, listening and understanding different interests people have and balancing them, and framing new ways as experiments that the team can change back if they don't work.
mamoriamohit 4y ago
I have been building and managing remote (+ async) teams since 2018 (way before pandemic), and the biggest breakthrough came in only after a year of struggles. The breakthrough was: Spend 10x more time evaluating cultural fit, and you'll spend 10x less time managing people. This allowed me to simply trust every single person, and let go of the processes and daily meetings/standups, etc. Simply trusting + communicating in weekly timelines kept everybody calm and productive.
- NotTameAntelope 4y ago
  This presupposes standups were for you (the manager) in the first place, but they were/are not. They're for the developers to keep in sync. For tiny teams (1-2 developers) that's trivial and doesn't need a shared conversation. For 3+ people to try and keep in sync, it's easier if they all get together. Sure, they can stay in sync other ways, but it's more likely that you lose productivity to people de-doing work, having trouble integrating, and losing out on developer experience when someone takes on a new problem. The real red flag here is that your team doesn't want to talk to one another on a daily cadence. Sounds like a team that isn't really a team, to me, just a bunch of individual developers being managed by the same person. Teams >>> individuals, every time.
ddmichael 4y ago
Just do an optional text update for f** sake. If you don't trust your people, don't hire them in the first place.
- beeboop 4y ago
  The unfortunate situation at a lot of places is that there can be tight budget constraints which impacts the caliber of people they hire and how diligently they hold current employees accountable. Not everyone is paying Google salaries for developers, which means you work with a team of very junior devs, or senior devs that have a small chip on their shoulder and are difficult to work with, but are affordable and still get work done. Yeah it sucks to work in these environments, but for the mediocre to average PM or developer, it's a place to start a career before moving to better circumstances.
schlowmo 4y ago
> “We have flexible working hours”, they say. Sure, but there’s also a stand-up meeting at exactly 8:30 AM to ensure everyone will be online early. This is the thing about daily stand-ups which I hate the most. I work as a freelancer which requires me to do a dance around social expectation everytime I get on with a new project. Oftentimes I work with full remote internal teams which are used to dailies in the morning, even when a substantial number of team members hate them. The (private) feedback I get when I'm the one who tries to reschedule them later in the day at the kick-off meeting is very astonishing. I simply don't get why even many relaxed employers don't realize that dailies in the (early) morning can be a very good way to reduce overall productivity and sometimes even set wrong incentives. I know a good share of employed people who only came to terms with early stand-ups because it means they can clock in early without doing any meaningful work for the first hours of the workday. But I think it's just fair that those employers with proclaimed "flexible hours" pay them for involuntary getting up before their time. Make me get up early, pay for my breakfast time. Or just stop pretending that you have flexible hours.
- flosstop 4y ago
  I see the early stand-up in a different way. I don't derive anything other than interruption and inconvenience from a stand-up so I'd rather get it out of the way first thing then I can get on with my work for the rest of the day without interruption.
  - hnfong 4y ago
    It can be done before lunch time
  - Silhouette 4y ago
    One problem with daily meetings is that the two of you are making reasonable and yet incompatible arguments here. You can't have a meeting at the same time every day that is both conveniently out of the way for those who want large blocks of time free for real work and conveniently in the middle of likely working times for those who prefer flexibility. Personally I think the solution to this is obvious and apparently so do many others here. Daily standups within a mostly stable and well-functioning team are almost always redundant at best and actively disruptive at worst. So don't have daily standups. Instead work on a culture where people communicate freely whenever they need to and you bring people together for larger and longer meetings when (and only when) you have a specific reason for that.
starwatch 4y ago
I'm a strong believer in minimum viable process when it comes to team management. As teams grow, processes need to grow with them. But imo every process - stand-ups included - should be introduced as an experiment. The experiments should have a clear hypothesis, and a period of evaluation. The evaluation should be conducted by anyone who is expected to participate in or benefit from the process. If process experiments don't work - take lessons and throw out the process. Our current stand-up has evolved[1] to people posting their done/doing/blockers in Slack each day. We still have a daily 15 minute zoom meeting - which was once a stand-up - but it's changed. Now it's a time-boxed meeting where we shoot the breeze, or play small multiplayer games [2]. The rules are simple - no work chat, no politics. We meet in the middle of the day so people have the morning period to get work done. Our stand-up wouldn't work for all teams. We've specifically hired people that would work well in our team - and they're thus more inclined to work well with the processes we've developed. [1]: I wrote a bit about this at https://blog.getchinwag.com/posts/calling-all-remote-teams-stand-up-meetings-dont-wfh/ https://blog.getchinwag.com/posts/calling-all-remote-teams-s... - though our stand-up has continued to evolve. [2]: Assembling jigsaws has proven to be quite fun in recent weeks - we use https://puzzlegarage.com/ https://puzzlegarage.com/
- wreath 4y ago
  > no politics. This in itself is an achievement.
  - atonse 4y ago
    I instituted the same rule in our slack. No politics. It helps to do it early on in the company. We’ve (so far) never had a political debate. Hope it stays that way Forever.
    - starwatch 4y ago
      We did have some political discussion but agreed it wasn't a net positive contribution to the culture we wanted to form. So we experimented with a no-politics rule and it stuck.
psi75 4y ago
No, they work as designed. The question is: who really designed them? If Agile actually empowered workers, management would ban it. Management took the relatively sensible directives of "the Agile Manifesto" and turned it into a vehicle through which they could shove Taylorism down everyone's throat. It's a status meeting. It's not supposed to be, but status meetings are good for managers and bad for workers and so they're not going anywhere. Capitalism would be bad enough if managers actually did care about "the company" or their shareholders, but it's simpler and more degenerate than that. They are optimizing for their own careers. It isn't more complex than that. The "bureaucratic culture of fear" suits them well. The weaponized standup is great for them; toward their real aims, it works beautifully, because it's basically thunderdome in its ability to make workers slug each other and terrorize those seen as least productive. "Agile" is a case-in-point where engineers, being intellectually intelligent but socially imbecilic, assumed good faith on the part of the people managing them and came up with a framework to make those good-hearted managers' lives and jobs easier... but, of course, the people above were not good-hearted and so any components of these methodologies that actually empowered working people got ripped out while still allowing the bosses to say, "Well, you asked for this."
- commandlinefan 4y ago
  > Capitalism would be bad enough You do realize that the only alternative to capitalism that's ever been proposed is Scrum for everything inside and outside of work?
snidane 4y ago
Your goal as a manager is to maintain flow - provided that you hired competent people. When you lose it and you feel the blame starts shifting your way your tendency is to set up more control and visibility. Here comes the daily standup and jira board of tasks. You lose even more flow as yoir team spends majority of time estimating and administering tasks in real time so that when you look at it once a week, it is semi-up to date. What you were looking for in the first place were to discover obstructions to the flow and finding process bottlenecks. You want to find out that one person that everything depends on to move and everybody slamming them with tasks and now the extra task tracking. You want to find out why that important task is not getting finished because the person is getting blocked on some infra problem and instead of reporting the blockage to you they pick up another task from the queue. Why would they report that if the only thikg you desire reported is what everybody ia working on - the important blocked people will always tell you they are busy enough as they found something else to work on. As a manager, how are you expecting to get any outcome if you never find the workplace bottlenecks and you only demand pople to get busy.
- nuclearnice1 4y ago
  > You want to find out why that important task is not getting finished because the person is getting blocked on some infra problem and instead of reporting the blockage to you they pick up another task from the queue. I think blocked on a high priority task is exactly what scrum with daily standup is sold as surfacing.
  - mgkimsal 4y ago
    > I think blocked on a high priority task is exactly what scrum with daily standup is sold as surfacing. A 'daily standup' seems sort of the lowest-common-denominator way of surfacing that. someone recognizing on their own, and reaching out to raise a flag is one way. 1-1 checkins more frequently with those working on larger items would be another.
    - nuclearnice1 4y ago
      > lowest-common-denominator way Well said and exactly the psychological state one feels when participating. > someone recognizing on their own, and reaching out to raise a flag is one way. 100% agree Note that the OP has this blocked developer not announcing the block of a high priority item, but rather just pulling another item from the queue and making progress. Depends on the person and the instructions, but I guess it happens. 1-1 also makes sense to me. That said, I can picture the manager after back and forth playing telephone with blockee sand blockers, believing that an efficient way to handle this is to have all the relevant people in one spot.
zabil 4y ago
In teams I've been a part of, I found a 15 minute everyday stand up to be a nice way to build rapport. We don't use it for planning or detailed discussions. We don't insist on a standup structure, or what must be discussed etc. We just find it useful for greeting each other, sharing context and checking if anybody needs help. We experimented having no standups(to be completely asynchronous), but we didn't like that and felt it's worth the effort to catch up once a day.
- Kaze404 4y ago
  +1 to this. I find that a 15 minute stand up at the very least lets me see my coworkers, and I get so much out of just saying hi and hearing it back.
- ishwarn 4y ago
  This is similar to what we do at Abl. We use a Slackbot to ask everyone for a written standup update, answering a few questions: - What did you do on your last working day? - What are you doing today? - Are you blocked? - Would you like a conversation with anyone (to get unblocked or anything else)? - Any announcements, like PTO? And that gets posted in Slack at a certain time. The goal of this is transparency for what folks are working on, giving people the opportunity to raise blockers, and announcements. We then have a scheduled 15 minutes a day to just hang. We have a check-in question that's not work related and we use the time to socially connect. We are a fully remote company that used to be in-office, and we found the opportunities to build & grow these connections are not available in a remote + scheduled Zoom world like they were in office.
  - thunky 4y ago
    > We then have a scheduled 15 minutes a day to just hang This sounds awful to me. Not sure why it would ever need to come to that: forcing people into a room every day and telling them to connect with each other. It just seems forced and phony. You already work together full time, and I assume you interact with each other as a normal part of your work? If not, maybe you aren't really on the same team, in which case why not invite accounting and HR into your social time?
kampsduac 4y ago
As a distributed team, I like the live interaction our daily standup provides. To stay focused on blockers, we share the yesterday/today portion of the update in Slack. This leaves our 10 minute stand up as a convenient forum for announcements and some virtual hallway conversation.
deleted 4y ago
[deleted]
kitsune_ 4y ago
If you want to fix these issues in the context of Scrum I suggest J. Coplien's "A Scrum Book". Or you can just read the patterns here: https://sites.google.com/a/scrumplop.org/published-patterns/home https://sites.google.com/a/scrumplop.org/published-patterns/... - The book is a slightly reworked reprint of the pattern work done by that group of people. It follows the pattern work by Christopher Alexander [1]. The patterns form a cohesive interlinked language that provides context for each pattern. Here is what it says about the Daily Scrum: https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/sprint/daily-scrum https://sites.google.com/a/scrumplop.org/published-patterns/... There some useful patterns that might even make sense outside of Scrum on there. Anyways, framing approaches and solutions in a cohesive pattern language is intriguing in its own right in my opinion. [1] https://en.wikipedia.org/wiki/Christopher_Alexander https://en.wikipedia.org/wiki/Christopher_Alexander
qaq 4y ago
You should start by implementing SAFe obviously :) https://www.scaledagileframework.com/ https://www.scaledagileframework.com/
- kingboss 4y ago
  I am a genius! I have invented the agile-waterfall method. Bring on the release train choo-choo!
  - qaq 4y ago
    On the positive side look at how many high paying useless jobs SAFe creates :)
alberth 4y ago
Off topic: I see folks in the comments talk about async communication. What I don’t understand about the async crowd is why then do you get mad when I email at 9pm at night, or I email on the weekend. I’m not asking for an immediate reply, that’s the entire point of async (for you to reply on your own terms/time).
- ipaddr 4y ago
  Who gets mad at an email not viewed? If there is an expectation of responding immediately that breaks async people get mad. I have no ideas what emails came in over the weekend.. we will find out when the time is right
  - alberth 4y ago
    So you agree, disagree? I’m confused.
    - ipaddr 4y ago
      If a call to action exists the receiver will get mad at the 9pm email. I also know that an email not checked by the receiver they won't be mad. What I don't know is the senders expectations of when the email should be checked.
- RegW 4y ago
  I think this is using the term "asynchrouously" where others might use "off-line". When the meeting turns up a problem that isn't going to be resolved in a few words, you might prompt those involved/interested to organise a specific meeting rather than bore the rest. However, "Can we take that off-line?" can also come to mean "Stop bringing problems!" :-)
- Kaze404 4y ago
  Do they? At work we tend to encourage async communication, and one of the first things I heard when I started is that I might get emails / messages outside of working hours but there was no expectation that I'd read them, or reply if I did.
NonNefarious 4y ago
"The software industry has been doing daily stand-ups for so long that it doesn’t remember why they exist" I've been a professional developer at one major software company after another (including ones that have tried SCRUM) since the '90s, and never heard the term "stand-up" at work until last year. That's a broadcast-news term as far as I'm concerned. Maybe they've been doing them but not calling them that.
- nivertech 4y ago
  > "The software industry has been doing daily stand-ups for so long that it doesn’t remember why they exist" That's so wrong. I worked at medium to large tech co. since late 90s, and only team leads attended regular meetings. Normal devs only attended very infrequent all-hands meeting (monthly at small companies, or quarterly at large). Of-course we had meetings, but they weren't dailies, but with specific agenda (e.g. design review, bugs, org. announcement, HR, etc.)
sodapopcan 4y ago
I like standup as a means of coming together as a team before starting the day, and only if your team is into that kind of thing. It shouldn't be a status report. If your manager needs a daily status report, that can be done async, I hate sitting around listening to my colleague list off every little thing they did the day before.
Clubber 4y ago
Stop making them daily. I see the author sticks to the dogma of a daily meeting of some sort. We have a 30 minute biz meeting followed by a 30 minute dev meeting weekly. We communicate by phone/teams/email when we need to.
lamontcg 4y ago
What I've found is pretty useless is manager-driven daily standups where the purpose is to go through all the items and get detailed status updates. I sort of infer that this happens through a broader management culture where managers get pop quizzes at meetings all week long where they have to be able to appear like they have the finger on the pulse of exactly what their reports are doing, which produces downwards pressure to micromanage. Even if they aren't micromanaging, it becomes this daily quiz so that the manager knows exactly what is going on. What was pretty useful was when daily standups were more IC driven and it was perfectly fine to say "yep, I'm working on the same thing I was doing yesterday" at least half the time. In those kinds of standups the Manager will typically bring broader concerns to the team that might have happened in the past 24h, rather than using the standup to quiz the team on what they're doing. The manager of course also gets to just give their own status as "meetings, meetings, meetings" and keep it short. In those cases we didn't even go through the Kanban board or have it open during the meeting, since everyone understood that you only have one or two things you're typically working on and your status is either that you're working on the same thing as yesterday or something is done and you're picking up something else. In some cases someone would be stuck or some issue would have come up, but this would usually result in two ICs taking over the zoom chat after 15 minutes and letting everyone else drop off. For brand new team members or junior devs this still works basically the same way but there would usually a bit more heavy use of after-meeting zoom chats or async chats afterwards. The formalism of doing it every day does work, particularly with remote teams, just to have a little bit of face to face time, and spur those after meeting or async zoom chats. But it needs to be kept lightweight and focused on developer-productivity and doesn't use any kind of issue board most days.
bitwidget 4y ago
I personally feel like daily standups are pretty important, contrary to what some people are commenting. Sure there are teams where they don't have any schedule meetings, but having that morning standup for 15-20 minutes each morning does a lot more than people think. I get to see what everyone else is currently working on and offer help if anyone says they have blockers. It works vice-versa as well, I sometimes run into issues and anyone on my team can pitch in, instead of me messaging individual people asking if they've seen that issue before. Even if all the above doesn't apply, I still get to talk and socialize with my entire team for 15 minutes, barely any productivity loss. Although I would have to agree with all the Agile/Scrum meetings comments here. I work at a very large insurance company and we have a dedicated Scrum Master. We have several meetings a week, each at least an hour with things like Retros, Backlog grooming, Planning, etc. These are the meetings that provide very little value while also taking a huge chunk out of my productivity.
SergeAx 4y ago
God knows how I am tired of those "insightful" let-me-tell-you-what-you-should-do headlines. Our stand-ups are working fine, there's nothing to be fixed. Thank you very much and good bye.

177 points by lucasfcosta 4y ago

ggm 4y ago

I don't agree entirely that the did/doing/next dialogue is bad. It's a well understood phenomena that declaring intent, and reflecting on achievement and pace influences how you approach the problem. This list is good, but it reads like the product of a person with focus and a low tolerance for others with a different pace and style. I can imagine them getting intensely frustrated with slow speakers, rambling PMs (me) and the like. Does this inherently make them "right" or "more productive" -Yes, at the cost of possibly burn out, and the lack of cohesion from ideaologues who cannot listen or engage with others in their problems unless on the kanban, declared as blockers. Its intruding another formalism for the one they don't like. "don't talk to me this way" is a poor basis for mutuality. Maybe its "a little from box A, and a little from box B" ? if 10 minutes of engagement with others causes this much angst, there's a bigger problem in play.

lucasfcosta 4y ago
Author here, thanks for your comment, I thought it was really thoughtful and well structured. I don't think the rambling itself is a problem. It will inevitably happen sometimes, and that's fine. It's part of making everyone feel safe. What I'm advocating for in this post is that we shouldn't create structures or formats which actively encourage rambling that does not add to the discussion. Furthermore, if those structures are inefficient (i.e. encourage rambling) and instil fear, you won't have 10 minutes of engagement with others, you'll probably have something like 30 minutes of unproductive technical discussion, which will cause the whole team to stop believing in the stand-up's purpose. That's not to say I disagree with you. I do agree we must find a balance, and that's why I add a few caveats to each of the recommendations, it's just that some practices are more prone to lead to inefficient meetings than others. Thanks again for chiming in with such a detailed and thoughtful piece of feedback.
- bigiain 4y ago
  FWIW, I mostly agree with your article, but I did find myself rolling my eyes a little when you started out reminding us of the origins of "Agile" and its principles, and criticising the rigid frameworks and practices it's metastasised into, but then the first piece of advice about how to "do it better" is to assume a Kanban board... For me, the "What did you do yesterday? What do you plan to do today? Is there anything blocking you?" questions work pretty well, with the expectation than nobody spends more than about 90 seconds answering all three. (This might just be because places I've recently worked haven't had well groomed or curated Kanban boards, but have had a mid and senior-heavy dev demographic?)
- ggm 4y ago
  Another side of this is that I hate Jira, which is the kanban I am directed by work to use, so 'talk to the kanban' doesn't work for me personally. I do know highly effective PMs who are living it, and it works for them. I truly believe to do what you propose, you probably have to be a high functional unit workwise. If you are, and you know you are, your suggestions are a laudable goal.

lostdog 4y ago

There is a very easy way to fix standups: Do them twice a week or even once a week. I've never been on a team that was so disorganized that we needed to have a standup every day. I've also never had tasks where you could always make progress in a single day. Meeting once or twice a week matches the meeting frequency to how often things really need communicating (beyond chatting in slack), so the meeting gets used effectively. Meeting every day just trains people to filibuster, and that's a big reason that the meetings stretch out to hours. I do believe there are teams that get blocked on each other every day and who have tasks that take a few hours to finish. Never been on one myself, but I'm sure Scrum works great for them.

gonzo41 4y ago
This has been my experience too. Also when working as a manager, It doesn't hurt if your wanting to do standups to just do a 5 minutes catch up with each team member individually before 11am to get your finger on the pulse of whats happening. If they are hitting issues you can do your manager thing.
jackbrookes 4y ago
Generally agree, but in my experience there are plenty of times when there are minor changes have been implemented in <1day e.g. changed the behaviour of a button or interaction. The standups let the team know that the change has gone through and the behaviour is intentional
- mgkimsal 4y ago
  How much overlap between people are there? Last several years, the 'agile' stuff I've worked on with various teams was always individual people working on individual things. Whether my button changed behaviour or not was usually of no concern to anyone else except the product owner, and you can talk with them directly. Spending dev time talking about stuff (or hearing about stuff) you had no control over, or involvement in, was usually time wasteful. This waste wasn't always just the time wasted, but the X minutes before and after to transition in and out of 'meeting' mode. 'Daily standup' of '15 minutes' usually cost me an additional 30-40 minutes of mental time of getting back in to the 'zone' (when I was there).

bergenty 4y ago

Talk about your goals and not your work. What does this even mean? Standup are a report to make sure things are going to be done by the end of sprint. They’re a place to bring up roadblocks and any revisions to estimates. They work really well for what they are.

pressurefree 4y ago

saidinesh5 4y ago

For the last 5-6 years, sending this automated message, once a day, in hipchat/slack/Microsoft teams is what worked well wherever I worked - both semi remote and fully remote places: Good morning! Don’t forget to post your update in thread. Be sure to include: 1. What you worked on yesterday. 2. What you plan on working on today. 3. Any blockers or risks you have identified. People usually reply there whenever they start working, and everyone knows what everyone else is working on. In case of blockers, people who can help get a nice reminder of an upcoming meeting, so they can plan their day accordingly. Honestly, the blockers bit was the only useful thing for most of us there, but it is nice to know what others are working on. Then we have a 30-45 minute video call stand up/review/meeting once every week/sprint, to summarise things and to accommodate for the much needed rambling.

torvald 4y ago
I've also have good experiences with this approach. Async by nature, writing it down often helps you actually articulate your problems precisely, and bonus; other teams or stakeholders can skim through the messages getting a situational awareness of what's happening.
randomdata 4y ago
> People usually reply there whenever they start working ... Honestly, the blockers bit was the only useful thing for most of us there What kind of blockers were did you find appearing at the start of work for there to be usefulness derived? I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.
- monster_group 4y ago
  >> Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around. You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.

NotTameAntelope 4y ago

Walk the board! If you go person-by-person you’re feeding into the worst parts of standups. Go story by story. If someone isn’t doing anything story related, they’re there to help others if something comes up (and need to be listening) but otherwise would just waste time talking about what they're doing. Be listening to what other people say! See if you can remove or prevent a problem they mention. Say things that matter to others! Give people a shot at clearing your path/making your life easier. If you don’t want a daily standup it’s because you don’t trust your team to be able to help you (or you don’t want to help your team), and that’s a highly solvable problem.

deleted 4y ago
[deleted]
asplake 4y ago
Walk the board right to left, closest-to-completion first. Focus on finishing!
- ant6n 4y ago
  This can’t be repeated too much!
BlargMcLarg 4y ago
>If you don’t want a daily standup it’s because you don’t trust your team to be able to help you Next up in "Holy generalizations Batman": if you don't use dark mode religiously, you're a terrible programmer. I don't like standups because I trust people to capable of asynchronous communucation and independent, not the other way around. Universal standups are exactly the bandaid I expect from teams unable to figure things out themselves (excluding situations teams want it themselves, hence 'universal'). Let's stop treating people as 'deficient until proven otherwise' for not agreeing with a barely supported methodology, please.
- deleted 4y ago
  [deleted]
- 4y ago

paskozdilar 4y ago

The "event-based" paradigm is a useful way to orchestrate software. I wonder why it's not used to orchestrate people. A rule of thumb would be "every meeting must have a reason - an event that lead to it". Why do we even have to have a fixed, recurring meeting? That's equivalent to polling a server periodically and asking "hey, any event happened?" - which is extremely unscalable, and should be done only in situations when malfunction of event-driven mechanics is expected. Same with people - if an employee is trusted, meetings with them should only happen on an event - when there is a change of plans, some new work to be done, et cetera. We have asychronous communication - so why not asychronous organization?

js8 4y ago
Because project managers, who invent these things, don't know enough computer science. The next question you might asks is, why other people need to know immediately what other people are working? Why cannot there be a dedicated thread (aka PM) who collects this information and makes it available? Project management would benefit by bringing concepts from operating systems such as scheduling or task switching.
- paskozdilar 4y ago
  > Project management would benefit by bringing concepts from operating systems such as scheduling or task switching. I agree. Perhaps this is a good time for a Free Software organizational tool, built on such principles.
- nprateem 4y ago
  Ha ha almost. It should be: Because project managers, who invent these things don't want to make themselves redundant. It's only by pushing the falsehood that the team is so incompetent as to require handholding from someone who likes moving tickets around that they're able to stay in a cushy job.
  - pantulis 4y ago
    Was Agile invented by PMs?

bob1029 4y ago

We have been to all ends of the earth on this sort of thing. The final conclusion I have arrived at: The amount of process and ceremony required is inversely proportional to the trust level on the team. Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant. Team members began to realize that others would simply reach out as needed. Everything is much more async now. Only 3rd party interactions require explicit scheduling these days. Prod down, vendor integrations, etc. Other observations: We seem to somehow spend more time on adhoc calls than our prior scheduled calls, but A Lot More (tm) is getting done regardless. Stress levels seem down as well. Weird how you can have cake and eat it too sometimes. I don’t know if I would sit here and proclaim that process is exclusively a bandaid for lack of trust, but it certainly seems like one indicator of this condition.

woutr_be 4y ago
I've had a similar impression in my previous company, this was a large multi-national bank who proclaimed they want to go agile. Spared no expense in hiring agile coaches and scrum masters. It even went as far as some people having two standups a day, one with their own scrum team, and another with the "leaders" of other scrum teams. Our scrum ceremonies were always stretched and highly moderator, except for the one that mattered, the retrospective. This was always hijacked by the agile coach, who pushed his agile believes and wouldn't listen to the actual developers who were trying to improve the process. Obviously following agile to the letter, caused a lot of frustration amongst developers, and lead to almost every project failing. But at least the coaches got paid well.
- nprateem 4y ago
  IME it's just scrum masters trying to prove their worth. Since they're either non-technical or not close to the tech, they're reduced to robots asking "do you need me to escalate that?", or "so can we move it to done?". I'm sure most scrum masters could be replaced by chatbots. It really gets quite tiresome, especially since if I needed something escalating I'd have asked them already, and I'm perfectly capable of moving a ticket myself. Instead I just disengage for the hour and half of standups I have per day (yes, I know)

pydry 4y ago

I always find standups degenerate into status update meetings no matter how hard I try. The antipattern keeps crawling back. Not sure if it's a quirk of human nature or the protestant work ethic or whatever but the only time I've managed to inhibit it was by being the most senior person in the room and repeatedly pulling rank. An ordinary manager's presence will pretty much guarantee it happens and make it impossible to avoid. Whatever the next iteration of the agile cult is I hope it somehow manages to account for human nature and the nature of typical organizations.

Xcelerate 4y ago

I’ve only worked for two companies in my career as a data scientist. The first one was a large, non-tech company, and we had mountains of “process”—Jira, Agile, stand-ups, training sessions on scrum, etc. I found it difficult to be productive, and I think my teammates did as well. The second company (that I still work for) is a large tech company, and there is almost zero prescribed process (at least for the teams I’ve been on; can’t speak for the entire company). Counterintuitively, everyone seems to be vastly more productive. In terms of process, the most we might do is to put together a loose project roadmap in a Google Doc or something, but that’s about it. There are no stand-ups. Superfluous meetings are discouraged. I have a weekly 1:1 with my manager to ensure my work and goals are aligned with the team priorities. It’s really nice because I feel like I actually have room to breath and get things done rather than attempt to “have something ready” for the standup the next day. At my first company, I arrived there as early as I could in the morning and left after exactly 8 hours. At my current company, I don’t have that desire to finish up the work day as quickly as possible. Although that might also have something to do with the second company rewarding performance and impact much more heavily than the first company—hard to tell how all of these different incentives influences employee psychology and behavior.

oifjsidjf 4y ago
Similar experience. We have 2 meetings per week, all in the same day. The rest is intra-teams communication without management butting in. Everyone is extremely productive. Why people think that daily standups are useful is beyond me. 95% of the things in the 2 weekly team meetings that we have is already useless for most people (but having everyone there is useful since otherwise you're just waiting to ping someone to respond, you zone out anyway if the topic is not to your relevance).
salmonlogs 4y ago
I briefly worked for a large non-tech corporate in between two FAANG jobs. What really surprised me at the corporate was how much they love to TALK about Agile. We had Agile Coaches, an Agile Centre of Excellence, dedicated Scrum Masters (literally their entire job), Agile Squads to try and improve the Agile Process, mandatory Agile Training and we constantly talked about how things were Agile and if we could be more Agile. They even experimented for a quarter by adding a mandatory agenda item to every single meeting to review how Agile we were and what can be done to be more Agile. We got absolutely nothing done. Progress was glacial, decisions took months, it was painful to do anything. In contrast, at both FAANG tech companies I'm not sure I've ever heard someone say the word Agile directly. It just happens by default, no ceremony and rigour required. Shit gets done, at pace, and people are excited and motivated to do it.

jukvalim 4y ago

Stand-ups and other Scrum rituals are for a team kind of like routines and habits of a person's life; tinkering with them until they help you and make you happy is well worth the trouble. They can also serve more than one purpose. I'm the SM/tech lead of our team. Here's how we do stand-ups. It's mostly a result of me suggesting things (I'm also soliciting ideas from others, but they don't seem to have quite the interest in tinkering with these things I do), trying it out with the team, seeing the results, getting feedback and iterating. 1) Before the stand-up, we all write a few sentences on team chat about what we've been working on, what we plan on doing today, and problems/things to discuss. This means we avoid "the round" and the problems associated with it, gives a broad picture of the situation to team members and provides a nice log for later if needed. 2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around. This is on purpose, which I haven't told the others. It's not like it's a secret, it just hasn't come up. It's to make the team comfortable with each other and provide light social interaction, which is important in a remote team. Also to make the whole thing a bit more fun, which is a shared interest of everybody. I try to make everyone feel included here. 3) At the beginning I usually go quickly through what is overall situation, based on the chat messages. I note problems and things to discuss that are written there. Then we go over them together relatively quickly; if they don't need to involve the whole team and take more than a few minutes to discuss, they're usually tabled off for the relevant people to discuss after the daily. Before moving on, I also ask if there's any other issues to talk about, and we treat those the same as issues written out beforehand. Once we run out of things to talk about with the whole team, we end the daily. Usually it's pretty short, less than 15 mins, but if it takes longer, it will not be because of boilerplate; it will be because there's things we need to discuss as a team, and since we're already together, might as well do it immediately. 4) After the daily, we often continue interacting, just not everybody together; after all, it's a break in coding flow/focus anyway, so might as well batch the "meetingy" things together. One common thing we do after daily is a live code review over video chat, if anybody happens to have a PR ready. It has different pros and cons than an asynchronous code review; we mix and match both. We also don't do the daily on Wednesdays and avoid scheduling other meetings on that day - it's our "deep work day". This way of doing things works for us; the daily stand-up provides cadence to our work, allows us to coordinate and share information and to interact as people. But if one of us has an idea on how to do things better, we can try it out and keep it if works. This works for us; for another team and situation, something completely different may be in order. Complaining about stand-ups is a common topic among developers, but I wonder how many try to change the way their team does them? Scrum provides the sprint retrospective as an opportunity for all to improve the team's ways of working; that's what it's for. Maybe your team is incapable of change due to authoritarianism or top-down process thinking, but that's a conclusion you reach after you've tried and failed to change things using your social and political skills. These skills include expressing your concerns clearly and avoiding blame, listing the potential benefits of the new way of doing things, listening and understanding different interests people have and balancing them, and framing new ways as experiments that the team can change back if they don't work.

mamoriamohit 4y ago

I have been building and managing remote (+ async) teams since 2018 (way before pandemic), and the biggest breakthrough came in only after a year of struggles. The breakthrough was: Spend 10x more time evaluating cultural fit, and you'll spend 10x less time managing people. This allowed me to simply trust every single person, and let go of the processes and daily meetings/standups, etc. Simply trusting + communicating in weekly timelines kept everybody calm and productive.

NotTameAntelope 4y ago
This presupposes standups were for you (the manager) in the first place, but they were/are not. They're for the developers to keep in sync. For tiny teams (1-2 developers) that's trivial and doesn't need a shared conversation. For 3+ people to try and keep in sync, it's easier if they all get together. Sure, they can stay in sync other ways, but it's more likely that you lose productivity to people de-doing work, having trouble integrating, and losing out on developer experience when someone takes on a new problem. The real red flag here is that your team doesn't want to talk to one another on a daily cadence. Sounds like a team that isn't really a team, to me, just a bunch of individual developers being managed by the same person. Teams >>> individuals, every time.

ddmichael 4y ago

Just do an optional text update for f** sake. If you don't trust your people, don't hire them in the first place.

beeboop 4y ago
The unfortunate situation at a lot of places is that there can be tight budget constraints which impacts the caliber of people they hire and how diligently they hold current employees accountable. Not everyone is paying Google salaries for developers, which means you work with a team of very junior devs, or senior devs that have a small chip on their shoulder and are difficult to work with, but are affordable and still get work done. Yeah it sucks to work in these environments, but for the mediocre to average PM or developer, it's a place to start a career before moving to better circumstances.

schlowmo 4y ago

> “We have flexible working hours”, they say. Sure, but there’s also a stand-up meeting at exactly 8:30 AM to ensure everyone will be online early. This is the thing about daily stand-ups which I hate the most. I work as a freelancer which requires me to do a dance around social expectation everytime I get on with a new project. Oftentimes I work with full remote internal teams which are used to dailies in the morning, even when a substantial number of team members hate them. The (private) feedback I get when I'm the one who tries to reschedule them later in the day at the kick-off meeting is very astonishing. I simply don't get why even many relaxed employers don't realize that dailies in the (early) morning can be a very good way to reduce overall productivity and sometimes even set wrong incentives. I know a good share of employed people who only came to terms with early stand-ups because it means they can clock in early without doing any meaningful work for the first hours of the workday. But I think it's just fair that those employers with proclaimed "flexible hours" pay them for involuntary getting up before their time. Make me get up early, pay for my breakfast time. Or just stop pretending that you have flexible hours.

flosstop 4y ago
I see the early stand-up in a different way. I don't derive anything other than interruption and inconvenience from a stand-up so I'd rather get it out of the way first thing then I can get on with my work for the rest of the day without interruption.
- hnfong 4y ago
  It can be done before lunch time
- Silhouette 4y ago
  One problem with daily meetings is that the two of you are making reasonable and yet incompatible arguments here. You can't have a meeting at the same time every day that is both conveniently out of the way for those who want large blocks of time free for real work and conveniently in the middle of likely working times for those who prefer flexibility. Personally I think the solution to this is obvious and apparently so do many others here. Daily standups within a mostly stable and well-functioning team are almost always redundant at best and actively disruptive at worst. So don't have daily standups. Instead work on a culture where people communicate freely whenever they need to and you bring people together for larger and longer meetings when (and only when) you have a specific reason for that.

starwatch 4y ago

I'm a strong believer in minimum viable process when it comes to team management. As teams grow, processes need to grow with them. But imo every process - stand-ups included - should be introduced as an experiment. The experiments should have a clear hypothesis, and a period of evaluation. The evaluation should be conducted by anyone who is expected to participate in or benefit from the process. If process experiments don't work - take lessons and throw out the process. Our current stand-up has evolved[1] to people posting their done/doing/blockers in Slack each day. We still have a daily 15 minute zoom meeting - which was once a stand-up - but it's changed. Now it's a time-boxed meeting where we shoot the breeze, or play small multiplayer games [2]. The rules are simple - no work chat, no politics. We meet in the middle of the day so people have the morning period to get work done. Our stand-up wouldn't work for all teams. We've specifically hired people that would work well in our team - and they're thus more inclined to work well with the processes we've developed. [1]: I wrote a bit about this at https://blog.getchinwag.com/posts/calling-all-remote-teams-stand-up-meetings-dont-wfh/ https://blog.getchinwag.com/posts/calling-all-remote-teams-s... - though our stand-up has continued to evolve. [2]: Assembling jigsaws has proven to be quite fun in recent weeks - we use https://puzzlegarage.com/ https://puzzlegarage.com/

wreath 4y ago
> no politics. This in itself is an achievement.
- atonse 4y ago
  I instituted the same rule in our slack. No politics. It helps to do it early on in the company. We’ve (so far) never had a political debate. Hope it stays that way Forever.
  - starwatch 4y ago
    We did have some political discussion but agreed it wasn't a net positive contribution to the culture we wanted to form. So we experimented with a no-politics rule and it stuck.

psi75 4y ago

No, they work as designed. The question is: who really designed them? If Agile actually empowered workers, management would ban it. Management took the relatively sensible directives of "the Agile Manifesto" and turned it into a vehicle through which they could shove Taylorism down everyone's throat. It's a status meeting. It's not supposed to be, but status meetings are good for managers and bad for workers and so they're not going anywhere. Capitalism would be bad enough if managers actually did care about "the company" or their shareholders, but it's simpler and more degenerate than that. They are optimizing for their own careers. It isn't more complex than that. The "bureaucratic culture of fear" suits them well. The weaponized standup is great for them; toward their real aims, it works beautifully, because it's basically thunderdome in its ability to make workers slug each other and terrorize those seen as least productive. "Agile" is a case-in-point where engineers, being intellectually intelligent but socially imbecilic, assumed good faith on the part of the people managing them and came up with a framework to make those good-hearted managers' lives and jobs easier... but, of course, the people above were not good-hearted and so any components of these methodologies that actually empowered working people got ripped out while still allowing the bosses to say, "Well, you asked for this."

commandlinefan 4y ago
> Capitalism would be bad enough You do realize that the only alternative to capitalism that's ever been proposed is Scrum for everything inside and outside of work?

snidane 4y ago

Your goal as a manager is to maintain flow - provided that you hired competent people. When you lose it and you feel the blame starts shifting your way your tendency is to set up more control and visibility. Here comes the daily standup and jira board of tasks. You lose even more flow as yoir team spends majority of time estimating and administering tasks in real time so that when you look at it once a week, it is semi-up to date. What you were looking for in the first place were to discover obstructions to the flow and finding process bottlenecks. You want to find out that one person that everything depends on to move and everybody slamming them with tasks and now the extra task tracking. You want to find out why that important task is not getting finished because the person is getting blocked on some infra problem and instead of reporting the blockage to you they pick up another task from the queue. Why would they report that if the only thikg you desire reported is what everybody ia working on - the important blocked people will always tell you they are busy enough as they found something else to work on. As a manager, how are you expecting to get any outcome if you never find the workplace bottlenecks and you only demand pople to get busy.

nuclearnice1 4y ago
> You want to find out why that important task is not getting finished because the person is getting blocked on some infra problem and instead of reporting the blockage to you they pick up another task from the queue. I think blocked on a high priority task is exactly what scrum with daily standup is sold as surfacing.
- mgkimsal 4y ago
  > I think blocked on a high priority task is exactly what scrum with daily standup is sold as surfacing. A 'daily standup' seems sort of the lowest-common-denominator way of surfacing that. someone recognizing on their own, and reaching out to raise a flag is one way. 1-1 checkins more frequently with those working on larger items would be another.
  - nuclearnice1 4y ago
    > lowest-common-denominator way Well said and exactly the psychological state one feels when participating. > someone recognizing on their own, and reaching out to raise a flag is one way. 100% agree Note that the OP has this blocked developer not announcing the block of a high priority item, but rather just pulling another item from the queue and making progress. Depends on the person and the instructions, but I guess it happens. 1-1 also makes sense to me. That said, I can picture the manager after back and forth playing telephone with blockee sand blockers, believing that an efficient way to handle this is to have all the relevant people in one spot.

zabil 4y ago

In teams I've been a part of, I found a 15 minute everyday stand up to be a nice way to build rapport. We don't use it for planning or detailed discussions. We don't insist on a standup structure, or what must be discussed etc. We just find it useful for greeting each other, sharing context and checking if anybody needs help. We experimented having no standups(to be completely asynchronous), but we didn't like that and felt it's worth the effort to catch up once a day.

Kaze404 4y ago
+1 to this. I find that a 15 minute stand up at the very least lets me see my coworkers, and I get so much out of just saying hi and hearing it back.
ishwarn 4y ago
This is similar to what we do at Abl. We use a Slackbot to ask everyone for a written standup update, answering a few questions: - What did you do on your last working day? - What are you doing today? - Are you blocked? - Would you like a conversation with anyone (to get unblocked or anything else)? - Any announcements, like PTO? And that gets posted in Slack at a certain time. The goal of this is transparency for what folks are working on, giving people the opportunity to raise blockers, and announcements. We then have a scheduled 15 minutes a day to just hang. We have a check-in question that's not work related and we use the time to socially connect. We are a fully remote company that used to be in-office, and we found the opportunities to build & grow these connections are not available in a remote + scheduled Zoom world like they were in office.
- thunky 4y ago
  > We then have a scheduled 15 minutes a day to just hang This sounds awful to me. Not sure why it would ever need to come to that: forcing people into a room every day and telling them to connect with each other. It just seems forced and phony. You already work together full time, and I assume you interact with each other as a normal part of your work? If not, maybe you aren't really on the same team, in which case why not invite accounting and HR into your social time?

kampsduac 4y ago

As a distributed team, I like the live interaction our daily standup provides. To stay focused on blockers, we share the yesterday/today portion of the update in Slack. This leaves our 10 minute stand up as a convenient forum for announcements and some virtual hallway conversation.

deleted 4y ago

[deleted]

kitsune_ 4y ago

If you want to fix these issues in the context of Scrum I suggest J. Coplien's "A Scrum Book". Or you can just read the patterns here: https://sites.google.com/a/scrumplop.org/published-patterns/home https://sites.google.com/a/scrumplop.org/published-patterns/... - The book is a slightly reworked reprint of the pattern work done by that group of people. It follows the pattern work by Christopher Alexander [1]. The patterns form a cohesive interlinked language that provides context for each pattern. Here is what it says about the Daily Scrum: https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/sprint/daily-scrum https://sites.google.com/a/scrumplop.org/published-patterns/... There some useful patterns that might even make sense outside of Scrum on there. Anyways, framing approaches and solutions in a cohesive pattern language is intriguing in its own right in my opinion. [1] https://en.wikipedia.org/wiki/Christopher_Alexander https://en.wikipedia.org/wiki/Christopher_Alexander

qaq 4y ago

You should start by implementing SAFe obviously :) https://www.scaledagileframework.com/ https://www.scaledagileframework.com/

kingboss 4y ago
I am a genius! I have invented the agile-waterfall method. Bring on the release train choo-choo!
- qaq 4y ago
  On the positive side look at how many high paying useless jobs SAFe creates :)

alberth 4y ago

Off topic: I see folks in the comments talk about async communication. What I don’t understand about the async crowd is why then do you get mad when I email at 9pm at night, or I email on the weekend. I’m not asking for an immediate reply, that’s the entire point of async (for you to reply on your own terms/time).

ipaddr 4y ago
Who gets mad at an email not viewed? If there is an expectation of responding immediately that breaks async people get mad. I have no ideas what emails came in over the weekend.. we will find out when the time is right
- alberth 4y ago
  So you agree, disagree? I’m confused.
  - ipaddr 4y ago
    If a call to action exists the receiver will get mad at the 9pm email. I also know that an email not checked by the receiver they won't be mad. What I don't know is the senders expectations of when the email should be checked.
RegW 4y ago
I think this is using the term "asynchrouously" where others might use "off-line". When the meeting turns up a problem that isn't going to be resolved in a few words, you might prompt those involved/interested to organise a specific meeting rather than bore the rest. However, "Can we take that off-line?" can also come to mean "Stop bringing problems!" :-)
Kaze404 4y ago
Do they? At work we tend to encourage async communication, and one of the first things I heard when I started is that I might get emails / messages outside of working hours but there was no expectation that I'd read them, or reply if I did.

NonNefarious 4y ago

"The software industry has been doing daily stand-ups for so long that it doesn’t remember why they exist" I've been a professional developer at one major software company after another (including ones that have tried SCRUM) since the '90s, and never heard the term "stand-up" at work until last year. That's a broadcast-news term as far as I'm concerned. Maybe they've been doing them but not calling them that.

nivertech 4y ago
> "The software industry has been doing daily stand-ups for so long that it doesn’t remember why they exist" That's so wrong. I worked at medium to large tech co. since late 90s, and only team leads attended regular meetings. Normal devs only attended very infrequent all-hands meeting (monthly at small companies, or quarterly at large). Of-course we had meetings, but they weren't dailies, but with specific agenda (e.g. design review, bugs, org. announcement, HR, etc.)

sodapopcan 4y ago

I like standup as a means of coming together as a team before starting the day, and only if your team is into that kind of thing. It shouldn't be a status report. If your manager needs a daily status report, that can be done async, I hate sitting around listening to my colleague list off every little thing they did the day before.

Clubber 4y ago

Stop making them daily. I see the author sticks to the dogma of a daily meeting of some sort. We have a 30 minute biz meeting followed by a 30 minute dev meeting weekly. We communicate by phone/teams/email when we need to.

lamontcg 4y ago

What I've found is pretty useless is manager-driven daily standups where the purpose is to go through all the items and get detailed status updates. I sort of infer that this happens through a broader management culture where managers get pop quizzes at meetings all week long where they have to be able to appear like they have the finger on the pulse of exactly what their reports are doing, which produces downwards pressure to micromanage. Even if they aren't micromanaging, it becomes this daily quiz so that the manager knows exactly what is going on. What was pretty useful was when daily standups were more IC driven and it was perfectly fine to say "yep, I'm working on the same thing I was doing yesterday" at least half the time. In those kinds of standups the Manager will typically bring broader concerns to the team that might have happened in the past 24h, rather than using the standup to quiz the team on what they're doing. The manager of course also gets to just give their own status as "meetings, meetings, meetings" and keep it short. In those cases we didn't even go through the Kanban board or have it open during the meeting, since everyone understood that you only have one or two things you're typically working on and your status is either that you're working on the same thing as yesterday or something is done and you're picking up something else. In some cases someone would be stuck or some issue would have come up, but this would usually result in two ICs taking over the zoom chat after 15 minutes and letting everyone else drop off. For brand new team members or junior devs this still works basically the same way but there would usually a bit more heavy use of after-meeting zoom chats or async chats afterwards. The formalism of doing it every day does work, particularly with remote teams, just to have a little bit of face to face time, and spur those after meeting or async zoom chats. But it needs to be kept lightweight and focused on developer-productivity and doesn't use any kind of issue board most days.

bitwidget 4y ago

I personally feel like daily standups are pretty important, contrary to what some people are commenting. Sure there are teams where they don't have any schedule meetings, but having that morning standup for 15-20 minutes each morning does a lot more than people think. I get to see what everyone else is currently working on and offer help if anyone says they have blockers. It works vice-versa as well, I sometimes run into issues and anyone on my team can pitch in, instead of me messaging individual people asking if they've seen that issue before. Even if all the above doesn't apply, I still get to talk and socialize with my entire team for 15 minutes, barely any productivity loss. Although I would have to agree with all the Agile/Scrum meetings comments here. I work at a very large insurance company and we have a dedicated Scrum Master. We have several meetings a week, each at least an hour with things like Retros, Backlog grooming, Planning, etc. These are the meetings that provide very little value while also taking a huge chunk out of my productivity.

SergeAx 4y ago

God knows how I am tired of those "insightful" let-me-tell-you-what-you-should-do headlines. Our stand-ups are working fine, there's nothing to be fixed. Thank you very much and good bye.