5 ms·

its always somebody dropping these gems in interviews followed by “is this age discrimination” the purpose is to provide transparency to other stakeholders, to

its always somebody dropping these gems in interviews followed by “is this age discrimination” the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders. in which case your own velocity isnt important as opposed to knowing if other team members are blocked on something you may be familiar with or even responsible for a daily meeting that shouldnt exceed 10 minutes, or done asynchronously daily, is a decent way of accomplishing that

CuriousCosmic 2y ago
Alternatively why even have a meeting? Just have a channel in slack/mattermost/teams for your team to post what they did and what they are stuck on at the end of the day and what they plan on doing at the start of the day. You get the same result but without forcing people to spend the 15-30 minute wasted time before the meeting and the hour or so of degraded performance while they try to get back into the zone after the meeting. Standups only benefit management and they really are the pinnacle of "this could have been an email/message". The only time they may be acceptable is if everyone on the team dedicates their entire schedule (at least for the week) on that one project and if they work the exact same hours, the exact same days, in a no-remote environment. Then you can have a quick 10 minute meeting around the coffee machine while people grab their coffee in the morning. Otherwise just make it an email/slack message.
- yieldcrv 2y ago
  yes that’s what asynchronously refers to, it’s in my post you might have been typing while I added that
  - CuriousCosmic 2y ago
    ahhhh yeah. I'm guessing I probably caught it right in that sweet spot between post and edit.
- hosh 2y ago
  Unless people sync up socially, it is unlikely the team will gel. Some places let a lone developer do everything. More power to them. I think there's a better chance for the team to problem solve together and be able to have continuity as people join and leave the team.
  - anonzzzies 2y ago
    You can go for tgif for socially gelling. We go to lunch together, often dinner en also drinks. No need for standups for any social contact. Especially when talking about work things.
    - hosh 2y ago
      That sounds like there is something to unpack there. I think it is beneficial but others do not. Why is it? Maybe it is because I've largely worked on remote-first teams, even before COVID. There are no TGIF, unless people make an effort to zoom together while drinking or something.
      - anonzzzies 2y ago
        Sure, I work mostly with remote teams for the past 30 years. My point stands in that yes, Zoom is nice for socialising; I see no point in daily standups and voice meetings. We do have drinks/gaming for social; just no one wants to 'socialise' while working on something; it's simply not effective.
        CuriousCosmic 2y ago
        This. Virtual coworking spaces are a great solution for people who work well that way and you can host virtual game nights or movie nights outside of working hours for people who want to participate but you can't make people socialize by wasting their time with pointless mandatory meetings.
        hosh 2y ago
        Socialization isn’t about doing things like pizza night or having games. It’s more about establishing connection and rapport, the basis of trust and communication. Most people are not going to be doing that asynchronously.
seneca 2y ago
I agree with everything you say here, except for the asynchronous part. It's much better for a team to see each other face to face for a few minutes a day, especially for remote teams. It's wildly higher throughput than bullet points most people don't bother reading, it gets exposure for junior engineers, and it builds a stronger sense of being a team. Someone who acts like being asked to spend 10 minutes a day with their team is some major imposition is worth losing over it.
- hosh 2y ago
  I see the same. There are places where the lone developer working completely async can work. Hopefully, they don't come out with over-engineered stuff that no one else can use.
- anonzzzies 2y ago
  We chat about everything in our team, asynchronous. Works fine for 30 years. I find people who have issues writing down their thoughts and bullet points first (which means they will be answered or addressed by someone before they can even hit a meet invite button). Each their own of course; everywhere I go (and we see a lot of companies close up because the nature of our work), we have to push away the meetings as they never work at all. What helps is asking very high hourlies; then suddenly meetings are not so wanted anymore (which proves the point).
n4r9 2y ago
> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders Are you suggesting that the daily standup is to provide progress updates to the wider company (and possibly clients)? In my experience doing it like this makes it less of a safe space. It's purely a discussion between Devs and QAs about what's currently being worked on.
palata 2y ago
You have to be a manager in order to throw a word salad like this. "stakeholders", "forecast team velocity", "aggregate potential throughput"... As an engineer, my feeling is that this bullshit never works and loses a lot of my time for the sake of a manager justifying their work instead of actually creating value.
- jf22 2y ago
  "stakeholders" Can I ask what do you think this the term "stakeholders" describes and what alternative terms you should use?
  - mattmanser 2y ago
    Stakeholder is corporate jargon. User, customer or client are the normal, non-corporate jargon, terms. A cynic might think 'stakeholder' gets used when a company forgets about the end-users.
    - jf22 2y ago
      I was more interested in the original authors definition as he called it part of a word salad. I don't see a problem with some terms as being corporate jargon. That's just shorthand for an idea the same way any slang for a group is shorthand.
      - palata 2y ago
        Here is why I did not answer: I don't think you are genuinely interested, I think you just disagree and were trying to argue that it was not a "word salad". Which is valid, it's okay to disagree with my subjective opinion. For the sake of the argument: I say "apple, pear, avocado... that's a salad!" and you answer "Why would you say that an apple is necessarily part of a salad? How should I call an apple if I don't want it to sound like it is part of a salad?" What makes a salad is the aggregation of multiple ingredients. Of course "stakeholders" is not a word salad.
