5 ms·

I've always hated standups. Very rarely do they provide value for the ICs (IMHO) and that should be the key measure. The biggest problem is that managers can e

• ck425 5y ago
  I disagree that the key measure should be value for ICs, or atleast engineering ICs. There are a lot of management and non-engineering IC issues that can be sorted by a quick chat. The alternative to a quick chat at standup tends to be constant Slack/Teams messages and lots of 30min meetings. ICs might not get much direct value from a daily standup but we get a lot of indirect value from moving a big chunk of those interruptions to a set time each day. This can be badly managed, as is the case in your examples. You're right that there shouldn't be more than 8 people and it definitely shouldn't take 45 min. 15 min max and if there's more to quickly discuss the people involved should stop and continue after the meeting. The situation you're talking about with crisis mode sounds like planning rather than standup and if you're Engineering Manager is declaring crisis mode and hijacking standup each day to spend an hour planning then you've got major cultural/organisation problems. In that case standups are just a symptom not the root cause. There's also the social aspect, which other comments have mentioned. I've always found that underrated, though I was recently reading about how some national cultures rate it a lot more than others. For me as a Brit I always feel far more comfortable communicating my colleagues when we get on socially and we understand each others sense of humor and communication styles. Taking that time to banter for a few min each morning is massively important for improving team communication. And during lockdown and WFH it's been even more essential.
• jseban 5y ago
  Having a daily casual meeting where everyone brings up all of their problems and issues, and anyone in the company is welcome to listen, but not talk, is just a dumb idea. And there are never any recurring (easy) obstacles that the scrum master can resolve, and that can always wait until the next daily, the work of developing software simply doesn't work that way. Edit: this is some bullshit inspired by rugby where you have regroup and change strategy as you learn about your opponents, what does that have to do with developing software I don't know.
  • dagw 5y ago
    If they where going to use a rugby term, I've always thought "ruck" would have been better. A ruck is quickly and dynamically formed every time progress is slowed, a scrum is a big formal process that is only necessary to restart the game after someone has screwed up.
  • splistud 5y ago
    Team rituals that trigger a productivity phase have no usefulness. Team communication has no value. Team leader having a chance to quickly gauge progress is not helpful at all.
    • malermeister 5y ago
      > trigger a productivity phase [Citation needed]. I find standups and their context switching cost me at least an hour of productivity each day. > Team communication has no value If you want to communicate with your teammates, just use Slack and communicate instantly, why wait for the next morning's standup? If anything, standup slows down communication. > Team leader having a chance to quickly gauge progress You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked?
      • handrous 5y ago
        > You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked? This doesn't fully excuse it, but the more closely management is watching team-work-coordination tools like ticketing systems, and the higher the level of management that's looking at them, the more prone they are to drift from reflecting reality. That a standup is, by default, not transparent and recorded for anyone else to look at, is, in some organizations, and if they're run properly, most of their value. Granted, yes, that's a work around for a broader cultural problem and shouldn't be necessary, but the real world's a mess.
• cdavid 5y ago
  > The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them. That can easily happen. On the other hand, where would you expect an EM to ask individual questions that matter to them ? My experience as an EM is that this really depends on the team, including domain and maturity. For example, if you have a team of mostly junior members, well, the "micro managing" version of standup is often useful. It gives a way to see how people can communicate their issues to other team members, especially when you're new as an EM. For more mature teams who don't have issues, I generally don't do standups, unless there is something critical and the project priorities at risk.
  • closeparen 5y ago
    The weekly 1:1s or project syncs that are also happening on top of standup, schedule a new meeting with the relevant participants if that’s too late from now, Slack or email if it’s a simple Q&A, JIRA ticket if it requires some work to investigate and answer.
• colechristensen 5y ago
  Matches my experience with standups: let’s all go around the room and think of something to say and then one or two people have a long drawn out conversation with the manager. What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high. It serves as an opportunity to be bored and frustrated for a half hour each day and does a rather good job of interrupting my daily flow. I think a key to a needed standup is a small group of people actually working collaboratively on something whereby the shared information is actually good to know. I am though a fan of short meetings of any topic where you literally are standing for the meeting, it seems to change the quality.
  • colmvp 5y ago
    > What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high. Yesterday, I asked a team member if they had QA'd my project. They said, "oh I wasn't expecting to QA your project." Yet I told them in the standup that I needed them to QA the project and I tagged them in a story. Clearly paying attention... During standup, I've also had people say "colmvp, you can go next" despite having already spoken. And near the end, we often don't even remember who hadn't spoken. I feel like standups work well for small teams, but in larger teams it just feels like it becomes impersonal and more of a thing to do to make yourself appear obedient to your manager.
    • davidw 5y ago
      I am getting the feeling that there is a whole set of these cargo-cult "best practices" like standups, "1-1's", retrospectives and so on. They're not stupid ideas, but they often seem implemented in a way where... "that's the done thing", rather than something evolved organically. I'm not a 'process guy' though so I have no idea what to replace these things with, if anything.
    • kovac 5y ago
      In my case it doesn't stop there. There's sprint planning, sprint retrospective, then a backlog grooming. After all that there are still more architectural discussions, meetings to clarify stuff. And then we break interfaces every other day. Reason given is "way of the agile". I can't speak in general, but it seems that we couldn't design a solid software for the long run if our lives depended on it anymore. I wonder what kind of processes industries like aviation, defense, and other high stake industries have?
