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.
Process has value specifically when one should assume a lower level of trust. This is not always a bad thing. A few examples:
Larger organizations with significant turnover, such as government bureaucracies. Sub-groups of the organization rely on process to interface with each other.
Guild-like organizations that work on individual projects with changes in team composition. Showing up to a new jobsite with people you haven't worked with before means less trust than you'd have on a team that's been together for a while. Process is the glue that keeps things functioning.
I'd rather work on a small team in a high-trust environment, but such a thing doesn't often scale well to large projects in every industry.
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.
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)
I don't understand hiring scrum master as a full time employee from my experience it always is role for one person in the team that does other stuff full time.
I never saw scrum master who is doing only scrum stuff myself but from what I read on the internet there are people who saw it.
Scrum masters are one of the reasons I chose to be overemployed. Their presence in an organization taught me that it is highly rational to be performative over performing.
Do you also have scrum-of-scrums? Because that is out DevOps team's latest idea to speed up an ERP project. So we get scrum masters instead of functional ERP experts and consultants. I am curious so, what a scrum-scrum would actually look like...
I remember my previous employer trying that out in one or two departments. Ultimately that company landed on SAFe Agile and it was a complete and utter shit show.
Where I'm at now is "doing" Kanban but the standup is really just a daily status update. I'm slowly getting the management to recognize that these things are problems, why they are problems, and what can be done about them. But I'm much happier with this situation because I can actually push back against it and try to improve the thing. At my previous employer, any attempt to even begin highlighting problems would render you standing alone against what amounts to a committee of management (in this case, specifically, people who are only employed because of the fact that they use these extremely heavy processes) if you wanted to discuss these things.
Your previous employer sounds a lot like my current one. Add to that a DevOps head who currently holds his first job in anything IT related and actual developers that are almost exclusively external and subcontractors... All our internal developers are doing is Palantir dashboards and some interfaces to get the data into Palantir.
Scrum of scrum doesn’t work, you shouldn’t have a separate “devops team”. If you really must, someone from that team should sit in your scrum to link back to their team any blockers.
Otherwise what you have, and I’ve seen this in multiple places, is developers getting blocked by DevOps constantly, so basically setting up “shadow” infrastructure to try and work around the problem.
IME whenever an organization like that hires an agile coach they either get a jaded cynical jobsworth who powers through the motions implementing some process heavy thing or an idealist who ends up clashing with managers who definitely want "agile", but with status updates, quarterly planning and accountability metrics and all the other shit that makes it impossible to be agile.
The latter will typically get managed out or even fired.
There doesnt really seem to be a way to square this circle.
At least what happened at my company, is that they hire an idealist who preaches agile to management, and then gets frustrated when reality doesn’t match what they preached, because now their job is on the line.
It was somehow hilarious to watch him weasel his way out of missed deadlines and failed project. Every developer ended hating him, since developers got the blame for everything, since we didn’t follow his idealistic view of agile.
In fairness Ive seen data scientists get equally surly when management hires them expecting them to work their magic and the reality is that the data is so filthy that there's nothing they can usefully do.
Ideally you should quit if conditions make your job impossible - that being the economically "efficient" thing to do. But mortgages, kids to feed and the everpresent reality of the capitalist system often prevents one from doing that.
I do agree with you, and it’s not that I hate agile, I actually think it’s a great way of working, if you allow teams to change what it means to work agile. However, more often than not, those agile coaches or scrum masters follow to handbook, without allowing real world experiences to change the process.
In my experience, they don't even follow the handbook, but rather the management's decisions about which parts of "agile" we want (Jira tickets, daily meetings) and which parts can be ignored (retrospective, having no long-term deadlines).
The old form or substance discussion. Some compabies have the substance, e.g. Toyota when it come to lean, some have both form and substance while the majority implement the form without getting the substance. The latter also wonder why things don't work as expected...
This sounds eerily familiar.
Let me guess, there were sprint planning sessions that went on for hours. More time was allocated to planning the work, than for the actual work.
Replacing one dogma (waterfall) with another (dogmatic agile), is not agile.
I think it is a necessary step in the process. No org is going to go from full on dogmatic waterfall to fully agile in one step. Dogmatic agile either works or fails on its own. If it works then the org might try going actual agile.
I agree that trust is a major component, especially from above. But it also requires a "team" mindset. The adhoc calls you are talking about are helpful for the team but they are disruptive to the person. This causes this approach to not work for some teams because there are people who just want to sit heads down and crank code. Those are the people that require daily stand ups to make sure they don't go off all willy nilly. These people also tend to get annoyed when someone else needs their subject matter expertise to fix/debug/tweak something as it is "interrupting" them.
When the team evolves to value for team success over individual, then this sort of things is obviously more efficient because everyone is actively engaged in keeping everyone in sync. So I think it is much more about a mature and cohesive team than trust explicitly. However, ime, there are always some who just want to play whac-a-mole and be "done" even when it isn't in the team's best interest.
I think that you've hit the nail on the head with trust. I have felt most productive in small teams with a lot of autonomy and self-regulation. The most interesting problem to me is how to establish that trust in the first place; especially if team members have varying levels of "conscientiousness" regarding code and process
> The amount of process and ceremony required is inversely proportional to the trust level on the team.
True! Though usually the mistrust is management of the team.
> Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant.
And conversely, when the team isn't communicating with one another, that's when introducing standups does the most good. Managers wanting to micromanage leads to heavy process.
I would love this set up. However we have one team member who is a total cowboy, goes off on tangents and can spend weeks on a random idea than an epic/quarterly goal and we can’t get rid of him. So daily stand-up’s are our only way of seeing what he’s up to. There’s always looking at PRs but we only have so much time individually to babysit PRs. It’s a trust thing for sure.
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.
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.
For the love of me I fail to find an article again about the different approaches, Scrum, waterfall or whatnot, and hoe they are used at start-ups, FAANG, large non-tech companies. I found it through the HN front page...
Gist of it: FAANG is very flexible as long as things get done (hinting at really understanding how things work), large corps somewhat flexible between teams (understanding in principle how it works but still being big corps) while start-ups stick to one methodology (sticking what some founder knows, or thinks to know). Brackets are my interpretation.
Based on what I saw in the last year in my current job, that rings true. Agile is the latest shit, so we aoply it to everuthing, from hardware development to ERP roll outs. Not sure if in those two cases it is the right approach.
It's not my understanding of that article.
What I understood is:
- most FAANGs are using either informal or formal mini-waterfall SDLCs (i.e. starting with small upfront design/product/marketing document).
- most non-tech enterprises and consultancies are using Agile/Scrum
- startups are somewhat in the middle
There is a google sheet with the detailed list of companies and their SDLCs.
Lastly I do agree that SDLC should be adapted to company size/stage and the industry/vertical.
I.e. don't use Agile/Scrum/SAFe over waterfall/RUP for mission- or safety-critical software (i.e. missile, aviation or automotive). And don't use waterfall/RUP for in-house enterprise software over Agile/Scrum/SAFe, etc.
Use something like Shape Up for a small web SaaS product, use EventStorming for a bank or insurance company, etc.
There were multiple daily standups, weekly standups, twice-monthly retros, monthly project updates, bimestrial project updates and quarterly workshops and offsites.
Which meant once a quarter you had at least 2 solid weeks of nothing but sync/update/standup/retro meetings to talk about the work you talked about planning to do, but failed to do because you spent all your time talking about planning to talk about planning to do it.
The two big weaknesses of teams I've experienced are this and not having decision owners.
It doesn't have to be the same person for everything, but having a single designated person to own each decision avoids meandering too much when you're uncertain, or getting blocked by debate when you're confident.
My favourite leaders have come in and quickly said "you guys spend too much time talking about making a choice, X is in charge of this decision, move on".
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).
I interned in the IT department (5 people for ~1500-2000 endpoints) of a large regional hospital with additional small local care instutions spread out over the surrounding towns/cities.
We had ONE meeting per week, every monday morning, where everyone told what they achieved the past week, what they planned to do that week and the department head handed down news from corporate to us (planned expansions, transitions in corpo IT etc.). That meeting took about 60 minutes and we were then all on the same level for that week with finer coordination done as required by specific incidents/projects.
Haven't yet worked in another institution with such a process but from my limited POV it worked really well, whereas daily meetings to reiterate the same things every, single, day sound like such a waste of time.
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.
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.
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
Agreed, that is the value of the stand-up, it is forced team communication. Most teams suck at communication so it can have benefits. If you have an amazing communicating team, you don't need them. The big problem that most meetings have is lack of agenda and a meeting runner who doesn't keep people on task. Most meetings end up with one person who can't debug X so can everyone help solve that problem during the stand-up. The point of listing blockers is to pull off a sub team LATER that can help resolve the blocking issue.
It is a shame because all of the corporate processes are designed simply to overcome poor and ineffective communication. If only we invested in teaching people how to communicate instead.
Where I am now, they have switch to SAFe which is the least agile process I've ever seen. Planning 3 months at a time is the opposite of agile. It is really just parallel waterfall that is run as "agile" day to day. It is useless. But the higher up want their meaningless GANNT charts so here we are.
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).
Should that information be part of a daily meeting that will be forgotten quickly or documented somewhere the requirement or documentation exists? How do you share this to someone off today..
Standups can be everyday and be useful. We do them via Slack and they take, maybe 3 minutes? 1 minute to perhaps type up your own standup to share and another 2 minutes to read the rest of the team's. They're quick hitters to get a simple baseline of the day and a snapshot from others on where they're at. Sometimes it can be redundant if you spoke to someone else the evening before about a thing they're trying to do, only to read about it in some form again the next morning. But that does not happen all that often.
Unfortunately, going to once a week or twice a week means teams will tend to drag them out for longer. They become more like discussion meetings or "status" meetings rather than super brief snapshots of the plan of attack for just one day.
The biggest reason to have them is when you have a ton of junior developers who are not very good at unblocking themselves by asking for help. I’ve found it’s invaluable to probe them when they’re stuck on the same ticket for multiple days but haven’t asked for help.
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.
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.
> 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?
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.
> 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.
> 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.
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.
> 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
And... it likely is more efficient in those scenarios. If something can't be resolved via 1-1 in less than, say, 3 exchanges, get everyone together for a synchronous meeting. But have that be the exception.
Not to mention said manager is (for some reason) laboring under the false assumption that most useful software development tasks can be accurately estimated.
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.
everyone can see it on issue tracker / Kanban board / etc.
> 3. Any blockers or risks you have identified.
for any blocker/risks I'll encounter, I'll send an email (and file bug/issue/ticket) immediately - no need to wait until the next morning.
Why do we need to use tools that less (or no longer) technical people can understand, if we still required to duplicate this data in email (or god forbid in actual meeting)?
This only makes sense under SDLCs which don't require detailed task breakdowns, like RUP, mini-waterfall, or Shape Up. But Shape Up provides some good solutions for risk management/status updates (e.g. Hill Charts [1]) without going down to daily standups.
Everyone can, but why would anyone do? Our default state is "I don't care what you do, that knowledge is a distraction detrimental to my own work. Ideally I'd want you all to work, if you have to, when I don't". The rituals exist to break down those walls, even if just a little.
It's best illustrated by the author's failure indicator "If the manager or “scrum master” can’t show up, the stand-up doesn’t happen". That's so very telling.
The alternative approach of the chat reminder tries to minimize friction (short writeup is so much easier to consume than trawling The Board) instead of forcing everybody to be present (and presumably listen, which does not necessarily happen)
Some of us do care and see the big picture of things, but that mostly limited to tech/product companies/startups, much less so to enterprise employees, or agency-supplied contractors.
I.e. it boils down to incentive alignment, and to a lesser extent professional curiosity.
> "I don't care what you do, that knowledge is a distraction detrimental to my own work."
Agree, so it doesn't matter whether this distraction is done by issue tracker, email, or an actual meeting.
At least in the issue tracker case it's stored in a structured database which I can easily query (even programmatically via API/bots), and much less distractive than in email/meeting.
Only if you have a perfect board, no things ever come up out of order, a be everyone has the same idea of granularity. In practice, no, that information is going to be either unclear or wrong.
I don't think this is necessarily true. If an engineer is blocked on a difficult problem for a day they don't have time update issue tracker to say they are blocked.
I personally mostly worked under SDLCs were the developers have autonomy and do task breakdown by themselves, rather than by being assigned by PM/SM (except bugs/support tickets).
If that's a psychological issue, not sure daily standup can help here, unless the PM/SM will try to interrogate that person, or try to guess if somebody is blocked.
> 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.
>> 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.
> 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.
Sure, but you are still unlikely to realize that you're blocked by that exactly at the start of your day. Once your blockage has been communicated, likely in the middle of your day, the state will remain until you are unblocked. There is no value in repeating every day that you're still waiting on Outside Vendor. The blocking state has been addressed. It is known that nothing will change until the state has changed.
And it is not like Outside Vendor can update you in an internal stand-up on why it is taking them so long, given that they won't be present, so you're not even getting that value out of bringing it up again.
It's not about being territorial, it's about ownership. I assume you work for a small company. At Big Co. there are thousands of services and APIs. You can't give default permissions to everybody to call every API. That would be a giant security lapse. Other teams let you modify their code but only after they thoroughly understand what you need to modify and what is it that that you are tying to do. They own the code and run in production. So it makes sense for them to critically evaluate whether you should be allowed to do what you are trying to do. All of that takes time and hence multi-day blocker.
Generally we don't go walking through other teams code bases unless we have to and we usually consult with the team before doing stuff. They just don't let their roadmap block our roadmap.
We don't use microservices. That helps a lot. We also have teams that manage infra. We do own the code we deploy but anyone can jump in and help if a fix is needed.
Oh day to day blockers, especially when working on multiple things in parallel and you wait on someone else for some tasks. From our logs, some of our last few blockers were:
1) Waiting for someone review and merge a pull request so something else that depends on that can be sent for a release.
2) Some architectural code changes that needed to be discussed with the person responsible for the module before i go ahead with the implementation.
3) Someone waiting on me to finish the CI setup so they can deploy their project
4) Us waiting on external client for more input, so our CEO can go nag them for more requirement updates.
5) Me hoping the someone can fix the frontend code because i was frustrated with my (lack of) CSS knowledge the previous day...
None of those will come up at the beginning of the day. They are impediments that will only be revealed during the course of the work. Are people refraining from sharing important knowledge as it comes available so that they can grasp at something to share the next day, perhaps because reciting "no blockers" each day grows incredibly tiring? If so, how is that beneficial to the team being left in the dark for longer than necessary?
I've worked under that "today/tomorrow/blockers" regime before and never once, in the years we labored under it, did anybody report a single blocker besides "my computer crashed, waiting for IT to fix it".
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.
> “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.
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.
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.
You're right and I agree with your proposed solution. Having no (useless) dailies at all is even better than having them midday. But I'm fighting an uphill battle here, especially as freelancer.
I'm always a bit amused when Product Owners are suprised that there's nothing to clarify at a daily since the team is constantly transparent towards each other about blockers etc.
But I'm fighting an uphill battle here, especially as freelancer.
True. Whenever I've done freelance/consultancy stuff in the past my rule has been that if a client invites feedback then I'll test the water once. If they're receptive I'll elaborate. Otherwise I'll usually drop any process-related feedback and fit in as well as I reasonably can with everyone else since IME that is normally the most effective way to work in that kind of environment. It's always a bit disappointing if you can see a client making obvious mistakes and you know how to fix them but sometimes it happens and if they're not interested in changing then ultimately that's their decision and their responsibility.
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.
Out of curiosity, how does a "no politics" rule work in a scenario like this? Unfortunately we're currently in a scenario where a queer person saying they had a great time with their husband/wife/partner over the weekend can be stretched to be a violation of that rule by mean spirited people (to put it mildly). I'm not saying this is the case, but I'd personally be uncomfortable sharing in environments like that because of such rule.
That said, having a scheduled 15 minute "hello" meeting every day sounds great! I feel like seeing my coworkers and saying hi is the most value I get out of daily standups, so your team's approach sounds great to me.
We've got people of all religions, nationalities, etc. and it's very rarely a problem. How we hire and the effort we put into curating our team culture goes a long way in helping with that.
Sometimes we do fall into political conversations though - politics being a massive part of being human after all. But when we do someone says something along the lines of "alright guys, this is starting to sound a bit political so let's talk about xyz instead" where xyz is your favourite funny cat video or similar.
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.
I would argue that it's a cynical way to look at the world, and it doesn't foster an environment for collaborative, clear-thinking problem solving.
Most things we do simply aren't political (at least not intentionally, not saying they can't be interpreted by others that way), they're just things we do from being on autopilot most of the time. And I strongly want to give people the benefit of the doubt unless it's quite obvious that they meant some form of malice by an action.
I still have no idea what most of our employees' political leanings are. What is important to me is that they are (genuinely) kind and respectful to each other, have a desire to work together, and that we are solving problems and helping our customers every day.
It's important to me that people have one place they can go to, where we work together as a team to focus on the problems we and our clients face, and come up with solutions to those problems in as objective a way as we can, as fellow human beings. That's the kind of team I would want to work with. And since it's in my control, I'm making it happen.
Not saying everything's perfect obviously, we're all still human, but we do aspire to preserve that aspect of our culture.
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.
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.
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?
The most common counter to the idea is "but some people don't communicate because "new/inexperienced/personality". Despite being expected to be fully functional adults in many ways and frequently given far more freedom as kids, status quo management seems hellbent on making adults seem incapable of basic communication in a corporate setting.
I don't necessarily disagree with that notion, but there are a lot of inconsistencies if that's the limit of what can be expected from an adult (Why are drinking, driving and taking on massive loans allowed?). Plus in the context of software development, we can easily set up
automated communication frameworks to catch the majority of it.
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.
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.
The interesting thing is: if Agile was invented by software engineers, how come it ended up disfigured in the hands of PMs, reinvented as Agile Coaches? My 2c theory: because the tenets of the Manifesto do not generate interest on the average developer demographics.
Because it's much easier to implement a set of concrete guidelines (have a daily meeting, use story points, etc) and turn them intro strict rules, than to implement the more fundamental but less concrete guidelines (individuals and interactions over processes and tools).
The same reason folk religion often focuses on hard, measurable rules (don't work on X, don't eat Y) instead of the more fundamental abstract ones (treat your fellow man as you want him to treat you).
Because it was invented for enterprise/consulting shops, not for product/tech companies.
For any real dev daily standups sounds as an idiotic practice.
If you're team is so disorganized that they can't collaborate effectively using bazillion of existing tools, and without hand holding/baby sitting of the "Scrum Master", then it's better to fire everyone, and build a new one.
I feel some negativity from this question, but I will disregard those feelings as unfounded and try to answer in the best faith possible.
No, I have not considered trying it out, for a simple reason - I don't control any organization nor work in a management position, so I don't really have a chance to do so.
I'd like to believe that I would try out all those things that come to my mind, if I were to have a chance to do so.
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.
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.
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.
"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.
> "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.)
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.
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.
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.
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?)
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.
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.
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.
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.
Async crowd is not mad at all! And in fact for a truly global & remote organization is impossible to schedule time for everyone. Just open your work email at times you work. Done.
I totally agree with you, but you can see even in this thread where people say things like "If a call to action exists the receiver will get mad at the 9pm email...What I don't know is the senders expectations of when the email should be checked"
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!" :-)
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
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.
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/... - 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.
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.
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.
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.
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.
Points for keeping one day meeting-free and batching meetings together. Deep work is the only useful kind of work, so getting one day of that is something! I'd be radical and suggest another of those deep work days to double productivity, but refering to your last point, organizational changes initiated by the team members are rare.
Generally, good changes would require scrum masters and tech leads to work harder, to really get to the bottom of a wide range of issues outside of superficial meetings, to actually understand how developers, testers and devops struggle, and to solve those problems. But it's easier to put the burden of articulating problems through public speaking on generally introvert developers who then risk incriminating themselves in the process.
> 2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around.
In a work environment it is extremely hard for people to truly enjoy jokes and chats when everyone, including soft leadership, is present. People are very much concerned with their standing within the organization and if they are good enough to remain, or advance. If that is not an issue, frustrations with many work-related disappointments and sometimes colleagues are main concerns for software people. It would take a truly remarkable individual to lead such a casual time of cracking jokes in everyone's second language in multicultural teams over video call, when their livelihood or sanity is on the line, rather than it being a stressful performative act for half the team.
It's interesting how people bring their own context and culture into things - which is where I assume your comment comes from. Also another reason why one size fits all processes or methods are not a good idea.
My team is a monocultural one, in a Nordic country. We're remote by choice, and because some of us live in other cities. Nordic countries have the lowest power distances in the world, which is relevant to how social interactions work out. Also, in my experience, software developers here don't typically worry that much about their standing in the organization, or about advancing in the organization, or being kicked out. Of course some do, but I don't think it's a cultural focus here like it might be in some other places. If you look at the discussion forums for devs here, those concerns hardly ever come up. Talking about raising salary by switching companies is way more common topic.
We have plenty of time for deep work on other days too. It just that in earlier phases of the project there were more meetings, so we set up the deep work day to make sure one day can be totally uninterrupted.
When it comes to articulating problems, I feel our people are vocal enough. Not all the time, but if there's something annoying or frustrating during a sprint, I feel that it comes out during a retro. It's the process improvement ideas where I feel like I'm the most active one - which is fair enough, since it's an area of interest not all people have.
> but they don't seem to have quite the interest in tinkering with these things I do
They are probably bored and planning an escape. You have no idea how visible the scripting is, including all the fake joking around step. Engineers are not children, and if they are you hired the wrong people. Let them get on with work, and do a weekly or by weekly standup instead. Be sure to … “empower” them to talk to stakeholders and let them be proactive.
There's several assumptions I read from your comment:
- A guess with a high level of confidence at mindset of people you don't know, and their mindset in situations you're not in.
- Assumption that joking that may happen is fake, again with people you don't know.
- Assumption that a weekly or biweekly standup is ideal for a team you know nothing about - which implies that it's ideal for all teams, of all experience levels, in all projects, in all fields, in all organizations.
Consider that you may not, in fact, be able to justifiably draw these conclusions from the text you just read. Also consider that whatever the personal experience that informs your conclusions is, it's probably not applicable everywhere.
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.
>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.
Sorry but that’s not trust, that’s distrust. If you trusted your team members, you’d see the clear efficiency in having a single, shared place to check what people can do for one another to make doing the work easier.
You don’t want to communicate on a daily cadence because the communication costs you more than you get out of it. That’s a problem. You should be demanding a daily standup, not running from it.
How about we stop pushing one's own way of working and way of thinking as the absolute truth? If stand-ups were truly the panacea you claim they are, it would be beyond trivial to find evidence in the decades they have been used. Yet that hasn't been the case, and debates devolve into clashing rationalities at best, fanatics ignoring or fighting each other at worst.
>You should be demanding a daily standup
The only things I demand from people in a professional setting are progress and results. How they reach is none of my concern until it is evident intervention is required. A daily standup does not guarantee an improvement in either of the two.
You don't get to have "your own way" of working entirely, as you work with others. Even if you don't get value out of daily standups because you don't know how to make use of them, others won't let their inability to understand the process stop them.
This is not a "different ways of working" thing in the same way as "I don't use a keyboard" isn't a "different way of working".
This is 100% a "you" problem if you can't figure out how to get value out of a daily standup, and whoever is leading your agile effort should be helping you.
Honestly I'm tired of people like you getting a pass, which you've clearly become accustomed to, but this one is so basic, so easy to do correctly, and so easy to extract value out of, you must actively be fighting the system in order to struggle at this point.
You literally go through a list of in-progress items, and people say, in a sentence or two, how they've moved that work forward and any issues they've encountered. Other people listen, and chime in if they can help, and stay quiet if they can't. It's dirt simple, and isn't replaced with async anything, as a) it's very quick and costs extremely little and b) there's no other way to know if what you're working on is relevant to other folks or not.
Have your noticed how there is hardly any agreement in this thread? Your opinion is one of many. You find daily stand-ups necessary and valuable. I don't. find them harmful.
Everyone's opinion is informed by their own experience. In my experience, a standup is about as valuable as having a conversation with a brick wall.
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."
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.
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.