kingkongjaffa 2y ago
> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders That’s mostly theatre though. Building useful software is not measured by team velocity or throughput. In 2024 counting this stuff is crazy. Measuring outcomes and customer value is infinitely better than measuring velocity. Output is not hard, deciding and testing that you are building the right thing to create the right outcomes and customer behaviours to give them value is far more important. In 2024 velocity and story points etc. and other theatrics are huge red flags to signal the organisation is not building meaningful products with care and craftsmanship.
- jf22 2y ago
  I think you're thinking of velocity as a metric and not as a helpful term to describe relative productivity.
  - n4r9 2y ago
    Not the person you're replying to, but I'm not convinced there's a difference. Discussions about velocity boil down to "how much can we fit into the next sprint/month/quarter". This typically feeds into some kind of burndown or roadmap update. However it retains the pitfalls of estimating something that is often unknowable in advance. I may be misunderstanding your comment in which case I'd greatly appreciate clarification as I really struggle with workflow planning.
    - jf22 2y ago
      I'm convinced people understand the difference. Everyone struggles with workflow planning and that's why people use the old mid 2010s scrum terms differently now.
      - n4r9 2y ago
        I've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you mean the difference in productivity between an experienced vs junior dev? Or perhaps someone that knows the codebase and someone that's new to it? And what do you gain from having a notion of "velocity" - what do you use it for? In my experience, you can perhaps throw a rough idea of complexity at a task (easy/medium/hard). Even then you may be wrong around a third of the time. How well complexity correlates with implementation effort depends on such a large number of factors (novelty of task, team size, dev experience, communication overheads, unseen dependencies...) that it's pointless to fine-grain any project or large feature estimates to an accuracy greater than something like "this will take about 2 months, but it could be 3 or 4".

CuriousCosmic 2y ago

Alternatively why even have a meeting? Just have a channel in slack/mattermost/teams for your team to post what they did and what they are stuck on at the end of the day and what they plan on doing at the start of the day. You get the same result but without forcing people to spend the 15-30 minute wasted time before the meeting and the hour or so of degraded performance while they try to get back into the zone after the meeting. Standups only benefit management and they really are the pinnacle of "this could have been an email/message". The only time they may be acceptable is if everyone on the team dedicates their entire schedule (at least for the week) on that one project and if they work the exact same hours, the exact same days, in a no-remote environment. Then you can have a quick 10 minute meeting around the coffee machine while people grab their coffee in the morning. Otherwise just make it an email/slack message.

yieldcrv 2y ago
yes that’s what asynchronously refers to, it’s in my post you might have been typing while I added that
- CuriousCosmic 2y ago
  ahhhh yeah. I'm guessing I probably caught it right in that sweet spot between post and edit.
hosh 2y ago
Unless people sync up socially, it is unlikely the team will gel. Some places let a lone developer do everything. More power to them. I think there's a better chance for the team to problem solve together and be able to have continuity as people join and leave the team.
- anonzzzies 2y ago
  You can go for tgif for socially gelling. We go to lunch together, often dinner en also drinks. No need for standups for any social contact. Especially when talking about work things.
  - hosh 2y ago
    That sounds like there is something to unpack there. I think it is beneficial but others do not. Why is it? Maybe it is because I've largely worked on remote-first teams, even before COVID. There are no TGIF, unless people make an effort to zoom together while drinking or something.
    - anonzzzies 2y ago
      Sure, I work mostly with remote teams for the past 30 years. My point stands in that yes, Zoom is nice for socialising; I see no point in daily standups and voice meetings. We do have drinks/gaming for social; just no one wants to 'socialise' while working on something; it's simply not effective.
      - CuriousCosmic 2y ago
        This. Virtual coworking spaces are a great solution for people who work well that way and you can host virtual game nights or movie nights outside of working hours for people who want to participate but you can't make people socialize by wasting their time with pointless mandatory meetings.
      - hosh 2y ago
        Socialization isn’t about doing things like pizza night or having games. It’s more about establishing connection and rapport, the basis of trust and communication. Most people are not going to be doing that asynchronously.