• dugmartin 5y ago
  Where I work now everyone (devs, PMs, managers) have internalized that if you are not talking about something the whole team needs to know about you just briefly mention it as an "icebox" topic (we use Pivotal Tracker) which the PM tracks during the meeting. At the end of the meeting the PM lists out any icebox topics mentioned and we all briefly sort them based on the number of people that care to listen and then we go through them in that order. It is a little bit of ceremony but it works for us.
  • ck425 5y ago
    That's an interesting concept, never heard of "icebox" before. I've always used the "is this relevant to everyone" questions though. There are often short chats about topics that are extremely useful for those involved but not the whole team. If those go on longer than a minute I ask the folk involved to stop and "pick them up offline" afterwards. Saves everyone time without destroying the value.
    • dugmartin 5y ago
      The "icebox" term is borrowed from Pivotal Tracker (which we use for all our projects) https://www.pivotaltracker.com/help/articles/terminology/ https://www.pivotaltracker.com/help/articles/terminology/ > The Icebox panel contains stories that have not yet been prioritized. If you want to add a story and keep it “on ice” until you’re ready to prioritize it, click the + Add Story at the top of the Icebox panel. When you’re ready to prioritize the story, drag it into the Current or Backlog panel. Icebox stories are in the unscheduled state.
• jonathankoren 5y ago
  “The dramatic reading of the status reports,” as one former coworker put it.
  • ryandrake 5y ago
    We used to call it "Executive Storytime". We'd even project the status doc onto the screen AND have everyone read their part aloud to everyone in the room. Although in reality, the message was entirely for the VP and other big shots in the room, who would occasionally have questions. I imagine these are the kinds of things you think about on your deathbed, while you wonder if you spent enough time with your family throughout your life.
• BeetleB 5y ago
  > The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them. In the one place I was in that did Scrum, the org had rules: 1. The "Scrum Master" is external to the team. 2. If the manager behaved this way, the Scrum Master would kick him/her out of the room - permanently if need be. Worked well, and realistically, managers don't really want to be there.
  • Viliam1234 5y ago
    Most companies say the word "Scrum", but break half of the Scrum rules every day. This is exactly how it should be: only developers at daily, plus the Scrum Master as an impartial moderator (mostly there to keep the daily short). But in most companies, "Scrum Master" is just a label they put on a manager, and he is doing management as usual, only with an extra excuse for daily meetings.
• JasonCannon 5y ago
  My BI, Data Engineering, and Project Management team all have a shared standup. They all work on a bunch of different projects at any given time so we can't really do project specific standups. I am amazed at the dedication that the PM who runs the standup has on keeping things short, direct, and moving. About 15 folks are in on that meeting, and he's always done within 15 minutes. 17 minutes on a bad day. Any side conversations try and start up? "Let's table that".
• spaetzleesser 5y ago
  "The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them. Beyond about 8 people (and maybe as low as 5) this means a bunch of people are standing around while other people give updates on things they don't really care about. I've seen standups with 20 people that last 45 minutes as the manager goes around the room, basically. That's not a standup. It's even worse if PMs and other non-eng are there. Just, stop." A lot of managers or PMs really can't be allowed into a standup. Especially if they show only from time to time and take over the meeting.
  • handrous 5y ago
    I've been at a place with PM-driven standups. It was fine because: 1) If the team was like, "our team on this project is tiny and we all sit next to each other, so we don't need them", or "we'd rather do Slack messages for standups, on this particular project", he'd let that happen without a fuss, aside from ensuring that any communication he needed from it was still, somehow, happening. So it was still team-driven and very flexible. 2) He was very disciplined about not turning them into project status meetings, or making standup messages take the form of status updates. [EDIT] I should add that the benefit to him was that he got to hear a lot of unvarnished truth about what was going on, which micromanagers don't get, because he was at all times, in the face he presented to the team, on "our side". That put him in a much better position for polishing up the information he had for consumption outside the team(s), which benefited us, too. He might have questions or something, and it's not that he never pushed back on anything, but he let standups be standups, and kept that stuff separate and as non-confrontational as possible.
  • bmhin 5y ago
    > Especially if they show only from time to time and take over the meeting. I do not understand the mindset that goes into thinking that somehow a person is 1. Not required for a meeting and so can only attend on occasion and 2. If present must drive the entire thing. I guess in theory they might think they are improving things if they assume it is an unguided, unfocused disaster with out them, but in my experience it is the exact opposite: a focused, relevant, quick stand up without vs a meandering, drawn out, ritualized boilerplate, "explain to the PM stuff everyone else knows" meeting with. PMs can be genuinely useful too. They just need to use the most important words in their toolkit: "you 2 (3,4) discuss offline/afterwards, next person". Not to be used if people are casually chatting, but to fix that problem of 2 people having a conversation while 6 others listen for no reason.
• lucb1e 5y ago
  What is an IC? (in your first sentence)
  • mateo411 5y ago
    Individual Contributor
• lloydatkinson 5y ago
  This is exactly my experience at multiple companies. Remote WFH has made it more tolerable.