3 ms·

I'm not a software engineer, but isn't the idea that if everyone is sharing their progress and challenges then others who had similar challenges on previous pro

I'm not a software engineer, but isn't the idea that if everyone is sharing their progress and challenges then others who had similar challenges on previous projects can voice their suggestions? It seems like "mute my mic and keep working until my department comes up" is why the meetings seem so pointless, because you aren't listening to other team's challenges and providing input? Then again, I could be romanticizing these meetings and maybe at your company unsolicited feedback is discouraged, so I don't want to project that onto you, but I always though that was the _idea_ of the daily/weekly standup?

dfischer 9y ago
The overall argument against it is that all the information is already reflected in the ticketing system and if anything had to be resolved you can do it 1:1 rather than wasting everyone’s time.
- philipodonnell 9y ago
  That sort of assumes that you know who to talk to. I was thinking more about the case of "here's how we are doing it" and someone you wouldn't have thought to ask saying "oh, we tried to do that at [x] last year and it didn't work because [a], [b], [c]".
  - dagw 9y ago
    But then to ensure that that 'right' unknown person is at the meeting you basically have to invite the whole company. Much better to send out a quick "hey, anybody done any work with Monte Carlo simulations before" on the company mailing list. Maybe twice a year you can have a big 'all-hands' all day work shop where you go through and discuss major long term issues.
dagw 9y ago
isn't the idea that if everyone is sharing their progress and challenges then others who had similar challenges on previous projects can voice their suggestions? At least in my experience, 90% of the time there aren't any 'useful' challenges being presented. Mostly it's stuff like "Dave was sick last week so we're a bit behind", "ticket #447 was much trickier than we expected, but we've solved it now" or "We're still waiting for the client to send us the updated data files". The actual technical challenges are almost always hashed out in smaller ad hoc meetings among the relevant people. And even when a 'real' challenge does get aired it's often of such a specialized nature that only 2-3 people have anything useful to add and it's much better for them to have a separate meeting. So it's not that feedback is discouraged, it's that there is hardly anything at the meeting to give constructive feedback on, and any feedback I can give has already been given days ago in one those above mentioned ad hoc meetings. And in the very very rare event that someone has a challenge that is big enough and generic enough that it's reasonable to assume that the whole team will have something productive to add then that is a unique enough event that it's worth scheduling a specific meeting just for that.
- philipodonnell 9y ago
  Is your employer a software consulting company with teams working for different clients? I could see how in that kind of meeting there would be very little overlap in situational awareness of what each client's requirements are. I was imaging a team working on different parts of the same large product, where it may not be feasible to identify everyone who might be able to provide constructive criticism ahead of time to get them into one of those ad-hoc meetings. Although, "that's the idea but it doesn't work in practice" is a fine answer, too.
  - dgreensp 9y ago
    I was in 50-person all-hands meetings for a product at Google, and there wasn’t the time or the context for anyone to give feedback on anything. At the time I felt bad about my inability to pay attention — without my laptop out I would barely have been able to stay in the room due to boredom — but the meeting really was a poor format and a waste of people’s precious time, attention, and energy, even at an hour a week.
- colanderman 9y ago
  Yep, "oh, we had a problem, but then we fixed it" accounts for about 50% of all the "content" in our daily standups. The solution is almost invariably (a) nontechnical, (b) wholly inapplicable outside some tiny domain, (c) trivial, or (d) so complicated as specific that the speaker rightly elides it from their report, making that 50% of time a total waste for everyone in the room. The few cases when it's actually a common problem one could reasonably expect others to have, team-wide emails have already been sent and there's no need to cover it again.