seneca 2y ago

I agree with everything you say here, except for the asynchronous part. It's much better for a team to see each other face to face for a few minutes a day, especially for remote teams. It's wildly higher throughput than bullet points most people don't bother reading, it gets exposure for junior engineers, and it builds a stronger sense of being a team. Someone who acts like being asked to spend 10 minutes a day with their team is some major imposition is worth losing over it.

hosh 2y ago
I see the same. There are places where the lone developer working completely async can work. Hopefully, they don't come out with over-engineered stuff that no one else can use.
anonzzzies 2y ago
We chat about everything in our team, asynchronous. Works fine for 30 years. I find people who have issues writing down their thoughts and bullet points first (which means they will be answered or addressed by someone before they can even hit a meet invite button). Each their own of course; everywhere I go (and we see a lot of companies close up because the nature of our work), we have to push away the meetings as they never work at all. What helps is asking very high hourlies; then suddenly meetings are not so wanted anymore (which proves the point).

n4r9 2y ago

> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders Are you suggesting that the daily standup is to provide progress updates to the wider company (and possibly clients)? In my experience doing it like this makes it less of a safe space. It's purely a discussion between Devs and QAs about what's currently being worked on.

palata 2y ago

You have to be a manager in order to throw a word salad like this. "stakeholders", "forecast team velocity", "aggregate potential throughput"... As an engineer, my feeling is that this bullshit never works and loses a lot of my time for the sake of a manager justifying their work instead of actually creating value.

jf22 2y ago
"stakeholders" Can I ask what do you think this the term "stakeholders" describes and what alternative terms you should use?
- mattmanser 2y ago
  Stakeholder is corporate jargon. User, customer or client are the normal, non-corporate jargon, terms. A cynic might think 'stakeholder' gets used when a company forgets about the end-users.
  - jf22 2y ago
    I was more interested in the original authors definition as he called it part of a word salad. I don't see a problem with some terms as being corporate jargon. That's just shorthand for an idea the same way any slang for a group is shorthand.
    - palata 2y ago
      Here is why I did not answer: I don't think you are genuinely interested, I think you just disagree and were trying to argue that it was not a "word salad". Which is valid, it's okay to disagree with my subjective opinion. For the sake of the argument: I say "apple, pear, avocado... that's a salad!" and you answer "Why would you say that an apple is necessarily part of a salad? How should I call an apple if I don't want it to sound like it is part of a salad?" What makes a salad is the aggregation of multiple ingredients. Of course "stakeholders" is not a word salad.

kingkongjaffa 2y ago

> the purpose is to provide transparency to other stakeholders, to then forecast team velocity and aggregate potential throughput to those stakeholders That’s mostly theatre though. Building useful software is not measured by team velocity or throughput. In 2024 counting this stuff is crazy. Measuring outcomes and customer value is infinitely better than measuring velocity. Output is not hard, deciding and testing that you are building the right thing to create the right outcomes and customer behaviours to give them value is far more important. In 2024 velocity and story points etc. and other theatrics are huge red flags to signal the organisation is not building meaningful products with care and craftsmanship.

jf22 2y ago
I think you're thinking of velocity as a metric and not as a helpful term to describe relative productivity.
- n4r9 2y ago
  Not the person you're replying to, but I'm not convinced there's a difference. Discussions about velocity boil down to "how much can we fit into the next sprint/month/quarter". This typically feeds into some kind of burndown or roadmap update. However it retains the pitfalls of estimating something that is often unknowable in advance. I may be misunderstanding your comment in which case I'd greatly appreciate clarification as I really struggle with workflow planning.
  - jf22 2y ago
    I'm convinced people understand the difference. Everyone struggles with workflow planning and that's why people use the old mid 2010s scrum terms differently now.
    - n4r9 2y ago
      I've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you mean the difference in productivity between an experienced vs junior dev? Or perhaps someone that knows the codebase and someone that's new to it? And what do you gain from having a notion of "velocity" - what do you use it for? In my experience, you can perhaps throw a rough idea of complexity at a task (easy/medium/hard). Even then you may be wrong around a third of the time. How well complexity correlates with implementation effort depends on such a large number of factors (novelty of task, team size, dev experience, communication overheads, unseen dependencies...) that it's pointless to fine-grain any project or large feature estimates to an accuracy greater than something like "this will take about 2 months, but it could be 3 or 4".