We Don't Do Daily Stand-Ups at Supercede
jezenthomas.com
jezenthomas.com
I must have been a “lazy, incompetent manager” by the words of this author. We had few-times-a-week stand ups because:
1. I suggested we do daily standups when COVID (and with it, WFH) started and review how it goes. A month or so later, checked with the team, and we decided to reduce it to 3x/week. We reviewed this later every now and then and the team decided it still works, so we kept it.
2. It was the very few times a week when everyone from the team got a sense of what everyone else is doing - and how they can help. We cheered on successes, cracked jokes, and shared information. Call me old-fashioned, but I really liked these occasions, as it gave me a sense of belonging to a group of people. And no, this was not about me, as a manager wanting to micromanage.
We were a team in one location/timezone, and this standup was one of the few things that helped feel connected. We also had multiple recent joiners with less industry experience who found the standups far more important/engaging than most others: this is also a dynamic worth noting (that will not apply to every team).
I’m not arguing that this works for everyone, not that it’s the way to go for a distributed team across 6+ time zones, like the company of the author is set up.
But assuming the world is black-and-white (“daily standups: bad, managers insisting on daily standups: incompetent”) is ignorant thinking at best; deliberately wanting to spark attention so people like me to grab a keyboard to type this out at worst.
I’m happy this team figured out what works for them: I’d encourage all teams to find your jam. And don’t assume everything else must be bad.
Not saying this is the case with your team, but be aware this can happen.
"Do people want to continue doing this thing that we always do, that I come out of my office and round up everyone every morning and lead as your benevolent leader, or does someone else want to say my way is bad and have an idea on how we can achieve a not necessarily defined objective?"
There's a reason why voting in democracies tends to be done via a secret ballot.
Some communist asshole wanted his nephew or something hired for some government position. He made the mistake of doing a vote by asking "all in favor?" because no-one raised their hands. What Suvorov suggested was the guy should've used "all opposed?". He said no one would've raised their hands neither but the result would've been very different ;)
If a manger thinks that that's not the case in their particular team, and the team members always speak their mind, then I have a bridge to sell to that manager.
Or to look at it the other way around: how many times engineers themselves _asked_ their manager to do those stand ups? Yep, wouldn't be that many.
I’ve personally tried to earn as much trust with actions as possible. E.g. this was my approach in having (eventually) all team members lead projects [1].
For example, on the projects people led, I gave them free hand on most, if not all things. People were free to decide how to do standups (or not do them at all, like some did) and hopefully these experiences helped them both shape their opinions and share these more freely in other situations as well.
As an engineer, I also hated being micromanaged and remembered situations when I was not comfortable speaking up. I tried to remember all of these and create and environment where this does not happen - eg never shoot down anyone’s idea, don’t assume I know better just because I have a manager title. Basically, try to live up to the manager I would have wanted back in the day.
And yes, managers’ words always carry more weight, which is the nature of a hierarchical dynamics (as much as I wish it was less so). I don’t know how to counter that beyond trying to foster a safe place where criticising the manager (me) is also completely fine, and to be celebrated (as it takes courage) and never result in any real or perceived retaliation.
[1] https://blog.pragmaticengineer.com/a-team-where-everyone-is-...
This will never be the case. Never. Engineers can sometimes be slightly more open in technical arguments... senior engineers to much lesser extent - seniors learned that sharing what everyone truly thinks is prohibitively expensive to their career, no matter how much amazing boss you think you are.
Anything more than technical stuff, especially management style -- forget it. No one will share what they think, unless the situation is beyond repair, and at this point junior engineers will rather share to the skip level manager or HR (futile, thus junior engineers), and seniors will just a) check out or b) leave.
> foster a safe place where criticising the manager (me) is also completely fine, and to be celebrated (as it takes courage) and never result in any real or perceived retaliation
Cute.
There's one thing that gets utterly lost in the discussions about standups vs. async that bothers the hell out of me: in the end it's about people and how they function as a team.
Any manager proclaiming "the way we do it at company X is the way, and everyone else is incompetent" is way over his head imho.
The essence of the matter is simple: in person meetings CANNOT replace textual documentation and proper task workflow. And writing everything down is no aid when it comes to human relationships in company culture.
There's a big point in what you are saying: ask your team! And make sure you have built the trust and culture needed to get true answers.
There's nothing wrong with periodically talking to each other and it does wonders for how people feel about their peers. The pitfall is when spending this time together is mandatory for the workflow to function, and above all, when one or the other workflow is forced & sole source of truth.
Have standups so extroverted team members can socialize and ponder issues together. Have a kanban and issue tracking so introverted team members can stay in the loop. Use both tools to maintain the big picture as a manager.
What fucks up companies is not "the wrong way of doing things", but forcing individuals to partake in a mode of work that isn't right for them because "that's how we do it"
This comes at the expense of the morale of the less extroverted members of the team.
Furthermore, strengthening social bonds is too important to be relegated to being an incidental side effect of a daily status meeting.
To clarify: at Supercede we hold informal coffee break chats (and also some other events) expressly for the purposes of social bonding. No obligation or even social pressure to join. Fancy coming along to gab with your colleagues? Great. Busy? No problem.
> I really liked these occasions
> the team decided it works well
One thing [people who become] managers completely underestimate is that they now have actual, real power, and that this dramatically alters the quality of the feedback they get.
You're not a neutral observer in this interaction, not by any fault of your own, but simply by the position you occupy. And there is virtually nothing you can do about it, no matter how hard you try. And no, it doesn't mean your team is actively trying to please, it just happens that way.
As an example (not quite the same thing, but similar): one time that I was managing a team I was just finishing some stuff up on Sunday and sent some e-mails that went to the team. Then I got a response. That same Sunday. Note to self: even if you write that e-mail on a Sunday, wait until Monday to send it!
This makes everything more tricky, as it’s true that the same behaviour as a manager or as an IC spark different responses.
It’s a tough one to navigate and I won’t say I have it all figured out. It also makes transitioning into management a lot more lonely, in my experience.
Edit: just to clarify I don't mean heavy handed HR stuff. Just what OP said. Crack some jokes, tell a bit about your life.
Really great developers don’t need your help dude.
What value occurs in these meetings other than you getting to pry into the micro details of what everyone is doing for the sake of your own sense of control? Does anything really change that much day to day that needs you to constantly check in on what people are doing?
Sorry man - it’s clueless old school management. Creative developers don’t need to be harassed three times a week.
Extremely junior intern level developers might need it. Even then it’s excessive (3x). Anyone with experience will leave. My guess is you are the type that likes to build a little fiefdom you control, it doesn’t work anymore.
My entire career (20 years working at startups and fangs), the super star developers check in every two weeks. Or maybe a once weekly sync. 3x is …. Why?
To avoid silos and silent struggles, and to have the "superstar" devs support those "extremely junior devs".
If what you're working on doesn't require a standup, maybe it's not actually a team project?
To me that's a discussion to be had with the product manager, not a developer. The feature is either done or worked on and that's it.
"I'd like to at least have some idea"
How far behind can you really get? Are you not involved in code reviews? Unless you're working with people going dark and raising massive pull requests twice a month, I fail to see how you could get to the point where you have no idea of what's going on, or on the opposite side how you could have anything but technical and implementation details to share with business people.
Then you effectively have two teams, isn't it? I've been in the exact situation before and that's the conclusion we've reached.
With a very conservative two minutes per update and the absolute best conditions, you've got a 20 minutes standup at the very strict minimum, and that's with military discipline. How do you get to 10 minutes?
At this point, you're either not saying anything important or not having any discussion. In both cases, everyone would save time either typing a one line status update on slack, or having more thorough and focused discussions outside of standup.
In principle, but that doesn't mean you get two PMs now or that the customer makes a meaningful distinction between that two.
> With a very conservative two minutes per update and the absolute best conditions, you've got a 20 minutes standup at the very strict minimum, and that's with military discipline. How do you get to 10 minutes?
We tend to give a very short update on what we're working on and what problems we have encountered, 30s - 1 minute I would say. Then there might arise some quick interaction, oftentimes leading to more discussion outside of the daily with the people involved. We have ~10 teams operating this way, works just fine for everyone.
I'm wary of such situations because, in my experience, sometimes it's a customer or someone in a different team fishing for information that your PM doesn't want to give them. Your PM may have a good reason to be vague about things, and carelessly delving into details may make your team's job harder.
Everything else, especially big-picture questions such as the general state of a project, is something that should be dealt with by someone else. To do otherwise is unfair to the devs (because it's not their job and perhaps not their skillset), unfair to the customer (because they'll be getting information that may not be entirely correct), and unfair to the company (because it reduces the company's ability to provide accurate information to the customer, it may expose confidential information, and it's burning expensive dev time)
These are not supposed to make deliveries faster or employees happier. Agile is fundamentally a risk management tool. It makes it less likely that you'll surprise your customers with shipping nothing or the wrong thing after spending $2MM on a project.
Of course it's a compromise and it's not a silver bullet. If you can scale your organisation and avoid these risks in some other way (because all of your team members are diligent and competent, managers and leaders have large working memory, good technical and people skills at the same time, or whatever) -- then by any means, do that.
But in many cases, daily stand-ups
However, some team members thought this was “wrong” and “not how agile should work” so eventually after continuing complaining I had to reinstate/allow these stand-ups again…
Unfortunately, if those guys had gone up the management chain saying how you're "not agile", they probably would have won...
However, if people already do it, or once they get accustomed to doing it, I can see no good reason to keep up a ritual that's disrupting - at least in a remote team.
From what I've seen, a lot of companies don't see it that way however, they rather cargo cult "best practices" :/
Every single one happened because the project manager wanted it or the lead programmer (who, for all intents and purposes, was a manager at that point) used it as a daily status meeting. At its most absurd, at one company, it took 30 minutes or more, on a daily basis, to listen to inconsequential (to me) stuff. To say my line took less than a minute on most days and the others almost always used this meeting to start discussions that needed to be shut down. Which of course lead to more meetings.
Many complaints, and this article is no exception, are not about canonical "daily stand-ups" but about the meetings people experience in their team or their lack of understanding what the aim of "daily stand-ups" are and what problems they propose to solve.
Agile favours face-to-face communication because it's the most effective for quick discussions. The format of the "daily stand-up" is also specifically designed to focus attention of the participants and to make it quick. It is not meant to be a project or status meeting.
Ultimately organizations decide what's best for them but it useful to gather a good understanding of those rituals before trying them out and criticising them.
Hence my point: it seems like a good idea, appears to work given the proper circumstances but simply does not most of the time, given the reality of many workplaces.
In another project we followed the 3-question rule (what did yesterday, what do today, what blockers) verbatimly. Meaning, answering these three questions to a slack bot. I'm not sure the answers were ever assessed, so not sure about how well tracking our team performance was.
These two examples showed me that taking daily standups to the extremes and never reflecting on this ceremony at all is the bad thing, not the daily stand-up per se. That's why I also find this article a bit...extreme, and therefore not necessarily applicable to every team.
1) it's great for refocusing everyone on monday first thing after a long weekend of hopefully for getting about work
2) it's much easier to follow up with people as a ritual rather than a 1 on 1 interjection, it depersonalizes info gathering that'd be hard for a manager to acquire any other way. Vocal tonality says a lot sometimes.
3) it's a great way to give casual encouragement and recognition occasionally
That said, I only think standups are needed maybe 3 days a week and 10 minutes max usually.
All three of your points suggest you see benefits for the general team member, but when you were the recipient of the 1) focusing / refocusing, 2) management follow up or 3) encouragement and recognition, you yourself did not like that forum?
Is it possible that your team feels the same way as you did when you were in their position?
3) makes me cringe - the carrot of public praise for doing your job, no thanks. Around the table of peers - everyone knows who has done what. Its up the organasation that the recognition needs to go, and for every manager that is passing it up the org, there is another that is taking credit themselves.
If a manager is there for the standup, it's not a standup at all. It's an "update management" meeting. Not saying there's anything wrong with that, but that's what it is.
Not saying it's not, it's just your points come across very first person.
It's nothing utopian, we don't have project managers join stand-ups.
> Given that our team are distributed across several time zones, it is logistically infeasible to hold a daily synchronous meeting.
I understand that stand-ups are terrible for global distributed remote teams because people need to adjust their time.
But there's no need to ditch it as a whole. For onsite teams, it can be good: A team that only uses WIPs, no deadlines. The stand-ups are just a very short and informal meeting to let people:
1. Synchronize what other people are doing, in order to avoid conflicts and reworks.
2: See if anybody needs help.
And that's it. We also do some funny gestures that do not hold, or do heavy-lifting when speaking just to make it quicker and more informal.
It's just when the culture is bad, the stand-ups would be one of the whips that bad managers could leverage. If there are no stand-ups, they could still reach for other tools.
To practice stand-ups properly the key idea is to have a no accusing or shaming team culture. Strive for it even if you have a little bit of power to practice; Protest it if you don't; Leave if you can do nothing about it.
This reason has always struck me as weird. Surely (as the article points out), people are asking for help as soon as they need it, not waiting until the next standup.
In practice, it's more of in-betweens like "I can figure it out slowly" or "I didn't realize Jerry could help me just like that".
When people encounter obvious blockers or they have no clue they will ask for help, but not so much for those "in-between".
Another scenario that often happens to us is one task is being pretty much depended on, and if there's an "in-between" like I just said, it's likely to make the team run out of task for a while. People on the task may not be paying enough attention to each other's progress, leaving them in blind spots compared to the team lead. Stand-ups are great for spotting those problems and tackle them early.
I introduced Scrum/Agile to my current company after having used it successfully at my previous job.
It was a little tough at first to get the project managers to understand that the daily stand-up was not for their benefit, but simply for the team to understand what everyone was working on and as a place to raise any issues. There was much gnashing of teeth as the stand-up replaced a daily check in call they had where devs had to report their status to the PM. But, a few sprints in and the PMs were happy to see results without having to be in daily status calls. (They are still invited to the stand-ups, but only as chickens)
For me, the biggest benefit of the agile/scrum process is the sanctity of the sprint. PMs don't interfere inside the sprint by changing goals or micromanaging, and devs promise to deliver the work from the sprint on time.
At the previous job, we had a dev team spanning 10 time zones. So I continued the practice of having the stand-up as a quick note in a slack channel, but the new team really wanted a daily meeting (via video conference). At the new job, we're all in the same timezone, but across multiple locations. So in some cases devs really like the "face to face" meeting.
I get that it's hard for some people to participate in social situations (I'm one of them), but if you can't muster up the strength to get three sentences out (I did this yesterday, I'm doing this today, I'm (not) blocked) then you might have larger issues. :)
But this misunderstanding caught my eye:
"The status of in-progress work is the remit of project/product managers."
A product manager's primary responsibility is to make sure the team is prioritizing correctly, i.e. that they're working on the right things and for the right reasons. Secondary to that is doing whatever it takes to unblock people's progress, e.g. when it's hindered by lack of access to resources, lack of coordination with other teams or external parties etc.
But who is responsible for the status of work? Obviously, the person doing the work.
A product manager isn't an 'engineering doula' monitoring people and telling them to code faster.
If you have a proJECt manager, perhaps you're working in an environment where deadlines are very rigid and/or there's a lot of coordination required to release things in sync with other teams (e.g. if you're shipping hardware, or annually-updated tax software).
Perhaps OP missused this tool and poorly communicates his own frustration assuming everyone else must be incompetent to use a tool he doesn’t understand. A sad but common story of Junior staff.
Stand-ups as such are a band-aid to fix an easy to spot issue, that you may as well resolve in other, non-prescripted way by some methodology: miscommunication within the team.
If your team is able to communicate naturally (morning checks, informal or formal reviews, lunch, coffee stop, walk, whatever...) you don't _need_ stand ups.
The problem is people joining well-functioning teams and saying "what? you're not doing stand ups? let's fix that"
No, it's not. It works for our team. We don't have the PO in our daily. If he likes, he can join as a guest, but he is not part of it. We, as engineers, use the daily to discuss the work for the next 24 hours - if there is anything to discuss. It works pretty well for us.
Not only did it save everyone reading out their updates while looking at their feet, or people saying things for the sake of saying things, but there was a detailed time log of what happened when (not just code, but also the bought process etc).
Blockers shouldn’t wait until the next day, and predictions of what is to be done that day are rarely accurate. End-of-day reports keep everyone in the loop without meetings, focus on accomplishments, and doesn’t require a blocking meeting.
A 15-minute standup does not nullify a stimulating work environment.
It should be more like a get-together just to take the general temperature, discuss any unforeseen problems or worries, etc, and perhaps notify any more detailed short calls, eg "hey Andy, I don't understand this part of your API, mind if I call you after this to discuss, as I';; be working on it later today", etc. ie part water-cooler, part play-plan.
PMs etc, should not be invited, unless they are required to help with something, this meeting is for the team.
The idea we need to "come together" to "talk about what we're doing" is invalidated if we can do this much better and more effectively when allowing for a decentralized and documentend working environment.
Why I prefer collaborating with designers who use tools such as Figma, is the fact I can annotate their work, not expecting an immediate response, but allowing them to handle my comment in an appropriate manner, when they seem fit, how they seem fit.
Almost nothing these days need an acute response.
Modern collaborative tooling has made stand-ups obsolete.
Ask Product Managers - they love standup. Counts as productive work for them
Ask engineers - they hate standup. Because these meetings actually get in the way of real work for engineers. Engineers don't need a standup to get in touch with other engineers. If something blocks them, they can reach out to each other immediately.
Stand-ups are clearly something to satisfy a manager's curiosity about their reports. But management really needs to take a hard look at introducing overhead to the actual producers.
More bureaucracy == less productivity
The blogpost starts explaining that they don't do daily standup because they are using a distributed team all over the world which makes it hard to gather the team for a daily standup. To me this makes perfect sense. There are many good ways for a team to be communicating and working. Everything doesn't need to be lean.
but then author carries on and the article becomes very weird:
"If daily stand-ups really are so awful, why do some managers insist on them? Hard truth: it’s because they’re lazy, incompetent managers"
"Daily stand-ups are not only a waste of time and make software development more expensive, but they demoralise developers and make them want to change jobs."
What works for me might not necessarily work for you, and vice versa - to indicate otherwise strikes me as unprofessional, unsympathetic and demotivational.
And, worse perhaps, there are a lot of incompetent managers that are NOT lazy.
Now, the OP is a specific point of view. It's not unprofessional to have a clear cut point of view on some arbitrary practice.
It's no unsympathetic neither demotivational: from my pov, it's rather a sign that everything may not be lost in IT if there are still people thinking differently.
I also agree with you with your statements. I used those words in the context of the article to make a point.
It sounds like you're talking about a non-toxic organisation. I believe the author is talking about what they've experienced in toxic organisations. I guess the problem is that everyone brings different experiences to the table, and a burned child fears fire.
In the context of toxic organisations where stand ups are a top down mandated micro management tool, I find your comment about intellect and disinterest a bit unfair.
Even if you didnt accomplish anything visible that day, for whatever reason, it's just part of being a mortal and just saying so can help normalize it as well as set a realistic expectation for the team.
edit downvotes for empathy :) HN at it´s best!
> or social anxiety, or they haven't learned that skill or they have been stuck on an issue with no progress
> or they've learned management makes their life harder
are radically different problems; the former two belong to the developer, the latter to the manager.
Actually, standup is the best opportunity to communicate that there is a problem (a dev stuck with an issue) and find out how that can be better approached/solved.
It feels like people who don't understand why so many developers hate daily stand-ups doesn't understand social interactions at all.
Why does working have to be exactly like social interactions? Btw what definition are you using? Social interaction in a party? Do pilots in the cockpit wilfully not communicate statuses because they hate it and just want to be chill?
When will you graduate from school? I wanna send some flower.
In case you didn't have a unproductive day there is always something to tell on what you were working. If you were stuck on soemthing and debugging it for 6 hours and have nothing to show for it then tell that you spent 6 hours debugging, someone might even offer you help :D
Have some empathy bro.
It's really simple, whatever it is, just say it.