iamatworknow 9y ago
>Then again, I could be romanticizing these meetings and maybe at your company unsolicited feedback is discouraged Before I moved and started working remotely for my company, I was in one of these meetings where a coworker who took over one of my projects from ~2012 was commenting on what he was doing, and I offered a suggestion in an attempt to help. My immediate supervisor said "That's not important". This is a guy hired all of 4 months before me -- we're #2 and #3 in terms of tenure among developers, and until about 3 years ago both reported directly to the owner of the company. I then noted that I believed it was important, and I knew that because I had direct experience with the project where my supervisor did not (because I wrote it), and my supervisor asked me "well then why don't fix it instead of [the newer dev working on the project]?" in a dismissive tone. This is a project I hadn't worked on in half a decade and was no longer in my job description. Thankfully the owner of the company was in the meeting as well, noticed the tension, and talked to both of us separately about it after the meeting (agreeing profusely with me that I was adding a valuable contribution and that my supervisor was out of line to snip at me). The supervisor later apologized to me directly. That was not the first time he directed uninvited hostility toward me, but it was the most public instance of it, and was the last before I started working remotely. Things are much better now, I imagine because the perceived threat of me trying to usurp his managerial role is now 1000 miles away from the office. So yeah...sometimes these meetings aren't so great, haha.
stdbrouw 9y ago
The problem is that hands-on meetings are supposed to be short, so you'll have time to say "we're having this issue", but not enough time to detail all of the different approaches you've already tried, so you get a lot of less-than-helpful advice from people who don't have enough information to go on but think they do.
- philipodonnell 9y ago
  That's fair. I suppose the length of the meeting is tough to get right to make it work like that. Too long and you end up wasting time, too short and, like you said, not enough time to get real constructive feedback.
colanderman 9y ago
To be asked to pay detailed attention to everyone's diverse problems for a half an hour every single day is an incredible energy drain. I need to focus on my work. If I have to build 20 different mental models in my head once a day to make sense of 20 different people's problems, I can't do that. The tried-and-true method of, "oh, ask so-and-so, they worked in that area" is strictly better, because no matter how many times you're redirected, you're bothering fewer people than at the daily standup.
valuearb 9y ago
In practice it's impossible to help someone with a software development problem in a standup. To understand their problem you almost always need a level of detail that's inappropriate for a standup. You don't want to force 50 people to sit around waiting while two engineers discuss a problem for 5 minutes. Instead the meeting organizer should say, Sarah, you know about this area, can you connect with Justin after the meeting and see if you can help. Anyone else who has ideas is welcome to join. Standups only work when people give a quick status update, their plans for the day, and call out any blockers. If it devolves into discussions of how to solve any problem it's no longer a standup. And anyone who schedules standups with more than a single focused team (preferably no more than a dozen people) just doesn't understand what a standup is for.

dfischer 9y ago

The overall argument against it is that all the information is already reflected in the ticketing system and if anything had to be resolved you can do it 1:1 rather than wasting everyone’s time.

philipodonnell 9y ago
That sort of assumes that you know who to talk to. I was thinking more about the case of "here's how we are doing it" and someone you wouldn't have thought to ask saying "oh, we tried to do that at [x] last year and it didn't work because [a], [b], [c]".
- dagw 9y ago
  But then to ensure that that 'right' unknown person is at the meeting you basically have to invite the whole company. Much better to send out a quick "hey, anybody done any work with Monte Carlo simulations before" on the company mailing list. Maybe twice a year you can have a big 'all-hands' all day work shop where you go through and discuss major long term issues.

dagw 9y ago

isn't the idea that if everyone is sharing their progress and challenges then others who had similar challenges on previous projects can voice their suggestions? At least in my experience, 90% of the time there aren't any 'useful' challenges being presented. Mostly it's stuff like "Dave was sick last week so we're a bit behind", "ticket #447 was much trickier than we expected, but we've solved it now" or "We're still waiting for the client to send us the updated data files". The actual technical challenges are almost always hashed out in smaller ad hoc meetings among the relevant people. And even when a 'real' challenge does get aired it's often of such a specialized nature that only 2-3 people have anything useful to add and it's much better for them to have a separate meeting. So it's not that feedback is discouraged, it's that there is hardly anything at the meeting to give constructive feedback on, and any feedback I can give has already been given days ago in one those above mentioned ad hoc meetings. And in the very very rare event that someone has a challenge that is big enough and generic enough that it's reasonable to assume that the whole team will have something productive to add then that is a unique enough event that it's worth scheduling a specific meeting just for that.

