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
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.
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).
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.
> 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.
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.
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".
> 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.
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.
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.
You can have planning meetings but those are relatively short (<1hr) bi-weekly or monthly meetings.
And you can have an open coworking VC. I've not seen this formally in a corporate environment personally but I've sat in calls with friends at work for hours doing mostly the same thing (just informally). And in a formal capacity it's fairly common in open source project spaces. Their discords will have an open VC channel for "co-working" or working while on VC so they can occasionally chat, ask questions, or otherwise interact socially in a way you could while in an office setting.
The best part of coworking spaces is that they are optional. You join when you want and you deafen yourself or leave/DND when you don't want to be there and need to be undisturbed.
If you want to build a social fabric and get the team integrated, the way you do that is culture. Enforcing socialization isn't a good thing.
Don't make "Mandatory Fun". The only thing it breeds is a toxic work environment where people don't want to be there.
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.
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.
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.
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.
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.
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.
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.
> You typed more about your definition of "word salad" than you did about stakeholders.
Because it seems to me that you focus on my definition of "stakeholders" but you actually have not understood what I was trying to say, which requires understanding what I mean by "word salad".
> The word stakeholders has meaning and isn't part of a word salad to me.
And this confirms that my point hasn't been understood.
I think it's very funny because I first wrote "instead of actually doing stuff" (which was wrong because this is "doing stuff", just bullshit stuff IMO). So I rephrased as "instead of actually being productive", which I thought was maybe a bit aggressive.
So I went for "actually creating value", because it felt like the way a manager would describe it. "I appreciate that you are doing work, and it is good, but it is not creating value... therefore I believe we need to change something" is how I imagined trying to constructively say "this is all bullshit, but I respect you as a person and I believe that you could do proper stuff instead".
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