philipodonnell 9y ago
Is your employer a software consulting company with teams working for different clients? I could see how in that kind of meeting there would be very little overlap in situational awareness of what each client's requirements are. I was imaging a team working on different parts of the same large product, where it may not be feasible to identify everyone who might be able to provide constructive criticism ahead of time to get them into one of those ad-hoc meetings. Although, "that's the idea but it doesn't work in practice" is a fine answer, too.
- dgreensp 9y ago
  I was in 50-person all-hands meetings for a product at Google, and there wasn’t the time or the context for anyone to give feedback on anything. At the time I felt bad about my inability to pay attention — without my laptop out I would barely have been able to stay in the room due to boredom — but the meeting really was a poor format and a waste of people’s precious time, attention, and energy, even at an hour a week.
colanderman 9y ago
Yep, "oh, we had a problem, but then we fixed it" accounts for about 50% of all the "content" in our daily standups. The solution is almost invariably (a) nontechnical, (b) wholly inapplicable outside some tiny domain, (c) trivial, or (d) so complicated as specific that the speaker rightly elides it from their report, making that 50% of time a total waste for everyone in the room. The few cases when it's actually a common problem one could reasonably expect others to have, team-wide emails have already been sent and there's no need to cover it again.

iamatworknow 9y ago

>Then again, I could be romanticizing these meetings and maybe at your company unsolicited feedback is discouraged Before I moved and started working remotely for my company, I was in one of these meetings where a coworker who took over one of my projects from ~2012 was commenting on what he was doing, and I offered a suggestion in an attempt to help. My immediate supervisor said "That's not important". This is a guy hired all of 4 months before me -- we're #2 and #3 in terms of tenure among developers, and until about 3 years ago both reported directly to the owner of the company. I then noted that I believed it was important, and I knew that because I had direct experience with the project where my supervisor did not (because I wrote it), and my supervisor asked me "well then why don't fix it instead of [the newer dev working on the project]?" in a dismissive tone. This is a project I hadn't worked on in half a decade and was no longer in my job description. Thankfully the owner of the company was in the meeting as well, noticed the tension, and talked to both of us separately about it after the meeting (agreeing profusely with me that I was adding a valuable contribution and that my supervisor was out of line to snip at me). The supervisor later apologized to me directly. That was not the first time he directed uninvited hostility toward me, but it was the most public instance of it, and was the last before I started working remotely. Things are much better now, I imagine because the perceived threat of me trying to usurp his managerial role is now 1000 miles away from the office. So yeah...sometimes these meetings aren't so great, haha.

stdbrouw 9y ago

The problem is that hands-on meetings are supposed to be short, so you'll have time to say "we're having this issue", but not enough time to detail all of the different approaches you've already tried, so you get a lot of less-than-helpful advice from people who don't have enough information to go on but think they do.

philipodonnell 9y ago
That's fair. I suppose the length of the meeting is tough to get right to make it work like that. Too long and you end up wasting time, too short and, like you said, not enough time to get real constructive feedback.

colanderman 9y ago

To be asked to pay detailed attention to everyone's diverse problems for a half an hour every single day is an incredible energy drain. I need to focus on my work. If I have to build 20 different mental models in my head once a day to make sense of 20 different people's problems, I can't do that. The tried-and-true method of, "oh, ask so-and-so, they worked in that area" is strictly better, because no matter how many times you're redirected, you're bothering fewer people than at the daily standup.

valuearb 9y ago

In practice it's impossible to help someone with a software development problem in a standup. To understand their problem you almost always need a level of detail that's inappropriate for a standup. You don't want to force 50 people to sit around waiting while two engineers discuss a problem for 5 minutes. Instead the meeting organizer should say, Sarah, you know about this area, can you connect with Justin after the meeting and see if you can help. Anyone else who has ideas is welcome to join. Standups only work when people give a quick status update, their plans for the day, and call out any blockers. If it devolves into discussions of how to solve any problem it's no longer a standup. And anyone who schedules standups with more than a single focused team (preferably no more than a dozen people) just doesn't understand what a standup is for.