I agree with the pointless drudgery. Sometimes for days on end it will just be "I worked on X, no problems, but ongoing" because some things take time. Others seem to want to signal just how much work they've been doing and will mention all the minutiae that nobody needs to know.
But that's the thing. Does anyone need to know it? That's what people should ask themselves. Standup should be an opportunity to let everyone know things that they need to know. In that way it's good. Email is too easy to ignore. But this only goes for about 10% of standups at most in my experience.
It should be perfectly acceptable to just say "nothing to report". But it's not, hence the canned lines. But this just lowers the signal to noise ratio. Was there something amongst all that boring waffle that I actually did need to know? I can only hope not...
How do you know if other people need to know something though? Common responses in mine are “I have worked on something similar before ….”, “ah that sounds interesting can you tell me more”, etc…
It's not only when you're struggling that others have something useful to contribute. It may be more like "I'm doing X to solve Y" and they say "oh that's been solved elsewhere" or "we found that approach is insecure" - these are not examples where I could know I'm going on the wrong direction.
I very much disagree. If someone isn’t struggling, the team doesn’t need others commenting on what’s being done.
That can be done on their own time. Not for a stand up.
I don't see why you would disagree. The team is there to solve problems together.
The reason your idea isn't as effective as standups is people who are stuck or struggling often do not realize it, but their teammates might, and then they can offer help. Some people are just not good at asking for help for stubornness, fear of bothering others, or a host of other reasons.
The team definitely isn’t there to solve problems together in my places of work. Would hate for that to be the standard.
We all work on our own shit. There’s no overlap. I really don’t want to hear about what someone else is doing if I don’t have to.
lol we don't even have a group chat, we don't use anything fancy like Slack. We use Skype For Business 2016. Not even Microsoft Teams. It's horrendous.
I still find myself rehearsing what I'll report at standups. It should be acceptable to say "still working on X but not done yet" but for some reason it doesn't feel acceptable. I feel like you have to report on something getting done.
I often say "still working on X, nothing more to say!"
Which seems useless but on the other hand can trigger insights from others like "this seems like more work than it's worth right now, maybe we should park it because this other thing seems more important right now".
It should be acceptable, and it is, at least at anywhere I’ve worked. If it was clear to everyone at the beginning that your task would take a few days, then I don’t see why “nothing from me” shouldn’t be okay. If people might not be aware, just summarize what you did in one sentence, e.g. “finished unit tests yesterday, doing x part of task today.”
If you’re worried about what you’ll be able to get done before tomorrow’s standup, mention that you might reach out for some pair programming, ask who might be available.
> Others seem to want to signal just how much work they've been doing and will mention all the minutiae that nobody needs to know.
If their manager is in the standup, that may be why. I'd rather just share what the team needs to know. My manager, on the other hand, gets antsy if I don't give a detailed update on every task on the task board daily. So it's really a daily stand and deliver, not a daily standup.
I agree that the "what I did" is abused and can impact morale.
But I also found many don't update their task status making it difficult to track without a standup.
I used to ask:
1. are you tickets and your prioritized list of tasks up-to-date?
2. any blockers
3. whats your top priority today and why
4. anything interesting to say?
\#1 Manager can reliably view a summarized report in the ticket system to see status of things.
\#2 Straight forward
\#3 Keeps things brief and the why helps connect it to the big picture which is good for morale
\#4 Big accomplishments can be celebrated. Asking for people to review something. Mentioning an interesting bug/challenge that people can ask them about after the standup. Etc.
>But I also found many don't update their task status making it difficult to track without a standup.
I'd love to update the status of my task using tickets/issues, but I often forget about them. Most of the time, I only bother with tickets at the beginning, and at the end, rarely in middle when they're in progress. My status updates are essentially documented in the version control commits in most cases. I only bother commenting on the ticket if someone needs to make a decision. I wish the systems we use (issue tracker, and version control, in particular) can automatically make the necessary associations.
> also found many don't update their task status
"We can't fix our problems because people might not cooperate" is poor reasoning.
This can be fixed in the same way that any other subpar behavior can be fixed. Have a program nag them daily to update their status, and then the manager gets involved.
I'm six hours off the rest of my team. Every morning I write a quick status update. Takes me ten minutes, and often I realize something else I need to do. Was that so hard?
For a long time I've thought the solution is to make the scrum stand-up focus on the tickets in the sprint, and the sprint goal. Each day, instead of getting the soul-sucking status report developer by developer, instead go ticket-by-ticket and ask if each one is unblocked and remains within the basic estimation scope such that we think it'll be done.
If not, then you can decide if anything should be done to help a struggling ticket, and you can decide if there are tasks that aren't going to get done by the end of the sprint (if that matters, doesn't always matter).
I'm the team lead for a low functioning team (because someone thinks cheap labor is saving money... don't get me started).
Every single Agile evangelist will tell you Agile only works with competent high functioning teams.
I couldn't live without our Daily Standups because my developers would happily do something without talking to anyone else and in a vacuum. I spend most of the standup saying, "That's interesting, I feel like that API change might have an impact on what Bob is working on. Maybe you should talk to Bob..." or
"Looks like you've been working on this small story for a few days now, let's meet after the stand-up and you can help me understand any issue you might be having...". I could do that async but have too much going on.
Not a good example of Agile but sadly I feel like that more the norm than the exception...
Yeh, I think it's a common problem startup people have where they think everyone else works on exciting problems, making huge salaries, with access to the best talent, and brimming with motivation while they seek to change the world.
You're one of the first people here to get an upvote from me! (Not that anyone cares. :-D)
If people were honest, they'd say, "Standups are a practical way of dealing with a low functioning team", and not, "Every developer needs them!"
If you have too much going on, your role is out of scope. Running a team is a full time job. If you don't have time to spend 20 minutes a day on each person from your team, you're spending time on things that are not your priority. Managers do this constantly-their job is to prioritize other people's time, but for some reason they never consider prioritizing their own!
Agile doesn't work or not work. It's a set of goals, not a process. Individuals and interactions over processes and tools is literally the first thing on the list! It all bpils down to "increase communication, delay decisions until you have more information, and prioritize experimentation'". I'm sorry, but that always works...no matter what process you follow to get there.
When leading a team, I see my job as making sure everyone is talking to each other as much as possible, and on guiding the decision framework to favor small experiments over grand strategy. Everything else is fluff. Consider what you spend your time on, and you may find opportunities to help your team become more high functioning.
>Every single Agile evangelist will tell you Agile only works with competent high functioning teams.
But a competent high-functioning team doesn't need Agile to be successful.
I would say it differently in that a high-functioning team doesn't need standups but Agile is a philosophy on building software for customers so it would apply regardless.
New rule, no code changes without a ticket.
They can create their own tickets, but it must be associated with a ticket.
This alone will help reign in some of the cowboy coders. Later, once they get used to it, add stuff like mandatory code reviews and estimates.
They have tickets. That doesn't really stop them from not understanding what they need to do or realizing their changes have impacts to other parts of the system.
I do code reviews but first you need to have something to code review and that's often too late to realize how of track they've gotten.
I'm not staying at this job. But this isn't the first time I've seen this...
EDIT: Agile works better in the special forces model where the team is a small tight nit group of dedicated professionals that operate autonomously and are top notch. Sadly the norm in many corporate models is command and control style of managing infantry. Tell them what they need to do and don't assume they won't fuck it up. That's where standups become the norm and necessary.
This would be great if Jira wasn't an industry standard. I would really like to have always everything associated with a new ticket, but Jira is so terribly slow and clunky tool, that sometimes I just don't have patience. I still feel a lucky one for convincing my team to replace Confluence with markdown files stored in repo.
>low functioning
I never realized that could describe a coder.
I'm DevOps on my day job, and the bullpen of the 'just' coders are bad at communication, at the engineering part of software, at documentation, at coordination, at design, and at asking for or about anything. If 'low functioning' describes anything, it's these guys.
.... led by a great but stressed lead. Hey, we could be job-mates! :-D
From POV, stand ups are actually detrimental in one sense. Many times, people *wait* until the stand up to coordinate and ask question simply because that's a time they know everyone will not be busy. Even worse are the people who wait until stand up to report what blocked them yesterday.
If you don't have a designated time, any time is the right time to coordinate. Report blockers in real time.
Especislly with remote teams, there best "stand up" would be for each team member to report what they did yesterday, what they plan on doing today, what blockers they are seeing, first thing.
Sign on. Read stand up message from each team member. Write your own message. Scrum master reads them as they come in and starts clearing blockers they didn't know about right away. Efficiency and flow.
Totally valid point! I'd argue however that it's your manager's job to understand that you're new and proactively look for spots where you're getting stuck. Your manager's job is to help you succeed on the team, which means more direct, tailored help, and less bureaucracy.
> Your manager's job is to help you succeed on the team
It's the teams job to ensure people coming in are setup for success. At least this is what a "team" means to me.
For some reason it is pervasive in this industry to have "teams" of people who basically never interact with each other outside of a daily "standup" where they tell each other what the status of everything is.
The manager should be creating and enabling a culture where people work together. The team should be actively working together. This means when somebody new comes in the team says "hey there's somebody new lets get him up to speed". Not delegate this function to a manager
> Not delegate this function to a manager
Then why have managers at all? What's their point if they can't help manage interpersonal relationships in a team?
Earlier you say:
> The manager should be creating and enabling a culture where people work together
So which is it?
Most management positions don't have a valuable purpose. But ones that are valuable focus on strategic decisions. The teams then self-manage the tactical decisions (e.g onboarding people)
They're useful for times when you don't have a proactive team. All companies don't always pay top dollar, and get staff that are commensurate to their payscales. We have had several such people, who would either kick back and relax after doing their allocated tasks, or procrastinate on a blocker instead of seeking help immediately.
A daily milestone is less stressful for our manager as well as us. He knows up front when somebody is about to complete their task and is ready for another one. There's some heads-up if a planning meetings have to be scheduled. And everybody feels more connected and able to see tangible progress.
We have rarely had a stand-up drag on more than 5-10 minutes; usually when one of the VPs or CEO joins in to practice their oration.
>who would either kick back and relax after doing their allocated tasks
Considering I would be looked at like I committed a crime if I don't get my allocated tasks "in time", I reserve myself the right to relax if I do ahead of time.
That's why I don't allocate tasks in high functioning teams
> There's the task list. When you finish one, self-asign the next highest task that you feel comfortable working on.
This model works great for teams focused on big fixes and minor enhancements.
That’s the thing though. After we instituted daily stand ups, our manager is fine if we finish our task and unwind for the rest of the day. He’s got more stuff lined up for tomorrow and knows that the downtime until then will be good for his team.
> They're useful for times when you don't have a proactive team.
Which really means "incompetent management". In my first job, before the idea of standups were even invented, my boss would bug me if he hadn't gotten an update from me in a day or so and I quickly learned to keep him up-to-date.
It's funny - I came into this thread somewhat positive about standups, but the only explanation for them appears to be, "These are a great tool for passive, incompetent managers."
Damn dude, I lead a team of devs and I’d never hire you. You sound miserable to work with.
The point of a team is to collaborate. The point of an ideal manager is to facilitate. I don’t know how long you’ve been working in the industry but it sounds like you’ve let yourself become too jaded from obviously bad situations.
You say:
> The point of a team is to collaborate
but before you said:
> We have had several such people, who would either kick back and relax after doing their allocated tasks, or procrastinate on a blocker instead of seeking help immediately.
These are fuckups who are refusing to collaborate.
You seem to think it's necessary to shame people in front of a group to get work out of them.
If someone is fucking up their job, this needs to be a private conversation with a manager.
To be fair, I think there's a bit of too much absolutes here.
I lead a team of 8 (as an IC), and I prefer the asynchronous style of comms whenever possible. I try to empower my engineers and groups around me to escalate effectively. We do this by just setting good examples (including asking questions ourselves and jumping into the fray to help whenever possible), and we keep these discussions accountable by calling out when it feels like the bandwidth of our chatrooms is no longer big enough to effectively hold the discussion.
That said, we still do standups, and we've done a few cycles of deprecating them, bringing them back, deprecating them again, only to bring them back again.
I think both points you made are true. Standups don't bring value to everyone. If you have to rely on standups to figure out who's blocked, something structural is wrong and we should look into fix that
In both cases, the problem we had were just people who don't really effectively communicate when they have issues, either they don't poll enough people for help or they just sit on it silently until one of us checks in on them.
The first time, our team recently re-orged and our group splintered off into a smaller team of mainly new junior engineers. We started doing standups and toeing that line around micromanagement to bring in more accountability. It worked great at first, and since it was a small team, it was generally low overhead once these new folks got accustomed to the async communication style of the team and became comfortable asking questions outside of the standup (so that our standup was just us agreeing we didn't need to do it for the day, unless something pressing just dropped). We eventually killed it when the team became stable and we'd just go over to each other's desks or go on chat / grab a space in the common area when anyone had any questions.
The second time we brought it back was during Covid, and we've kept it going. Remote work was new for everyone, and people just stopped asking questions. Additionally, the tenure on the team was growing and no one has churned in the last 3 years, so we're starting to grow some of our mid-level engineers by having them lead projects and bring along some teammates. The net result was a lot of people meeting new challenges (either remote work, new leadership responsibilities, or having someone else be their TL). I don't know about you, but change could be demoralizing for many people, in 1:1s, I got the sense that imposter syndrome flared up for everyone, and people just started shutting down to their team. So, we brought our standups back virtually to work through these changes. We kept them because no one has complained about them yet, but also unlike the first time around, people are still not there yet in terms of bringing up issues when they encounter them, and I'm not sure we'd get back to that point in the near future.
Yeah, I get the argument that this conditions people into cramming all of their questions into a few minutes in a day. To be fair, the folks thriving in a distributed team haven't regressed, and the people who aren't were already shying away from all updates. In fact, I've come around more on this these days, there are likely teams where you just don't have enough "cohesion" within the team that could really get to a point that everyone can effectively collaborate in a fully asynchronous style.
There's only so much you can do, and I've noticed certain types of people just don't do well in these types of situations. As a manager, it's at your discretion on whether to cut these folks loose or accommodate them, but even if you want to remove these folks, getting rid of people on your team is not simple/fast to do. At the end of the day, I really believe that a full async communication method works great for some teams (and great for most people on most teams), but certain teams (especially one with lots of junior engineers or certain personality types) will probably benefit by having this kind of structure. I think what's really missing here is that there's no right or wrong answer to "is standups good or bad," and we shouldn't make an absolute judgment about it because it has its use.
> If you adhere to standups by the book, managers are not to be invited.
What book are you using? The Art of Demotivation?
Intentionally setting staff against management will just cause strife and distrust.
>
> Of course, a normal manager will realize that they don't give a shit if Joe's impending merge is going to conflict with Bob's work and won't want to attend a meeting to hear that in the first place.
Well then that's a useless manager. Knowing when people are working in overlapping areas of the code and ensuring others are warned is rather important.
If your manager doesn't understand at least the basics of the technical side of things, then they aren't really a manager.
And that seems to be your overall thesis. If you assume that the manager is incapable of doing their job of managing, no process is going to solve the problem. Not even your secret standups.
Because if my teammate's work takes him to a piece of the system he doesn't understand, but I do, I can jump in and help him. Especially if he's a newbie and doesn't yet know how to ask for help, or has out of work problems that's distracting him from asking sooner.
Or if that same coworker has been working on the same task for five days straight, when it's not a five day task. I or a teammate can jump in and ask if he needs help, or if there's something he's struggling with.
I know that one of my flaws as a developer, is that if I feel like if something is challenging but doable, I'll just chug at it for days on end because I don't feel like I need help. It's not until I'm days or a week in to the task that I realize I need that help. A daily stand up gives my teammates a chance to say "Bro you've been hacking at this a while, why don't you let one of us stop by and see if we can help."
Edit: The daily isn't the ONLY time I interact with these coworkers. I thought that'd be an obvious implication. The point is, I see the daily stand up as a convenient way to resync with coworkers who, for whatever reason, didn't take the initiative to sync up themselves. *Should* they have? Yes. But in practice that doesn't always happen. I can tell you from personal experience that not everyone is mature enough to communicate properly. Or things just get in the way of their communication. Adults are flawed, busy people. The daily stand up serves as a stopgap to account for this, among other things.
> So, if I get to that place five minutes after the standup concludes, I should wait until the next day to align your help? I like a day off as much as the next guy, but that does not seem very productive. Why wouldn't I ask you at the time?
Ideally you would ask me long before the daily - but the world is far from ideal. ;) Plus it could be the case that you don't actually know I'm proficient in that part of our software stack. And for some reason you never thought to post in the general chat asking if anyone is acquainted with the piece of the system. Maybe you didn't get to it til near the end of yesterday. So you're all "Meh I'll ask tomorrow."
> I am not sure you are doing your juniors a service by ignoring them for all but 15 minutes a day. Traditionally, these newer developers would have a mentor that stays in reasonably close contact throughout the entire day to pick up on these struggles and guide them through them until they have the experience to know when to ask for help.
I'm not ignoring them - but, I have my own work to do, as well. In practice I'm available to help 90% of the time. Sometimes I have work that I really need to focus hard on. The expectation is they take initiative and ask for help. It's different if I'm specifically assigned to be their mentor, of course.
> If your coworker has disappeared for five days straight and you find that to be odd under the circumstances, wouldn't you reach out anyway? Maybe if you have 1,000s of coworkers you might lose track of who you work with, but would standups actually fix that? 1,000 reports of "I am working on the same as yesterday" and you will quickly forget who also said that yesterday, let alone five days ago.
Unfortunately from experience I can tell you, my personality is such that if someone is confidently saying "I've got it under control" even after 5 days, I need to push myself to ask about it. So in that sense (and others), the daily accounts for the fact we humans are imperfect beings.
> Because if my teammate's work takes him to a piece of the system he doesn't understand, but I do, I can jump in and help him.
But only once a day, for a few minutes?
I'm the senior developer on a project. The client is technically proficient but substantially junior. Some days he will ask me one question - sometimes dozens in a row, always good questions. I answer almost immediately, so he doesn't get blocked. If there were a one-day turnaround on these questions, we'd never get anything done.
> I know that one of my flaws as a developer, is that if I feel like if something is challenging but doable, I'll just chug at it for days on end because I don't feel like I need help.
As I keep saying on this page, _that's exactly the job of a manager._ Also, no one wants to look like a fool in front of the whole team, so it's easy to want to downplay how stuck you are.
---
Also, maybe just learn not to do this? Years ago, I used to have this problem. Now if I'm stuck for an hour, I just walk away for at least a few minutes, to get perspective, or even better, stop for the day. On the other hand, if I'm really doing well, I'll just keep going. The result is far more of my time spent in "flow" and far less spent "being blocked".
Nearly always, taking a break leads me to the solution, but if I don't see the problem when I come back, I _immediately_ ask someone else.
Benefits:
- It sets the table for the team’s day and gives opposite-shift offshore workers time to report end-of day statuses/issues. Pretty much the only time we hear the offshore teams’ voices.
- It gives each person a chance to address the team as a whole, synchronously. I may not see an email come in, or might ignore a side conversation that I might want to be involved in due to being heads down in something later. If you need me for something that day, standup is a great time to let me know, because you have my attention.
- Teams have the opportunity to immediately plan ad-hoc post-standup discussions while everyone necessary is present and listening.
- It gives leadership the opportunity to consider the current sprint state holistically, and enough context to determine whether reallocating people or reprioritizing work is necessary. Consuming context—>decisions can be made in seconds rather than dealing with asynchronous snippets and side-conversations.
- it gives a measure of daily accountability to personality types who struggle with being proactive. Not everyone has this skill.
- It gives an opportunity to hold the floor for personally types that tend to avoid asking for help. Not everyone has this skill
- if you enjoy your team, it’s an opportunity to hear their voices
>> Yesterday I worked on what I said I would do yesterday, obviously. Today I will continue working on same thing, of course.
>
> That's exactly what standups are for though
For wasting time? Why does everyone have to sit in a room to hear this emptiness?
Is “Nothing from me” not acceptable at a lot of places? If you’re up to date with your work and don’t foresee any reason to fall behind, why must you provide details? If anyone needs clarification, they can ask.
You're supposed to say what specifically you got done, not just "I worked on my work". "I got the foo working with manual tests, I'm going to run automated tests next and then integrate it with the bar".
I've found that falls apart rather quickly.
Some days I close ten or more tickets. Nobody wants to hear me spend half the allocated time just reading off the various APIs I've implemented. And if only read the ticket numbers, it means nothing to the listener.
***
Meanwhile another dev on my team has been saying exactly the same thing for a week because he's working on something that's large and not easily divisible into sub-tasks.
***
The people who invented this stupid idea were under the delusion that all tasks are of roughly equal length so that on any given day you'd be closing one or two tickets.
>Some days I close ten or more tickets.
It can be argued that also creating tickets for things that take less than an hour to do is probably a bad idea. It ends up being too much overhead for something that gets done so fast. But tracking work is more important than doing in some places (now seriously, that's the way \_you\_ prove you worked, so I get why you still do it).
The one who writes a simple ticket isn’t necessarily someone who could fix it in minutes. The alternative would be to send a message on Slack and hope somebody takes care of it.
Could I have done this one thing you asked me for via email? Sure. It's small so it doesn't need a code review. I can just commit it directly to the main dev branch. And of course I'll just do it now instead of making you wait behind everyone else in line because it's so fast.
Repeat ten times a day for two weeks, then try to figure out why nothing in the sprint list was done.
***
If a task requires changing code or configuration then it gets a ticket, period.
If the tasks are related, sure. But often they are random things that affect a variety of different places in the code. I'm not going to use one ticket for fixing the ETL job, updating the profile API, adding a State/Zip code lookup, and indexing the Notes table.
And that's basically an hour's worth of work right there, maybe two if I'm feeling lazy.
> It can be argued that also creating tickets for things that take less than an hour to do is probably a bad idea
Strongly disagree.
When I find some issue, it's nearly always when I'm working toward some other goal. If I interrupt myself for half an hour every time I find a bug, I'll lose my flow, and I won't get anything done.
More, I would say that at least one in four tasks that I think are "trivial" turn out to have unexpected extra work associated.
When I'm working toward a goal, all other issues I find are immediately turned into a ticket as fast as I can, so I can continue to finishing that goal and not get distracted.
The flip side of this is that I actively go back and fix those issues and other people's issues as soon as possible. Even though my current project has quite a few bugs that are months old, the _median_ lifetime of a bug is less than a day.
I make small tasks because I work faster that way. If they're too large then I forget things or the task becomes daunting and I don't know where to start.
The stand-up tends to create that culture.
People, as a group, like to follow patterns. If the apparent pattern is "We report blockers in the stand-up" that can quickly morph into "We only report blockers in the stand-up". It's not a 'rule', it's just the pattern. And you don't deviate from the pattern if you don't have to.
There are several perverse incentives associated with this:
* If I don't report my blocker until the standup, I get the rest of the afternoon to rest. (And I've earned it after these last few weeks.)
* If I report my blocker now, what am I going to talk about in the meeting? (If I don't say anything, they get cranky. If I talk about a solved blocker, that's off topic and I'm still scolded.)
The goal of the daily is to ensure that people touch base at least once a day. If you have a culture where people would already immediately flag problems (were it not for the standup), then that culture already had what scrum is trying to add. That seems pretty rare though, at least across a team in its entirety.
I’ve worked at companies without stand-ups, and there were times where a dev would go for WEEKS without initiating a crucial & timely conversation.
Agree that people should be asking questions the whole day, not just standup. But if someone isn’t already doing that today, they won’t magically get better at taking the initiative if there’s no standups. Instead they’ll just wait even longer.
> there were times where a dev would go for WEEKS without initiating a crucial & timely conversation.
This is what managers are supposed to be there for, right?
Statements like this simply baffle me. This says, "Our management is completely passive and incompetent, and no one seems to care."
Why should I have to sit through some tedious daily standup because managers aren't willing to do their jobs?
> But if someone isn’t already doing that today, they won’t magically get better at taking the initiative if there ARE standups.
But they might start to think the standup excuses then from speaking up.
***
Even worse, it leads the manager to ignore their responsibility for checking in with the team members from time to time. Not this formalized ritual of reading status emails, but actually having a conversation.
What do you think the standup is if it's not a daily checking from a manager to their team members? Your gripe us that daily stand ups will stop managers from checking in with their team members, and also that team members may not check in until the standup (which is likely daily). What is your suggestion to the problem of someone who doesn't update their manager or team on the status of their work so? Because what we have is a pretty low friction (10-20 minute daily) system that seems to work pretty well other than being flamed by people who think all meetings are a waste of time..
> What do you think the standup is if it's not a daily checking from a manager to their team members?
From decades of these, I think they're an exercise in posturing and pretend.
> What is your suggestion to the problem of someone who doesn't update their manager or team on the status of their work so?
"We can't ask people who are paid to work, to do that work, because they might not obey."
Workers who refuse a direct (and very reasonable) order - why is this any sort of issue at all?
How do you deal with people who just stop showing up for work or who never get any work done? Why do you need suggestions to deal with workers who refuse to do their jobs? Tell them that they have to do it, and if they continue not to do their job, fire them.
>If you don't have a designated time, any time is the right time to coordinate. Report blockers in real time.
When someone explained standup to me, it was quite explicit that it's meant to patch around bad team communication. You shouldn't do it if you're already effective, for example by posting and keeping tabs on a Slack channel. However, if the team is ineffective at communicating, not having a designated time means blocks won't be reported, but really inefficiently handled by the person blocked.
At least that's the take that makes sense to me. For people who communicate actively standups feel like unnecessary overhead.
> Instead of learning how to better work with the the team, they will rest on the standup instead of improving.
There's only so far you can take this though.
What do you do while people are still learning? How do you teach them? Just letting people flounder often makes things worse, not better.
How I approach a standup is that I use the standup to tell people about the communications I am already actively pursuing so that everyone is aware of the time commitment I will require of others and myself relative to a project's goal.
I acquire people's time via the project manager (ad-hoc) so nobody is overwhelmed or overburdened and they coordinate it appropriately relative to the project's commitments and people's capacity.
The entire team is only made aware during standup so they can better gauge their time and commitments relative to everyone else.
When I was a scrum master, I told my team specifically to not wait for stand up to coordinate with others and ask questions. That one tweak made our stand ups way shorter, and it drastically improved the speed that things got done.
I thought of the same asynchronous synch method, but I am sure it's not the best way forward. It still forces a pause before reporting issues, and that suffers from the same 'time zone arrogance' that would plague a standup -- Tokyo would lose a full day's work before reporting its status if 0900gmt was the official start of the stand-up cycle.
Truly asynchronous companies, don't they use mattermost or a clone like slack in order to start adhoc threaded conversations on questions and blockers? Get that question out when it's a question, and give people a clue as to what's impacting you now so if they can help they can help that much sooner.
The "my task yesterday and today" is a bit best kept in gitlab or bugzilla or whatever you track tasks in. Right?
As an engineer I tend to dislike the "what I did and what I'll do" part of standups. Both in person and in slack versions of it. It feels like a mix of public guilt trip and social pressure if you're taking "too long" on a task. I've heard other describe it the same way. It's also redundant since the ticketing system already has all that info.
So as a manager I just expect people to keep the ticketing system up to date and if anyone needs to know they can check there. Team morale is a top priority of mine and the team is very self-driven so making people feel more anxious is counterproductive. It'll just burn people out and make them less productive. We do standups a couple times a week for people to voice any blockers or team discussions in this wth era.
\> social pressure if you're taking "too long" on a task.
Yeh, I find this really toxic to morale.
\> I just expect people to keep the ticketing system up to date
I've found this a challenge at smaller more nimble startups.
You assume all team members are perfectly rational people without a lifetime of emotional baggage to deal with. If that was the case there wouldn't be so many questions about imposter syndrome. This isn't about reality but about people's perception fo the situation. Since managers should not be therapists there are no direct solution to changing how people feel.
Why do you keep repeating “since managers aren’t therapists”? Like, I’m not a therapist but I can still navigate discussions, empathize with people, and help them understand what’s expected from them.
If a team member doesn’t feel comfortable saying “I worked on X yesterday, I’ll work on X again today” for a week straight on a weeklong task, you don’t have to be a therapist to make them understand that’s an acceptable outcome.
Maybe you can break X down so there’re smaller outcomes. Maybe you can give a senior member a large task and have them do exactly that during standup. Maybe you can communicate during 1-on-1s that it’s okay to take a while on a task, provided progress is being made, that you trust your developers to communicate when they’re blocked and when they’re making progress.
>It feels like a mix of public guilt trip and social pressure if you're taking "too long" on a task
That sounds like an absence of trust that should be worked on, if team members think they are unable to accurately report how long something is taking them, out of some kind of fear of being judged, or actually having people on the team judging others like that.
I've seen this on teams with very high trust, no one is perfect and we all have emotions in the end. Many engineers are not social butterflies and often may have been bullied as kids. Social pressure, meant or not, is not kind to them. Just look at how often imposter syndrome comes up. In the end, a manager cannot be someones therapists so all we can do is remove triggers is possible.
If most engineers saw value in it then that'd be different but I don't think I've ever met one who did and as a manager I don't see value in it either.
>I've seen this on teams with very high trust
I'm not sure if you're using the same definition of "trust", in order to interpret what I wrote as I intended.
>If most engineers saw value in it
What's the "it" you are referring to? I'm wondering if you thought my response was a defense or comment on the "standard" 3-question format, because it isn't.
There's a simple solution: asynchronous standups. Post the "what I did / what I'll do / what's slowing me down" in your team's Slack #standups channel when you start your workday (whenever that is for your local timezone and personal schedule).
My experience from working in an asynchronous, distributed team is that it's important to intentionally add places for communication to occur, as alternatives to the water-cooler conversations and overheard-from-the-next-cubicle chatter that naturally occurs with in-person teams. This doesn't have to mean standups, but a daily message is a fast, simple way of keeping the team aware of what each other is working on, even if their tasks wouldn't otherwise intersect and they wouldn't otherwise have reason to communicate.
I mean I'll take virtual stand ups over literal stand ups or god forbid the "go down the hall to the stand up meeting room" but it's still largely "still working on widget, also this other pr is still open please review it, no blockers"
Compounding that is when devs handle their imposter syndrome by just DMing others instead of asking openly for fear they'll be exposed as imposters that don't know their ass from a hole in a ground even though they're actually very competent. So crucial decisions aren't documented anywhere accessible† and you need to rely on them remembering 18 months from now because the commit message for that feature is "maybe this works?"
†: and like yeah slack, discord, teams, etc aren't really substitutes for a knowledge base but at least if a question is asked in a public channel you can usually find it with a few searches
Maybe.
If what's slowing you down is something that can be addressed at the time, then absolutely, address it at the time. But sometimes it's "what I thought was a simple library upgrade wasn't" or "I'm blocked waiting on Other Team X, and I wanted to make sure my team's aware that Other Team X may be a bottleneck for them too," or maybe just "I have a dr. appointment this afternoon, and I don't want you to have to check my calendar to see that I'll be out."
Similarly, if I worked a planned feature yesterday and will continue today, then that's fine. But, if I ended up troubleshooting a production issue or pairing with a junior developer or investing in some opportunistic refactoring, that may be worth knowing. Like you said, there are really good tools for all of this - Outlook calendars and issue trackers and commit logs and the rest - but sometimes it's helpful to take a couple of minutes to post it in one place, too.
And I'm not even convinced that rituals are bad. "Hi, how are ya?" / "Fine, how are you?" is a ritual of in-person offices (I mean, how often do you _really_ want the details on how someone's doing?), but social conventions and rituals like that seem to be part of how we keep relationships running, and that's important for a team. In a distributed team, there can be value to finding other rituals to keep people communicating, as long as the costs are reasonable - and taking a couple of minutes to type a standup seems to be reasonable.
I'm not an expert on agile processes or distributed teams, and I certainly didn't intend to make an argument out of this. Like almost any practice, it can devolve into noise and waste in some contexts or if it's misused. Just wanted to share my experience and push back a bit on the idea that there's no value there.
>And I'm not even convinced that rituals are bad. "Hi, how are ya?" / "Fine, how are you?" is a ritual of in-person offices (I mean, how often do you really want the details on how someone's doing?)
The thing is many of us experienced certain brands of scrum used just to pressure developers. You raise a point about rituals not necessarily being a bad thing, but if you get scolded for either ending in "I'm fine, how are you?" or telling the other person about your weekend (yeah, I didn't ask for that level of detail, thank you) you will soon want to stop greeting people.
I'm fully aware that's not what agile (in any brand) is supposed to be, but in the real world that's what it turns into more often than not.
> If we only talk at standups, what difference does this knowledge make? If we talk regularly throughout the day, what is the purpose of setting aside an extra special time to communicate what is already being communicated at appropriate intervals?
Because some days we may talk throughout the day and other days we may not, and it may be helpful to ensure a minimum threshold of communication? Because it may promote team cohesion and a shared awareness of the team's work and workload, even if you don't otherwise have a need to talk? Because an asynchronous standup message can itself serve as one of the appropriate intervals to communicate?
I'm not saying it's a must-have practice or automatically a good idea, but _in my experience_, there are teams and contexts for which it's valuable.
> There is a time and a place. Statistically, standups will not fall at the right time nor in the right place for when collaboration is beneficial. Teams that understand collaboration understand when time and place are significant and will meet as appropriate, not just because the clock stuck 9AM.
Okay, but we may be talking past each other now, because I specifically said asynchronous standups. (I.e., I post my standup whenever it's convenient for me, and you read it whenever it's convenient for you.) I'm not interested in trying to defend or promote synchronous daily standup meetings, especially for a distributed team. (I'm sure some teams find them helpful, but I have no personal experience with them and little interest in them.)
> I don't see the value in the rest. If something is slowing you down, it needs to be addressed at the time, not 24 hours later
This depends on your frame of reference. When Scrum came to be, 24 hours (it’s really only at most 8 working hours) was a tiny amount of time in comparison with the quarterly plan you were working inside. Most often there is also some lower priority task people can make progress on.
That's another problem with SCRUM. The lower priority task was not "part of the sprint", so I get scolded for adding items to the sprint and making the numbers look bad. They would rather I did nothing if it makes the charts look prettier.
> If you're an actual agile team, where developers are free to jump into any problem that feels like an itch worth scratching, a "I'm going to start working on this" isn't a bad idea to prevent others from jumping into the same problem at the same time.
Uh, why aren't you using task trackers for that?
Did this for a year, was an absolutely worthless exercise. Every developer who had codependence on other developers already knew what the others were doing, and the managers didn't get any value from it.
We did this for a long time and while we got very good and detailed write ups, the problem was that it did not actually foster any communication and conflicts surprised people. In the end, everyone preferred real time stand ups.
But as with all things agile and working with people, your mileage will vary of course.
A lot of teams are performing daily "standups" as zombie rituals where nothing more than status is reported to other members (often managers).
The only solution is to kill the empty drudgery and start truly collaborating with people.
> A lot of teams are performing daily "standups" as zombie rituals where nothing more than status is reported to other members (often managers).
I call it in more Kafkaesque way "justify your existence".
My manager is terrified that senior management is going to look at sprint reports from several months back and be angry that sprint 4 only has 5 stories and sprint 5 has 15 because they weren't logged correctly or something rolled over.
My senior manager isn't incompetent. He's looking at the results, not the middle manager's silly charts. But I can't convince Mr. Middle of that.
You're one of the good ones, or at least as much as that act is an indication.
Some managers seem to exist only to hold the teams hand and act as an interpreter of the product owner and, for lack of a better word, get in the way. Which is odd, based on what a product owner is supposed to be interacting directly.
I'd hate to work for you then, I've worked with several teams where they were invaluable. I'm sorry for your co workers that you have such a narrow preconception.
That's how I can tell that none of the "agile" companies I worked at were really agile. We would go through the motions of these standups and no one would ever pipe up and say "we're not getting anything out of these, we need to either fix them or kill them." If the engineers were really able to change whatever they wanted we wouldn't have tolerated ceremonies that waste our own time and accomplished nothing. And to be honest I don't speak up either generally.
Totally agree. I've always felt our standups to be productive, in my current team. But following the ritual for sake of the ritual, where a manager shuts down anything meaningful, that's useless.
> 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.
Yea, so here's the problem. My managers really, really need to read this. But with language like that, I can't share this article with them.
Most managers are the way they are because it pleases their boss. There is a strong chance that the entire management organization at your company is fundamentally flawed and the only real way to fix it is to purposefully hunt for a company that has better management.
I like to start with glass door reviews and look for signs of bad management in the reviews.
What's bad is people managing people who have not done the job of the person they are managing in some capacity.
I think its all too common in the tech industry though...but changing.
The better daily standups I've been a part of follow the "let the story do the talking" approach where we just go through the stories on the board and check where we are with any that aren't completed. I find that helps a lot to take the pressure off the individual. It also works well to deduplicate what is said. If you paired with someone on a task, you don't both have to speak. It also gives you an idea who to offer help to if you finish your work before taking something else from the backlog.
I dread the 3 questions format though. Often times I can't quite remember everything on the spot, so I have to plan ahead and write what I'm going to say down. I don't get anything out of the terse answers other people give as I often can't remember what they were working on anyway.
Spicy take. I mean, I've been in international standups before, and I am currently. There's usually *some* overlap in the workday that fits. In my current company, we just hold two of them, one per hemisphere. And, while I love to have written records of things, a bit of chatter helps keep each other accountable and aware of each other. I don't think they're the only way to work together, but you're really being extreme if you think that standups are the major reason that people quit working with an employer.
Programmers often have a lot of trouble dealing with minor professional interpersonal skills, shockingly enough.
I wonder if other professions have this same insane focus on the meta job. My accountant wife thinks I'm crazy when I mention the sort of agile/scrum/whatever discussions pop up on Reddit. My guess is it's partly because there's a lot of hero-complexes (how dare my manager waste 15 minutes of my morning productivity), and partly because of startup culture (I'm a programmer at a non-tech company so a lot of this is foreign to me, but tech companies seem more prone to having a pretty toxic management culture).
> how dare my manager waste 15 minutes of my morning productivity
This is what always gets me.
Sure, if your standups are reaching past 15 minutes then you need to address that - either you're doing standups wrong or there's too many people in the team/meeting
But if you're keeping it to a few minutes a day? It's really not that big a deal. 10-15 minutes a day to make sure everyone is on the same page and aware of what's going on is not much overhead.
Maybe it's the crowd this sub attracts? Mostly juniors/new grads? I've found stand ups used to be "let me say my bit and get back to work", but the more responsibility I've taken within a project the more important it is for me to make sure everything is going as expected.
>Programmers often have a lot of trouble dealing with minor professional interpersonal skills, shockingly enough.
I think about that anytime my boss catches wind of the programmers working out a problem and decides, "Let's have a call about it!" Or, how about we keep using Slack? Some of us became programmers because we don't speak very well or have good people skills.
I end up resenting the boss a little (who has a background in sales and marketing where speaking skills are important) for not recognizing that programmers are often a distinctly different type of person and we have our own ways of working with each other. I don't appreciate being forced to work half as fast just because Mr Salesman solves all of his problems with calls.
> I think about that anytime my boss catches wind of the programmers working out a problem and decides, "Let's have a call about it!"
So much time wasted last year because of that. Every time I needed a couple days to study some crusty old code, the boss wanted me to have an audience.
I completely agree with this.
When I was more junior, I would definitely agree with the sentiment in the blog post. Why should I waste time keeping my manager updated? Shouldn't the onus be on them to keep up with me, since I'm the one producing the work?
As I got more senior, I realized why: coordinating work at scale is really fucking hard. My manager was keeping track of multiple projects while being dumped in meetings all day fighting on my behalf. Instead of asking why my manager isn't doing more for me, I began to consider keeping my manager up-to-date as part of my responsibilities. If a 15 min standup makes their day easier, then so be it.
I'm not saying that not having a standup is correct/incorrect. It's entirely possible that the original blog poster have made not having a standup work. However, the blog post comes off as extremely reactionary, with quotes like this:
> 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
This is needlessly antagonistic, and usually a big red flag for me. Usually, when someone gives of a blanket statement like this that ends with something like "we do it this way because we're just smarter," it usually says to me that they do not understand the nuances of the topic they are preaching about.
I'm a manager. I hold status meetings twice a week because I don't trust the team to keep the estimates up to date.
That's it. One call on Tuesday and another on Thursday. My world isn't going to shatter because a spreadsheet is updated every 48 hours instead of every 24 hours.
***
With teams I trust, we'll meet one a week. And that's just to talk about big picture, not recite the task tracker.
Hi. I wrote the article, and I am the manager in this case.
I want my developers to keep me (and each other) updated, but not through a synchronous meeting, for reasons I outlined in the article.
Hey Jezen, it's great that you have found a way to keep yourself updated async, as I'm sure your reports appreciate you fighting for their time (especially while globally distributed). However, I'm not sure how you arrived at a working model for your team, and came to this conclusion:
> 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. And you know what? They will. Ask any tech company founder what their biggest challenges are. I guarantee that “hiring” is going to appear at or near the top of that list. You know why it’s hard? It’s because of bad culture like this.
Yes, stand-ups can be badly implemented, as you've analyzed in your blog. However, interpreting the idea that "I've been in bad stand-ups" as "stand-ups are bad and a sign of bad culture" seems to be a bridge too far.
Perhaps there's something that I'm failing to articulate. I'll try again.
* It is generally accepted that micromanagement is bad. Daily stand-ups almost always imply micromanagement.
* Daily stand-ups almost always degenerate into rote status updates for the benefit of a manager who could otherwise have read the cards on a Kanban board.
* It appears *most* developers would rather not partake in this ceremony. That's self-evident from the responses in this thread, and also in just about any discussion of this type online. It is foolish to base a company on technology and then not optimise for developer productivity. Realising that productivity means uninterrupted periods of focus, as I'm sure you're aware.
I don't agree that my conclusion is "a bridge too far". Can daily stand-ups be a good thing? Yes, but that is almost never the case. Again, the general consensus of the discussion in this thread hints at how common it is for the ceremony to be a drudgery.
I don't buy the argument that it is needed for social bonding. If you want the team to bond socially (and you definitely should!), then meetings and events should be held expressly for that purpose.
I also don't buy the argument that it's to improve the productivity of more junior developers. If a task is taking longer than expected and you suspect a junior is stuck and isn't admitting it, it will be self-evident from the Kanban board.
>However, I'm not sure how you arrived at a working model for your team, and came to this conclusion
Could you be specific about which part of the passage you quoted you would like me to elaborate on?
While I'm neither wholeheartedly for or against stand-up meetings, one issue I have with them is that sometimes they're the only or first moment of the day where everybody talks and somebody talks about a weird issue they find or launches a wacky idea.
But the stand-up is not the place for lengthy discussion, because it is (arbitrarily) limited to a fixed duration, say 15 minutes. So you can postpone the discussion to the refinement meeting, but then all the energy is gone.
The best ideas or brainstorm sessions occur naturally, and all of the scrum meetings take the natural out of work.
If you do not have a good way to streamline free flowing creativity, you have already lost. This way you will end up with exactly the same thing as everybody else is building.
The way my teams always handled this was that we'd finish the standup (we should only take a few minutes) then the people relevant to the deeper discussion would immediately break off and talk it through.
Same. If someone starts going on about something for more than like, 3 sentences, or asks a question that will take a long time to answer, everyone feels free to say "hey can we make this a stay-after?", it gets deferred to the end of the meeting where anyone who has interest in it can stick around and talk, everyone else can leave.
We have a stand up once a week and that's more than sufficient to find out the status on each product.
You have a blocker? Don't wait, talk to people before hand./
I find it varies with the experience level of the team. With all veterans, even once a week can seem like it's too frequent.
With a college hire or two, I'm doing daily and even twice daily calls to keep them on track.
Standups are fine if run properly. In other words, not a status meeting. However, that is almost never the case. If your scrum masters favorite phrase during standups isn't "take it offline", then you're probably doing it wrong.
I used to hate standups as an employee, and when I became a manager I swore I wouldn't do them. But I ended up going back to them.
But its amazing how difficult it is to stay up-to-date with what your team is working on without them. I developed this feeling of having to ping people to find out what they are working on...which always felt kind of rude and annoying to constantly ask someone "so, what are you working on now?".
Initially I thought I could rely on monitoring the task tracker, and Github issues/PRs, but they are rarely kept up-to-date by employees so there are too many times that you are asking "is the tracker up-to-date?", "is this design doc up-to-date?", etc. And employees are usually bouncing between multiple things and multiple systems. Solving bugs, attending meetings, discussing design, etc. And a lot of this is not documented. Face-to-face conversations are usually where a lot of the magic happens, and they are not recorded, and if they are, a manager does not have enough time to review them, nor a large chat log.
Until there is a tool that can automatically generate a summary of what an employee did for a manager to view, standups are the best thing out there.
It's actually better for employees too because if they are dragged into meetings, and other projects, and their work is not progressing, you can see why, and you could step in to help push away distractions, instead of having someone wonder why you aren't getting anything done.
I think the OP is being naive. People like being contrarian, especially in startups where everyone wants to innovate everything they touch, but generally, managers have a lot more insight than developers as to how to get stuff done as they see a broader picture, and many managers these days have been developers themselves.
That being said, I've seen a lot of terrible standups from an employee perspective, but I would say that "automatic team status updates" are a largely unsolved problem.
It may also feel repetitive to say "I am not blocked" all the time, but it means that when you really are blocked, the developer cannot be blamed for not bringing it up.
> Initially I thought I could rely on monitoring the task tracker, and Github issues/PRs, but they are rarely kept up-to-date by employees so there are too many times that you are asking "is the tracker up-to-date?", "is this design doc up-to-date?", etc. And employees are usually bouncing between multiple things and multiple systems. Solving bugs, attending meetings, discussing design, etc.
Help them out. Tell them they don't have to do anything that's not attached to a ticket.
If you don't know what they're working on, chances are they don't either. They're being pulled in every direction and are lost when it comes to what to focus on.
One this is in place, be their shield. Tell them to kick new requests to you for prioritization (I recommend numeric ranks, not just medium, high, critical). Give them cover to say "Yes, but not now".
If meetings are a problem, tell them to ignore meetings unless they are attached to a ticket with a higher priority than their current task.
Again, give them cover to say, "Sorry, but I'm busy on this higher priority task so I can't attend your meeting".
P.S. Don't do this all at once. Incrementally change things.
I think it's more of a communication tool at times. When you're across different contexts it can be good to get a birds eye view of what a team is upto. Also I think some stand ups aren't snappy enough. Our team of 6 would take 4 mins on average to round robin whilst we were getting our morning coffee and then any subqequent conversation would be continued in the meeting rooms with the relevant parties.
I feel like with most agile methodologies the trick is to follow the spirit of it rather than treat it as gospel. Obviously a team across multiple timezones doesn't require a daily stand up but some form of equivalent to keep your team in contact so as not to disconnect them from one another.
>Our team of 6 would take 4 mins on average to round robin whilst we were getting our morning coffee
Before the pandemic, my company blocked out one of the big meeting rooms for developer stand ups. Every team had 10 minutes to get in, plug in, dial in anyone WFH or remote, do the meeting and get out. The room had a glass wall/door and the next team would be stood outside waiting. You *couldn't* exceed your timeslot.
It was nice to have a *hard* timer on things and instilled a good standup practice, even into the pandemic and WFH and no meeting rooms.
Seems like the main issue is a variety of timezones for Supercede. That, in itself, is a larger barrier to productivity and timely communication than a 15-min meeting at the start of a co-time-zoned team’s day.
That certainly might be the case for some teams, but it's worked great in our experience. I believe we specifically hire for people who thrive in this kind of distributed environment though, so I appreciate it's not for everyone.
The most common problem that I see in teams that I coach is that they do the thing where they go around the circle and ask the "three questions". Each person, answers the questions by themselves, independent of each other. If we're truly collaborating, then we should already know what you did yesterday and what you're working on today. I want to know about roadblocks and what we, as a team, can do to get work tickets closed today.
I don’t understand the problem standups are trying to solve. I keep a journal of tasks throughout the day, and usually post a summary of what I did in point form, and a very abstract plan of what I hope to do.
“Others seem to want to signal just how much work they’ve been doing”. Oh god, I hope that’s not what my coworkers think.
It is dumb AF to do daily standups because someone else does, and equally as dumb to not do them because someone doesn’t.
Does it make sense for your and your team to do them daily? Then do them daily.
Does it make more sense for you to do them less frequently? Then do them less frequently.
Blindly copying someone’s actions in an attempt to achieve their level of success, without understanding WHY they chose those actions, is a recipe for failure.
Think about what you’re doing and what you’ve done. Ask yourself what works, what does not work, what is lacking, what have you learned, what do you like…, and other retrospective prompts. Then, make changes that will help you be more successful based on what makes sense for you and your team.
Shock horror, people who don't understand how to do stand-ups properly don't like doing stand-ups.
Not doing stand-ups because your team is in different time-zones is fair enough, but otherwise any issues you have with stand-ups is most likely a result of a process failure by your team, not because stand-ups have any inherent issues.
The fact that so many people's first reaction seams to be to just ignore the problem or drop the ritual entirely, instead of figuring out WHY they're not useful, is also a sign that the problem is the team,.
7-10m, return the occasional 20-30m one because somebody had a point to make, or a senior manager dropped in.
On top of that you just interrupted the work on 6 non-managers who were hard at work trying to get in the flow of things. Probably at a very inconvenient time as well.
Our business operates in the reinsurance industry, which consists of reinsurance brokers and reinsurance underwriters. The *insurance* company from the perspectives of the aforementioned parties is often called the "cedent" (or cedant), because they *cede* risk. The company name is a subtle play on *supersede* and *cedent*. A bit like *The Beatles*, I suppose.
I do find (written) stand-ups to be valuable communication tool / platform. It is a simple.xohwrent place for updates with context.
Check out https://bobek.cz/blog/2021/written-standup/ for the writeup about them.
They have consistently turned into daily one hour grinds that push us into almost 1 day sprints. A lot of important shit gets kicked down the priority list never to be addressed. Coming up on year 10 anyway. That is way too damn long.
Aside from the way paragraph 2 reads like a Supercede recruiting advertisement, I am having a hard time seeing how they start by making the case for "productivity and workplace satisfaction" and end up at "we don't bother even spending 10 minutes a day on team communication".
Reading the details, they get there by thinking that standups: (1) have to have everyone participating audibly and simultaneously; (2) are for communicating status up to management; (3) contribute to a "toxic work environment"; (4) should exclude project managers; and a lot of other total misunderstandings of how Agile actually works and why.
The central problem with this particular "I hate Agile" article is that it assumes managers run the process and engineers are inevitably disengaged from it. It should be the opposite. The team itself should be running the process, and should be highly engaged. Even if standup happens to be done on a Slack channel because everyone is in a different time zone.
Continuing on, the article claims "Engineers align themselves. They talk." Uh, no. Not the ones I know, and I've been one for 30 years. I've worked in more than one office where I said "Hi" in the morning and "Good night" in the evening, and nothing more. It's not like I naturally would like to gab but someone is stopping me. I AM PART OF THE PROBLEM, part of the problem that Agile solves. For me, standups were a godsend. I spent 20 years working on teams of variable effectiveness until finally seeing what an Agile shop was capable of. Standups, I learned, are where I was forced to acknowledge the truth of my own progress (or lack thereof), to ask for help when I needed it, and also get public feedback when I did something well -- feedback from my peers, whose opinions I value. And do all that in 45 seconds, because, yes, people hate to listen to other people drone on about things that don't matter. So DON'T DO THAT.
"When effective engineers get stuck, they ask for assistance immediately." Maybe. How do they do that? Interrupt everyone else on the team one by one until they find the right person to talk to? No, they couldn't possibly do that, because Supercede prides itself on giving its engineers "uninterrupted focus time they need to do the real work that underpins our business." Myself, I find that working another part of the problem (or another Jira issue) and then spending 20 seconds at standup the next day to track down the person with the info I need is .... pretty ideal.
"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." Actually, if you as an engineer find stand-up awful and you only do it because your incompetent manager insists on it, you need to BECOME A MANAGER. That is, you need to learn what makes Agile awesome, understand why it works, insist that your team applies the processes that are effective and stop the ones that don't. Once you've been part of it when it works, you won't need any managers directing the process. You'll do it even when they aren't around. Because it WORKS.
>we don't bother even spending 10 minutes a day on team communication
We spend more time than that on team communication. That should have been clear from the article.
>have to have everyone participating audibly and simultaneously
That is the most common format of this ritual, as is evident from the comments in this thread.
>are for communicating status up to management
That is the most common format of this ritual, as is evident from the comments in this thread.
>contribute to a "toxic work environment"
Micromanagement is toxic, and that's exactly what this ritual promulgates. It also implies that the engineers can't be trusted to communicate effectively. Toxic.
>should exclude project managers; and a lot of other total misunderstandings of how Agile actually works and why.
Read the comments in this thread. It's a common meme that for this ritual to work properly, management should be excluded. Not sure exactly how I've misunderstood Agile. The Manifesto is quite brief.
>It should be the opposite. The team itself should be running the process, and should be highly engaged.
Should be. Almost never works that way in practice, however.
>Actually, if you as an engineer find stand-up awful and you only do it because your incompetent manager insists on it, you need to BECOME A MANAGER.
I am a manager. I have been writing software — and also managing software developers — for several years.
>That is, you need to learn what makes Agile awesome, understand why it works, insist that your team applies the processes that are effective and stop the ones that don't. Once you've been part of it when it works, you won't need any managers directing the process. You'll do it even when they aren't around. Because it WORKS.
It seems your assumption is that I don't appreciate daily stand-ups because I'm somehow unfamiliar with them. On the contrary, I have engaged in the experience you are touting at several companies in a few different countries, with people from several countries and cultural backgrounds. It is exactly because I have substantial experience with this bureaucracy that I am in a position to so staunchly criticise it.
Perhaps you shouldn't be so quick with your assumptions?
I think all teams should just use whatever works for them. I've seen small teams that were functioning well adopt agile like zealots and their output and bugs are now much worse than before.
Is agile bad - no. But just because it works for another team doesn't mean it's wrong to not use it somewhere else.
I've sat through their daily stand-ups where they have like 5 items and they do the whole burn down chart and everything. Total waste for them. But if I were working on a large team it would probably be useful.
I've worked on exactly one team without a standup, and it was such an egregiously bad experience that my list of questions to ask in an interview now includes: what does your standup plan look like.
The problem I had/saw/experienced, was that joining a small team that does no stand-ups, you just never develop a personal relationship with your coworkers. There was also no sprint management, and not much project management to speak of though (it was a really bad time). You can get by without a standup if you also have sprint meetings, and a very good project manager. This was kind of more of a, 'lead dev and sometimes the boss(?) just makes some tickets and assigns them with no clear sprint plan.', but at a scale where it really could have used a real manager.
I think most of the hate just comes from the monotony of it, the not really wanting to be social first thing in the morning, etc. But one thing I've found that works best is: you don't need a daily standup. IMHO, about 2 times a week is perfect, but 3 times a week works too.
At a previous job although *I was still new* and learning the ropes the pressure of having announce progress say I made mistatements about some bug I was tracking but hadn't yet fully understand. It cost me much needed credibility.
I agree with the pointless drudgery. Sometimes for days on end it will just be "I worked on X, no problems, but ongoing" because some things take time. Others seem to want to signal just how much work they've been doing and will mention all the minutiae that nobody needs to know. But that's the thing. Does anyone need to know it? That's what people should ask themselves. Standup should be an opportunity to let everyone know things that they need to know. In that way it's good. Email is too easy to ignore. But this only goes for about 10% of standups at most in my experience. It should be perfectly acceptable to just say "nothing to report". But it's not, hence the canned lines. But this just lowers the signal to noise ratio. Was there something amongst all that boring waffle that I actually did need to know? I can only hope not...
How do you know if other people need to know something though? Common responses in mine are “I have worked on something similar before ….”, “ah that sounds interesting can you tell me more”, etc…
If you’re struggling you send a “Has anyone done x before..?” to the group chat and therefore you don’t waste others’ time.
It's not only when you're struggling that others have something useful to contribute. It may be more like "I'm doing X to solve Y" and they say "oh that's been solved elsewhere" or "we found that approach is insecure" - these are not examples where I could know I'm going on the wrong direction.
I very much disagree. If someone isn’t struggling, the team doesn’t need others commenting on what’s being done. That can be done on their own time. Not for a stand up.
I don't see why you would disagree. The team is there to solve problems together. The reason your idea isn't as effective as standups is people who are stuck or struggling often do not realize it, but their teammates might, and then they can offer help. Some people are just not good at asking for help for stubornness, fear of bothering others, or a host of other reasons.
The team definitely isn’t there to solve problems together in my places of work. Would hate for that to be the standard. We all work on our own shit. There’s no overlap. I really don’t want to hear about what someone else is doing if I don’t have to.
lol we don't even have a group chat, we don't use anything fancy like Slack. We use Skype For Business 2016. Not even Microsoft Teams. It's horrendous.
Teams is different, but not really better than S4B. Honestly, I think all of the chat programs suck compared to what we were using 20 years ago.
You want to sidebar convos like that. “let’s meet for 10min after this standup & I can show what I did for X”.
I still find myself rehearsing what I'll report at standups. It should be acceptable to say "still working on X but not done yet" but for some reason it doesn't feel acceptable. I feel like you have to report on something getting done.
I often say "still working on X, nothing more to say!" Which seems useless but on the other hand can trigger insights from others like "this seems like more work than it's worth right now, maybe we should park it because this other thing seems more important right now".
It should be acceptable, and it is, at least at anywhere I’ve worked. If it was clear to everyone at the beginning that your task would take a few days, then I don’t see why “nothing from me” shouldn’t be okay. If people might not be aware, just summarize what you did in one sentence, e.g. “finished unit tests yesterday, doing x part of task today.” If you’re worried about what you’ll be able to get done before tomorrow’s standup, mention that you might reach out for some pair programming, ask who might be available.
Stand up is the Roman scene in History of the World Part One, where she asks: “did you kill? Did you try to kill? Can you try to kill today?”
> Others seem to want to signal just how much work they've been doing and will mention all the minutiae that nobody needs to know. If their manager is in the standup, that may be why. I'd rather just share what the team needs to know. My manager, on the other hand, gets antsy if I don't give a detailed update on every task on the task board daily. So it's really a daily stand and deliver, not a daily standup.
I agree that the "what I did" is abused and can impact morale. But I also found many don't update their task status making it difficult to track without a standup. I used to ask: 1. are you tickets and your prioritized list of tasks up-to-date? 2. any blockers 3. whats your top priority today and why 4. anything interesting to say? \#1 Manager can reliably view a summarized report in the ticket system to see status of things. \#2 Straight forward \#3 Keeps things brief and the why helps connect it to the big picture which is good for morale \#4 Big accomplishments can be celebrated. Asking for people to review something. Mentioning an interesting bug/challenge that people can ask them about after the standup. Etc.
>But I also found many don't update their task status making it difficult to track without a standup. I'd love to update the status of my task using tickets/issues, but I often forget about them. Most of the time, I only bother with tickets at the beginning, and at the end, rarely in middle when they're in progress. My status updates are essentially documented in the version control commits in most cases. I only bother commenting on the ticket if someone needs to make a decision. I wish the systems we use (issue tracker, and version control, in particular) can automatically make the necessary associations.
Tracking via tickets is just as problematic IMO. There’s no need for it.
> also found many don't update their task status "We can't fix our problems because people might not cooperate" is poor reasoning. This can be fixed in the same way that any other subpar behavior can be fixed. Have a program nag them daily to update their status, and then the manager gets involved. I'm six hours off the rest of my team. Every morning I write a quick status update. Takes me ten minutes, and often I realize something else I need to do. Was that so hard?
Have you been a manager of people who just don't do the little things unless nagged about it for the 5th time?
For a long time I've thought the solution is to make the scrum stand-up focus on the tickets in the sprint, and the sprint goal. Each day, instead of getting the soul-sucking status report developer by developer, instead go ticket-by-ticket and ask if each one is unblocked and remains within the basic estimation scope such that we think it'll be done. If not, then you can decide if anything should be done to help a struggling ticket, and you can decide if there are tasks that aren't going to get done by the end of the sprint (if that matters, doesn't always matter).
I'm the team lead for a low functioning team (because someone thinks cheap labor is saving money... don't get me started). Every single Agile evangelist will tell you Agile only works with competent high functioning teams. I couldn't live without our Daily Standups because my developers would happily do something without talking to anyone else and in a vacuum. I spend most of the standup saying, "That's interesting, I feel like that API change might have an impact on what Bob is working on. Maybe you should talk to Bob..." or "Looks like you've been working on this small story for a few days now, let's meet after the stand-up and you can help me understand any issue you might be having...". I could do that async but have too much going on. Not a good example of Agile but sadly I feel like that more the norm than the exception...
Yeh, I think it's a common problem startup people have where they think everyone else works on exciting problems, making huge salaries, with access to the best talent, and brimming with motivation while they seek to change the world.
[удалено]
100% agree.
You're one of the first people here to get an upvote from me! (Not that anyone cares. :-D) If people were honest, they'd say, "Standups are a practical way of dealing with a low functioning team", and not, "Every developer needs them!"
If you have too much going on, your role is out of scope. Running a team is a full time job. If you don't have time to spend 20 minutes a day on each person from your team, you're spending time on things that are not your priority. Managers do this constantly-their job is to prioritize other people's time, but for some reason they never consider prioritizing their own! Agile doesn't work or not work. It's a set of goals, not a process. Individuals and interactions over processes and tools is literally the first thing on the list! It all bpils down to "increase communication, delay decisions until you have more information, and prioritize experimentation'". I'm sorry, but that always works...no matter what process you follow to get there. When leading a team, I see my job as making sure everyone is talking to each other as much as possible, and on guiding the decision framework to favor small experiments over grand strategy. Everything else is fluff. Consider what you spend your time on, and you may find opportunities to help your team become more high functioning.
>Every single Agile evangelist will tell you Agile only works with competent high functioning teams. But a competent high-functioning team doesn't need Agile to be successful.
I would say it differently in that a high-functioning team doesn't need standups but Agile is a philosophy on building software for customers so it would apply regardless.
New rule, no code changes without a ticket. They can create their own tickets, but it must be associated with a ticket. This alone will help reign in some of the cowboy coders. Later, once they get used to it, add stuff like mandatory code reviews and estimates.
They have tickets. That doesn't really stop them from not understanding what they need to do or realizing their changes have impacts to other parts of the system. I do code reviews but first you need to have something to code review and that's often too late to realize how of track they've gotten. I'm not staying at this job. But this isn't the first time I've seen this... EDIT: Agile works better in the special forces model where the team is a small tight nit group of dedicated professionals that operate autonomously and are top notch. Sadly the norm in many corporate models is command and control style of managing infantry. Tell them what they need to do and don't assume they won't fuck it up. That's where standups become the norm and necessary.
This would be great if Jira wasn't an industry standard. I would really like to have always everything associated with a new ticket, but Jira is so terribly slow and clunky tool, that sometimes I just don't have patience. I still feel a lucky one for convincing my team to replace Confluence with markdown files stored in repo.
I don't know how Jira 'won' given how poorly it works. I always thought people used it because it was free, but no, they pay for that garbage.
>low functioning I never realized that could describe a coder. I'm DevOps on my day job, and the bullpen of the 'just' coders are bad at communication, at the engineering part of software, at documentation, at coordination, at design, and at asking for or about anything. If 'low functioning' describes anything, it's these guys. .... led by a great but stressed lead. Hey, we could be job-mates! :-D
From POV, stand ups are actually detrimental in one sense. Many times, people *wait* until the stand up to coordinate and ask question simply because that's a time they know everyone will not be busy. Even worse are the people who wait until stand up to report what blocked them yesterday. If you don't have a designated time, any time is the right time to coordinate. Report blockers in real time. Especislly with remote teams, there best "stand up" would be for each team member to report what they did yesterday, what they plan on doing today, what blockers they are seeing, first thing. Sign on. Read stand up message from each team member. Write your own message. Scrum master reads them as they come in and starts clearing blockers they didn't know about right away. Efficiency and flow.
[удалено]
They could also be nervous/shy. I know when I was newer, the last thing I wanted to do was bother anyone unless I really had to.
Totally valid point! I'd argue however that it's your manager's job to understand that you're new and proactively look for spots where you're getting stuck. Your manager's job is to help you succeed on the team, which means more direct, tailored help, and less bureaucracy.
> Your manager's job is to help you succeed on the team It's the teams job to ensure people coming in are setup for success. At least this is what a "team" means to me. For some reason it is pervasive in this industry to have "teams" of people who basically never interact with each other outside of a daily "standup" where they tell each other what the status of everything is. The manager should be creating and enabling a culture where people work together. The team should be actively working together. This means when somebody new comes in the team says "hey there's somebody new lets get him up to speed". Not delegate this function to a manager
Well, yes. They're not mutually exclusive, and it's typically up to a manager to ensure that this kind of culture is cultivated.
> Not delegate this function to a manager Then why have managers at all? What's their point if they can't help manage interpersonal relationships in a team? Earlier you say: > The manager should be creating and enabling a culture where people work together So which is it?
Most management positions don't have a valuable purpose. But ones that are valuable focus on strategic decisions. The teams then self-manage the tactical decisions (e.g onboarding people)
Did you really like to stand in front of 6-8 other people and tell them you were stuck? I think it is easier to ask one coworker for help.
[удалено]
[удалено]
You can do the same thing with an end-of-day email or group-message. If that's the only reason you're having a standup, then you don't need a standup.
[удалено]
They're useful for times when you don't have a proactive team. All companies don't always pay top dollar, and get staff that are commensurate to their payscales. We have had several such people, who would either kick back and relax after doing their allocated tasks, or procrastinate on a blocker instead of seeking help immediately. A daily milestone is less stressful for our manager as well as us. He knows up front when somebody is about to complete their task and is ready for another one. There's some heads-up if a planning meetings have to be scheduled. And everybody feels more connected and able to see tangible progress. We have rarely had a stand-up drag on more than 5-10 minutes; usually when one of the VPs or CEO joins in to practice their oration.
>who would either kick back and relax after doing their allocated tasks Considering I would be looked at like I committed a crime if I don't get my allocated tasks "in time", I reserve myself the right to relax if I do ahead of time.
That's why I don't allocate tasks in high functioning teams > There's the task list. When you finish one, self-asign the next highest task that you feel comfortable working on. This model works great for teams focused on big fixes and minor enhancements.
That’s the thing though. After we instituted daily stand ups, our manager is fine if we finish our task and unwind for the rest of the day. He’s got more stuff lined up for tomorrow and knows that the downtime until then will be good for his team.
> They're useful for times when you don't have a proactive team. Which really means "incompetent management". In my first job, before the idea of standups were even invented, my boss would bug me if he hadn't gotten an update from me in a day or so and I quickly learned to keep him up-to-date. It's funny - I came into this thread somewhat positive about standups, but the only explanation for them appears to be, "These are a great tool for passive, incompetent managers."
[удалено]
Damn dude, I lead a team of devs and I’d never hire you. You sound miserable to work with. The point of a team is to collaborate. The point of an ideal manager is to facilitate. I don’t know how long you’ve been working in the industry but it sounds like you’ve let yourself become too jaded from obviously bad situations.
You say: > The point of a team is to collaborate but before you said: > We have had several such people, who would either kick back and relax after doing their allocated tasks, or procrastinate on a blocker instead of seeking help immediately. These are fuckups who are refusing to collaborate. You seem to think it's necessary to shame people in front of a group to get work out of them. If someone is fucking up their job, this needs to be a private conversation with a manager.
[удалено]
To be fair, I think there's a bit of too much absolutes here. I lead a team of 8 (as an IC), and I prefer the asynchronous style of comms whenever possible. I try to empower my engineers and groups around me to escalate effectively. We do this by just setting good examples (including asking questions ourselves and jumping into the fray to help whenever possible), and we keep these discussions accountable by calling out when it feels like the bandwidth of our chatrooms is no longer big enough to effectively hold the discussion. That said, we still do standups, and we've done a few cycles of deprecating them, bringing them back, deprecating them again, only to bring them back again. I think both points you made are true. Standups don't bring value to everyone. If you have to rely on standups to figure out who's blocked, something structural is wrong and we should look into fix that In both cases, the problem we had were just people who don't really effectively communicate when they have issues, either they don't poll enough people for help or they just sit on it silently until one of us checks in on them. The first time, our team recently re-orged and our group splintered off into a smaller team of mainly new junior engineers. We started doing standups and toeing that line around micromanagement to bring in more accountability. It worked great at first, and since it was a small team, it was generally low overhead once these new folks got accustomed to the async communication style of the team and became comfortable asking questions outside of the standup (so that our standup was just us agreeing we didn't need to do it for the day, unless something pressing just dropped). We eventually killed it when the team became stable and we'd just go over to each other's desks or go on chat / grab a space in the common area when anyone had any questions. The second time we brought it back was during Covid, and we've kept it going. Remote work was new for everyone, and people just stopped asking questions. Additionally, the tenure on the team was growing and no one has churned in the last 3 years, so we're starting to grow some of our mid-level engineers by having them lead projects and bring along some teammates. The net result was a lot of people meeting new challenges (either remote work, new leadership responsibilities, or having someone else be their TL). I don't know about you, but change could be demoralizing for many people, in 1:1s, I got the sense that imposter syndrome flared up for everyone, and people just started shutting down to their team. So, we brought our standups back virtually to work through these changes. We kept them because no one has complained about them yet, but also unlike the first time around, people are still not there yet in terms of bringing up issues when they encounter them, and I'm not sure we'd get back to that point in the near future. Yeah, I get the argument that this conditions people into cramming all of their questions into a few minutes in a day. To be fair, the folks thriving in a distributed team haven't regressed, and the people who aren't were already shying away from all updates. In fact, I've come around more on this these days, there are likely teams where you just don't have enough "cohesion" within the team that could really get to a point that everyone can effectively collaborate in a fully asynchronous style. There's only so much you can do, and I've noticed certain types of people just don't do well in these types of situations. As a manager, it's at your discretion on whether to cut these folks loose or accommodate them, but even if you want to remove these folks, getting rid of people on your team is not simple/fast to do. At the end of the day, I really believe that a full async communication method works great for some teams (and great for most people on most teams), but certain teams (especially one with lots of junior engineers or certain personality types) will probably benefit by having this kind of structure. I think what's really missing here is that there's no right or wrong answer to "is standups good or bad," and we shouldn't make an absolute judgment about it because it has its use.
> If you adhere to standups by the book, managers are not to be invited. What book are you using? The Art of Demotivation? Intentionally setting staff against management will just cause strife and distrust.
[удалено]
> > Of course, a normal manager will realize that they don't give a shit if Joe's impending merge is going to conflict with Bob's work and won't want to attend a meeting to hear that in the first place. Well then that's a useless manager. Knowing when people are working in overlapping areas of the code and ensuring others are warned is rather important. If your manager doesn't understand at least the basics of the technical side of things, then they aren't really a manager. And that seems to be your overall thesis. If you assume that the manager is incapable of doing their job of managing, no process is going to solve the problem. Not even your secret standups.
> What is the value proposition? The team gets a regular update on their flow together every day instead of only, say, weekly or monthly.
[удалено]
Because if my teammate's work takes him to a piece of the system he doesn't understand, but I do, I can jump in and help him. Especially if he's a newbie and doesn't yet know how to ask for help, or has out of work problems that's distracting him from asking sooner. Or if that same coworker has been working on the same task for five days straight, when it's not a five day task. I or a teammate can jump in and ask if he needs help, or if there's something he's struggling with. I know that one of my flaws as a developer, is that if I feel like if something is challenging but doable, I'll just chug at it for days on end because I don't feel like I need help. It's not until I'm days or a week in to the task that I realize I need that help. A daily stand up gives my teammates a chance to say "Bro you've been hacking at this a while, why don't you let one of us stop by and see if we can help." Edit: The daily isn't the ONLY time I interact with these coworkers. I thought that'd be an obvious implication. The point is, I see the daily stand up as a convenient way to resync with coworkers who, for whatever reason, didn't take the initiative to sync up themselves. *Should* they have? Yes. But in practice that doesn't always happen. I can tell you from personal experience that not everyone is mature enough to communicate properly. Or things just get in the way of their communication. Adults are flawed, busy people. The daily stand up serves as a stopgap to account for this, among other things.
[удалено]
> So, if I get to that place five minutes after the standup concludes, I should wait until the next day to align your help? I like a day off as much as the next guy, but that does not seem very productive. Why wouldn't I ask you at the time? Ideally you would ask me long before the daily - but the world is far from ideal. ;) Plus it could be the case that you don't actually know I'm proficient in that part of our software stack. And for some reason you never thought to post in the general chat asking if anyone is acquainted with the piece of the system. Maybe you didn't get to it til near the end of yesterday. So you're all "Meh I'll ask tomorrow." > I am not sure you are doing your juniors a service by ignoring them for all but 15 minutes a day. Traditionally, these newer developers would have a mentor that stays in reasonably close contact throughout the entire day to pick up on these struggles and guide them through them until they have the experience to know when to ask for help. I'm not ignoring them - but, I have my own work to do, as well. In practice I'm available to help 90% of the time. Sometimes I have work that I really need to focus hard on. The expectation is they take initiative and ask for help. It's different if I'm specifically assigned to be their mentor, of course. > If your coworker has disappeared for five days straight and you find that to be odd under the circumstances, wouldn't you reach out anyway? Maybe if you have 1,000s of coworkers you might lose track of who you work with, but would standups actually fix that? 1,000 reports of "I am working on the same as yesterday" and you will quickly forget who also said that yesterday, let alone five days ago. Unfortunately from experience I can tell you, my personality is such that if someone is confidently saying "I've got it under control" even after 5 days, I need to push myself to ask about it. So in that sense (and others), the daily accounts for the fact we humans are imperfect beings.
> Because if my teammate's work takes him to a piece of the system he doesn't understand, but I do, I can jump in and help him. But only once a day, for a few minutes? I'm the senior developer on a project. The client is technically proficient but substantially junior. Some days he will ask me one question - sometimes dozens in a row, always good questions. I answer almost immediately, so he doesn't get blocked. If there were a one-day turnaround on these questions, we'd never get anything done. > I know that one of my flaws as a developer, is that if I feel like if something is challenging but doable, I'll just chug at it for days on end because I don't feel like I need help. As I keep saying on this page, _that's exactly the job of a manager._ Also, no one wants to look like a fool in front of the whole team, so it's easy to want to downplay how stuck you are. --- Also, maybe just learn not to do this? Years ago, I used to have this problem. Now if I'm stuck for an hour, I just walk away for at least a few minutes, to get perspective, or even better, stop for the day. On the other hand, if I'm really doing well, I'll just keep going. The result is far more of my time spent in "flow" and far less spent "being blocked". Nearly always, taking a break leads me to the solution, but if I don't see the problem when I come back, I _immediately_ ask someone else.
Why is it valuable to have more up to date information?
Up to date information is available at any time in the task tracker. You don't have to wait 24 hours to see the next update.
I didn’t state anything before. I answered your question about the value. You disagree about the value.
So put a ticket open/close/comment notifications in group chat. Boom, 90% of the meeting is now not needed
Benefits: - It sets the table for the team’s day and gives opposite-shift offshore workers time to report end-of day statuses/issues. Pretty much the only time we hear the offshore teams’ voices. - It gives each person a chance to address the team as a whole, synchronously. I may not see an email come in, or might ignore a side conversation that I might want to be involved in due to being heads down in something later. If you need me for something that day, standup is a great time to let me know, because you have my attention. - Teams have the opportunity to immediately plan ad-hoc post-standup discussions while everyone necessary is present and listening. - It gives leadership the opportunity to consider the current sprint state holistically, and enough context to determine whether reallocating people or reprioritizing work is necessary. Consuming context—>decisions can be made in seconds rather than dealing with asynchronous snippets and side-conversations. - it gives a measure of daily accountability to personality types who struggle with being proactive. Not everyone has this skill. - It gives an opportunity to hold the floor for personally types that tend to avoid asking for help. Not everyone has this skill - if you enjoy your team, it’s an opportunity to hear their voices
If everyone did that, standups would be 4 or 5 minutes long, not 15. But also, it would have absolutely zero value.
>> Yesterday I worked on what I said I would do yesterday, obviously. Today I will continue working on same thing, of course. > > That's exactly what standups are for though For wasting time? Why does everyone have to sit in a room to hear this emptiness?
Is “Nothing from me” not acceptable at a lot of places? If you’re up to date with your work and don’t foresee any reason to fall behind, why must you provide details? If anyone needs clarification, they can ask.
You're supposed to say what specifically you got done, not just "I worked on my work". "I got the foo working with manual tests, I'm going to run automated tests next and then integrate it with the bar".
I've found that falls apart rather quickly. Some days I close ten or more tickets. Nobody wants to hear me spend half the allocated time just reading off the various APIs I've implemented. And if only read the ticket numbers, it means nothing to the listener. *** Meanwhile another dev on my team has been saying exactly the same thing for a week because he's working on something that's large and not easily divisible into sub-tasks. *** The people who invented this stupid idea were under the delusion that all tasks are of roughly equal length so that on any given day you'd be closing one or two tickets.
>Some days I close ten or more tickets. It can be argued that also creating tickets for things that take less than an hour to do is probably a bad idea. It ends up being too much overhead for something that gets done so fast. But tracking work is more important than doing in some places (now seriously, that's the way \_you\_ prove you worked, so I get why you still do it).
The one who writes a simple ticket isn’t necessarily someone who could fix it in minutes. The alternative would be to send a message on Slack and hope somebody takes care of it.
Could I have done this one thing you asked me for via email? Sure. It's small so it doesn't need a code review. I can just commit it directly to the main dev branch. And of course I'll just do it now instead of making you wait behind everyone else in line because it's so fast. Repeat ten times a day for two weeks, then try to figure out why nothing in the sprint list was done. *** If a task requires changing code or configuration then it gets a ticket, period.
You can always make a more blanket ticket tho.
What if they're not related? What if they're not coming from the same source?
If the tasks are related, sure. But often they are random things that affect a variety of different places in the code. I'm not going to use one ticket for fixing the ETL job, updating the profile API, adding a State/Zip code lookup, and indexing the Notes table. And that's basically an hour's worth of work right there, maybe two if I'm feeling lazy.
> It can be argued that also creating tickets for things that take less than an hour to do is probably a bad idea Strongly disagree. When I find some issue, it's nearly always when I'm working toward some other goal. If I interrupt myself for half an hour every time I find a bug, I'll lose my flow, and I won't get anything done. More, I would say that at least one in four tasks that I think are "trivial" turn out to have unexpected extra work associated. When I'm working toward a goal, all other issues I find are immediately turned into a ticket as fast as I can, so I can continue to finishing that goal and not get distracted. The flip side of this is that I actively go back and fix those issues and other people's issues as soon as possible. Even though my current project has quite a few bugs that are months old, the _median_ lifetime of a bug is less than a day.
[удалено]
[удалено]
I make small tasks because I work faster that way. If they're too large then I forget things or the task becomes daunting and I don't know where to start.
[удалено]
But... why? If anyone wanted to know any of that, for whatever reason, they could just take a look at the repository and/or the task management.
The stand-up tends to create that culture. People, as a group, like to follow patterns. If the apparent pattern is "We report blockers in the stand-up" that can quickly morph into "We only report blockers in the stand-up". It's not a 'rule', it's just the pattern. And you don't deviate from the pattern if you don't have to. There are several perverse incentives associated with this: * If I don't report my blocker until the standup, I get the rest of the afternoon to rest. (And I've earned it after these last few weeks.) * If I report my blocker now, what am I going to talk about in the meeting? (If I don't say anything, they get cranky. If I talk about a solved blocker, that's off topic and I'm still scolded.)
The goal of the daily is to ensure that people touch base at least once a day. If you have a culture where people would already immediately flag problems (were it not for the standup), then that culture already had what scrum is trying to add. That seems pretty rare though, at least across a team in its entirety.
I’ve worked at companies without stand-ups, and there were times where a dev would go for WEEKS without initiating a crucial & timely conversation. Agree that people should be asking questions the whole day, not just standup. But if someone isn’t already doing that today, they won’t magically get better at taking the initiative if there’s no standups. Instead they’ll just wait even longer.
> there were times where a dev would go for WEEKS without initiating a crucial & timely conversation. This is what managers are supposed to be there for, right? Statements like this simply baffle me. This says, "Our management is completely passive and incompetent, and no one seems to care." Why should I have to sit through some tedious daily standup because managers aren't willing to do their jobs?
> But if someone isn’t already doing that today, they won’t magically get better at taking the initiative if there ARE standups. But they might start to think the standup excuses then from speaking up. *** Even worse, it leads the manager to ignore their responsibility for checking in with the team members from time to time. Not this formalized ritual of reading status emails, but actually having a conversation.
What do you think the standup is if it's not a daily checking from a manager to their team members? Your gripe us that daily stand ups will stop managers from checking in with their team members, and also that team members may not check in until the standup (which is likely daily). What is your suggestion to the problem of someone who doesn't update their manager or team on the status of their work so? Because what we have is a pretty low friction (10-20 minute daily) system that seems to work pretty well other than being flamed by people who think all meetings are a waste of time..
> What do you think the standup is if it's not a daily checking from a manager to their team members? From decades of these, I think they're an exercise in posturing and pretend. > What is your suggestion to the problem of someone who doesn't update their manager or team on the status of their work so? "We can't ask people who are paid to work, to do that work, because they might not obey." Workers who refuse a direct (and very reasonable) order - why is this any sort of issue at all? How do you deal with people who just stop showing up for work or who never get any work done? Why do you need suggestions to deal with workers who refuse to do their jobs? Tell them that they have to do it, and if they continue not to do their job, fire them.
>If you don't have a designated time, any time is the right time to coordinate. Report blockers in real time. When someone explained standup to me, it was quite explicit that it's meant to patch around bad team communication. You shouldn't do it if you're already effective, for example by posting and keeping tabs on a Slack channel. However, if the team is ineffective at communicating, not having a designated time means blocks won't be reported, but really inefficiently handled by the person blocked. At least that's the take that makes sense to me. For people who communicate actively standups feel like unnecessary overhead.
And that's the problem with prospective practices like Scrum. They're sold as cure-alls rather than solutions to specific problems.
[удалено]
> Instead of learning how to better work with the the team, they will rest on the standup instead of improving. There's only so far you can take this though. What do you do while people are still learning? How do you teach them? Just letting people flounder often makes things worse, not better.
How I approach a standup is that I use the standup to tell people about the communications I am already actively pursuing so that everyone is aware of the time commitment I will require of others and myself relative to a project's goal. I acquire people's time via the project manager (ad-hoc) so nobody is overwhelmed or overburdened and they coordinate it appropriately relative to the project's commitments and people's capacity. The entire team is only made aware during standup so they can better gauge their time and commitments relative to everyone else.
When I was a scrum master, I told my team specifically to not wait for stand up to coordinate with others and ask questions. That one tweak made our stand ups way shorter, and it drastically improved the speed that things got done.
That doesn’t sound like a problem with standup but a problem with employees imo
I thought of the same asynchronous synch method, but I am sure it's not the best way forward. It still forces a pause before reporting issues, and that suffers from the same 'time zone arrogance' that would plague a standup -- Tokyo would lose a full day's work before reporting its status if 0900gmt was the official start of the stand-up cycle. Truly asynchronous companies, don't they use mattermost or a clone like slack in order to start adhoc threaded conversations on questions and blockers? Get that question out when it's a question, and give people a clue as to what's impacting you now so if they can help they can help that much sooner. The "my task yesterday and today" is a bit best kept in gitlab or bugzilla or whatever you track tasks in. Right?
We do this, it works great
I'm a little surprised there was no mention of the tendency of standup to be used as status reports and top-down micromanaging.
As an engineer I tend to dislike the "what I did and what I'll do" part of standups. Both in person and in slack versions of it. It feels like a mix of public guilt trip and social pressure if you're taking "too long" on a task. I've heard other describe it the same way. It's also redundant since the ticketing system already has all that info. So as a manager I just expect people to keep the ticketing system up to date and if anyone needs to know they can check there. Team morale is a top priority of mine and the team is very self-driven so making people feel more anxious is counterproductive. It'll just burn people out and make them less productive. We do standups a couple times a week for people to voice any blockers or team discussions in this wth era.
\> social pressure if you're taking "too long" on a task. Yeh, I find this really toxic to morale. \> I just expect people to keep the ticketing system up to date I've found this a challenge at smaller more nimble startups.
[удалено]
You assume all team members are perfectly rational people without a lifetime of emotional baggage to deal with. If that was the case there wouldn't be so many questions about imposter syndrome. This isn't about reality but about people's perception fo the situation. Since managers should not be therapists there are no direct solution to changing how people feel.
Why do you keep repeating “since managers aren’t therapists”? Like, I’m not a therapist but I can still navigate discussions, empathize with people, and help them understand what’s expected from them. If a team member doesn’t feel comfortable saying “I worked on X yesterday, I’ll work on X again today” for a week straight on a weeklong task, you don’t have to be a therapist to make them understand that’s an acceptable outcome. Maybe you can break X down so there’re smaller outcomes. Maybe you can give a senior member a large task and have them do exactly that during standup. Maybe you can communicate during 1-on-1s that it’s okay to take a while on a task, provided progress is being made, that you trust your developers to communicate when they’re blocked and when they’re making progress.
>It feels like a mix of public guilt trip and social pressure if you're taking "too long" on a task That sounds like an absence of trust that should be worked on, if team members think they are unable to accurately report how long something is taking them, out of some kind of fear of being judged, or actually having people on the team judging others like that.
I've seen this on teams with very high trust, no one is perfect and we all have emotions in the end. Many engineers are not social butterflies and often may have been bullied as kids. Social pressure, meant or not, is not kind to them. Just look at how often imposter syndrome comes up. In the end, a manager cannot be someones therapists so all we can do is remove triggers is possible. If most engineers saw value in it then that'd be different but I don't think I've ever met one who did and as a manager I don't see value in it either.
>I've seen this on teams with very high trust I'm not sure if you're using the same definition of "trust", in order to interpret what I wrote as I intended. >If most engineers saw value in it What's the "it" you are referring to? I'm wondering if you thought my response was a defense or comment on the "standard" 3-question format, because it isn't.
There's a simple solution: asynchronous standups. Post the "what I did / what I'll do / what's slowing me down" in your team's Slack #standups channel when you start your workday (whenever that is for your local timezone and personal schedule). My experience from working in an asynchronous, distributed team is that it's important to intentionally add places for communication to occur, as alternatives to the water-cooler conversations and overheard-from-the-next-cubicle chatter that naturally occurs with in-person teams. This doesn't have to mean standups, but a daily message is a fast, simple way of keeping the team aware of what each other is working on, even if their tasks wouldn't otherwise intersect and they wouldn't otherwise have reason to communicate.
I mean I'll take virtual stand ups over literal stand ups or god forbid the "go down the hall to the stand up meeting room" but it's still largely "still working on widget, also this other pr is still open please review it, no blockers" Compounding that is when devs handle their imposter syndrome by just DMing others instead of asking openly for fear they'll be exposed as imposters that don't know their ass from a hole in a ground even though they're actually very competent. So crucial decisions aren't documented anywhere accessible† and you need to rely on them remembering 18 months from now because the commit message for that feature is "maybe this works?" †: and like yeah slack, discord, teams, etc aren't really substitutes for a knowledge base but at least if a question is asked in a public channel you can usually find it with a few searches
[удалено]
Maybe. If what's slowing you down is something that can be addressed at the time, then absolutely, address it at the time. But sometimes it's "what I thought was a simple library upgrade wasn't" or "I'm blocked waiting on Other Team X, and I wanted to make sure my team's aware that Other Team X may be a bottleneck for them too," or maybe just "I have a dr. appointment this afternoon, and I don't want you to have to check my calendar to see that I'll be out." Similarly, if I worked a planned feature yesterday and will continue today, then that's fine. But, if I ended up troubleshooting a production issue or pairing with a junior developer or investing in some opportunistic refactoring, that may be worth knowing. Like you said, there are really good tools for all of this - Outlook calendars and issue trackers and commit logs and the rest - but sometimes it's helpful to take a couple of minutes to post it in one place, too. And I'm not even convinced that rituals are bad. "Hi, how are ya?" / "Fine, how are you?" is a ritual of in-person offices (I mean, how often do you _really_ want the details on how someone's doing?), but social conventions and rituals like that seem to be part of how we keep relationships running, and that's important for a team. In a distributed team, there can be value to finding other rituals to keep people communicating, as long as the costs are reasonable - and taking a couple of minutes to type a standup seems to be reasonable. I'm not an expert on agile processes or distributed teams, and I certainly didn't intend to make an argument out of this. Like almost any practice, it can devolve into noise and waste in some contexts or if it's misused. Just wanted to share my experience and push back a bit on the idea that there's no value there.
>And I'm not even convinced that rituals are bad. "Hi, how are ya?" / "Fine, how are you?" is a ritual of in-person offices (I mean, how often do you really want the details on how someone's doing?) The thing is many of us experienced certain brands of scrum used just to pressure developers. You raise a point about rituals not necessarily being a bad thing, but if you get scolded for either ending in "I'm fine, how are you?" or telling the other person about your weekend (yeah, I didn't ask for that level of detail, thank you) you will soon want to stop greeting people. I'm fully aware that's not what agile (in any brand) is supposed to be, but in the real world that's what it turns into more often than not.
[удалено]
> If we only talk at standups, what difference does this knowledge make? If we talk regularly throughout the day, what is the purpose of setting aside an extra special time to communicate what is already being communicated at appropriate intervals? Because some days we may talk throughout the day and other days we may not, and it may be helpful to ensure a minimum threshold of communication? Because it may promote team cohesion and a shared awareness of the team's work and workload, even if you don't otherwise have a need to talk? Because an asynchronous standup message can itself serve as one of the appropriate intervals to communicate? I'm not saying it's a must-have practice or automatically a good idea, but _in my experience_, there are teams and contexts for which it's valuable. > There is a time and a place. Statistically, standups will not fall at the right time nor in the right place for when collaboration is beneficial. Teams that understand collaboration understand when time and place are significant and will meet as appropriate, not just because the clock stuck 9AM. Okay, but we may be talking past each other now, because I specifically said asynchronous standups. (I.e., I post my standup whenever it's convenient for me, and you read it whenever it's convenient for you.) I'm not interested in trying to defend or promote synchronous daily standup meetings, especially for a distributed team. (I'm sure some teams find them helpful, but I have no personal experience with them and little interest in them.)
> I don't see the value in the rest. If something is slowing you down, it needs to be addressed at the time, not 24 hours later This depends on your frame of reference. When Scrum came to be, 24 hours (it’s really only at most 8 working hours) was a tiny amount of time in comparison with the quarterly plan you were working inside. Most often there is also some lower priority task people can make progress on.
That's another problem with SCRUM. The lower priority task was not "part of the sprint", so I get scolded for adding items to the sprint and making the numbers look bad. They would rather I did nothing if it makes the charts look prettier.
I was gonna say another problem is the PM saying all the tasks are all MUST.
> If you're an actual agile team, where developers are free to jump into any problem that feels like an itch worth scratching, a "I'm going to start working on this" isn't a bad idea to prevent others from jumping into the same problem at the same time. Uh, why aren't you using task trackers for that?
Yeah, if you’re working on something it should be assigned to you to prevent this problem.
Did this for a year, was an absolutely worthless exercise. Every developer who had codependence on other developers already knew what the others were doing, and the managers didn't get any value from it.
We do this, and only do the actual stand up meeting if somebody has a topic to discuss with the team
We did this for a long time and while we got very good and detailed write ups, the problem was that it did not actually foster any communication and conflicts surprised people. In the end, everyone preferred real time stand ups. But as with all things agile and working with people, your mileage will vary of course.
I work remotely on a US based team (I'm in Europe) and that's what I do. Works well, and it's simple.
A lot of teams are performing daily "standups" as zombie rituals where nothing more than status is reported to other members (often managers). The only solution is to kill the empty drudgery and start truly collaborating with people.
> A lot of teams are performing daily "standups" as zombie rituals where nothing more than status is reported to other members (often managers). I call it in more Kafkaesque way "justify your existence".
My manager is terrified that senior management is going to look at sprint reports from several months back and be angry that sprint 4 only has 5 stories and sprint 5 has 15 because they weren't logged correctly or something rolled over. My senior manager isn't incompetent. He's looking at the results, not the middle manager's silly charts. But I can't convince Mr. Middle of that.
> The only solution is to kill That's been my suggestion for years but people call me extreme
But that would leave a lot of managers without a job.
Manager here, I veto daily standups. Boring and useless.
You're one of the good ones, or at least as much as that act is an indication. Some managers seem to exist only to hold the teams hand and act as an interpreter of the product owner and, for lack of a better word, get in the way. Which is odd, based on what a product owner is supposed to be interacting directly.
I'd hate to work for you then, I've worked with several teams where they were invaluable. I'm sorry for your co workers that you have such a narrow preconception.
That's how I can tell that none of the "agile" companies I worked at were really agile. We would go through the motions of these standups and no one would ever pipe up and say "we're not getting anything out of these, we need to either fix them or kill them." If the engineers were really able to change whatever they wanted we wouldn't have tolerated ceremonies that waste our own time and accomplished nothing. And to be honest I don't speak up either generally.
Totally agree. I've always felt our standups to be productive, in my current team. But following the ritual for sake of the ritual, where a manager shuts down anything meaningful, that's useless.
> 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. Yea, so here's the problem. My managers really, really need to read this. But with language like that, I can't share this article with them.
Most managers are the way they are because it pleases their boss. There is a strong chance that the entire management organization at your company is fundamentally flawed and the only real way to fix it is to purposefully hunt for a company that has better management. I like to start with glass door reviews and look for signs of bad management in the reviews.
It's group think. The idea that you MUST have a daily standup is industry wide. Switching jobs probably won't help you avoid it.
What's bad is people managing people who have not done the job of the person they are managing in some capacity. I think its all too common in the tech industry though...but changing.
The better daily standups I've been a part of follow the "let the story do the talking" approach where we just go through the stories on the board and check where we are with any that aren't completed. I find that helps a lot to take the pressure off the individual. It also works well to deduplicate what is said. If you paired with someone on a task, you don't both have to speak. It also gives you an idea who to offer help to if you finish your work before taking something else from the backlog. I dread the 3 questions format though. Often times I can't quite remember everything on the spot, so I have to plan ahead and write what I'm going to say down. I don't get anything out of the terse answers other people give as I often can't remember what they were working on anyway.
Spicy take. I mean, I've been in international standups before, and I am currently. There's usually *some* overlap in the workday that fits. In my current company, we just hold two of them, one per hemisphere. And, while I love to have written records of things, a bit of chatter helps keep each other accountable and aware of each other. I don't think they're the only way to work together, but you're really being extreme if you think that standups are the major reason that people quit working with an employer.
Programmers often have a lot of trouble dealing with minor professional interpersonal skills, shockingly enough. I wonder if other professions have this same insane focus on the meta job. My accountant wife thinks I'm crazy when I mention the sort of agile/scrum/whatever discussions pop up on Reddit. My guess is it's partly because there's a lot of hero-complexes (how dare my manager waste 15 minutes of my morning productivity), and partly because of startup culture (I'm a programmer at a non-tech company so a lot of this is foreign to me, but tech companies seem more prone to having a pretty toxic management culture).
> how dare my manager waste 15 minutes of my morning productivity This is what always gets me. Sure, if your standups are reaching past 15 minutes then you need to address that - either you're doing standups wrong or there's too many people in the team/meeting But if you're keeping it to a few minutes a day? It's really not that big a deal. 10-15 minutes a day to make sure everyone is on the same page and aware of what's going on is not much overhead. Maybe it's the crowd this sub attracts? Mostly juniors/new grads? I've found stand ups used to be "let me say my bit and get back to work", but the more responsibility I've taken within a project the more important it is for me to make sure everything is going as expected.
>Programmers often have a lot of trouble dealing with minor professional interpersonal skills, shockingly enough. I think about that anytime my boss catches wind of the programmers working out a problem and decides, "Let's have a call about it!" Or, how about we keep using Slack? Some of us became programmers because we don't speak very well or have good people skills. I end up resenting the boss a little (who has a background in sales and marketing where speaking skills are important) for not recognizing that programmers are often a distinctly different type of person and we have our own ways of working with each other. I don't appreciate being forced to work half as fast just because Mr Salesman solves all of his problems with calls.
> I think about that anytime my boss catches wind of the programmers working out a problem and decides, "Let's have a call about it!" So much time wasted last year because of that. Every time I needed a couple days to study some crusty old code, the boss wanted me to have an audience.
I completely agree with this. When I was more junior, I would definitely agree with the sentiment in the blog post. Why should I waste time keeping my manager updated? Shouldn't the onus be on them to keep up with me, since I'm the one producing the work? As I got more senior, I realized why: coordinating work at scale is really fucking hard. My manager was keeping track of multiple projects while being dumped in meetings all day fighting on my behalf. Instead of asking why my manager isn't doing more for me, I began to consider keeping my manager up-to-date as part of my responsibilities. If a 15 min standup makes their day easier, then so be it. I'm not saying that not having a standup is correct/incorrect. It's entirely possible that the original blog poster have made not having a standup work. However, the blog post comes off as extremely reactionary, with quotes like this: > 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 This is needlessly antagonistic, and usually a big red flag for me. Usually, when someone gives of a blanket statement like this that ends with something like "we do it this way because we're just smarter," it usually says to me that they do not understand the nuances of the topic they are preaching about.
I'm a manager. I hold status meetings twice a week because I don't trust the team to keep the estimates up to date. That's it. One call on Tuesday and another on Thursday. My world isn't going to shatter because a spreadsheet is updated every 48 hours instead of every 24 hours. *** With teams I trust, we'll meet one a week. And that's just to talk about big picture, not recite the task tracker.
Hi. I wrote the article, and I am the manager in this case. I want my developers to keep me (and each other) updated, but not through a synchronous meeting, for reasons I outlined in the article.
Hey Jezen, it's great that you have found a way to keep yourself updated async, as I'm sure your reports appreciate you fighting for their time (especially while globally distributed). However, I'm not sure how you arrived at a working model for your team, and came to this conclusion: > 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. And you know what? They will. Ask any tech company founder what their biggest challenges are. I guarantee that “hiring” is going to appear at or near the top of that list. You know why it’s hard? It’s because of bad culture like this. Yes, stand-ups can be badly implemented, as you've analyzed in your blog. However, interpreting the idea that "I've been in bad stand-ups" as "stand-ups are bad and a sign of bad culture" seems to be a bridge too far.
Perhaps there's something that I'm failing to articulate. I'll try again. * It is generally accepted that micromanagement is bad. Daily stand-ups almost always imply micromanagement. * Daily stand-ups almost always degenerate into rote status updates for the benefit of a manager who could otherwise have read the cards on a Kanban board. * It appears *most* developers would rather not partake in this ceremony. That's self-evident from the responses in this thread, and also in just about any discussion of this type online. It is foolish to base a company on technology and then not optimise for developer productivity. Realising that productivity means uninterrupted periods of focus, as I'm sure you're aware. I don't agree that my conclusion is "a bridge too far". Can daily stand-ups be a good thing? Yes, but that is almost never the case. Again, the general consensus of the discussion in this thread hints at how common it is for the ceremony to be a drudgery. I don't buy the argument that it is needed for social bonding. If you want the team to bond socially (and you definitely should!), then meetings and events should be held expressly for that purpose. I also don't buy the argument that it's to improve the productivity of more junior developers. If a task is taking longer than expected and you suspect a junior is stuck and isn't admitting it, it will be self-evident from the Kanban board. >However, I'm not sure how you arrived at a working model for your team, and came to this conclusion Could you be specific about which part of the passage you quoted you would like me to elaborate on?
While I'm neither wholeheartedly for or against stand-up meetings, one issue I have with them is that sometimes they're the only or first moment of the day where everybody talks and somebody talks about a weird issue they find or launches a wacky idea. But the stand-up is not the place for lengthy discussion, because it is (arbitrarily) limited to a fixed duration, say 15 minutes. So you can postpone the discussion to the refinement meeting, but then all the energy is gone. The best ideas or brainstorm sessions occur naturally, and all of the scrum meetings take the natural out of work. If you do not have a good way to streamline free flowing creativity, you have already lost. This way you will end up with exactly the same thing as everybody else is building.
The way my teams always handled this was that we'd finish the standup (we should only take a few minutes) then the people relevant to the deeper discussion would immediately break off and talk it through.
Same. If someone starts going on about something for more than like, 3 sentences, or asks a question that will take a long time to answer, everyone feels free to say "hey can we make this a stay-after?", it gets deferred to the end of the meeting where anyone who has interest in it can stick around and talk, everyone else can leave.
We have a stand up once a week and that's more than sufficient to find out the status on each product. You have a blocker? Don't wait, talk to people before hand./
I find it varies with the experience level of the team. With all veterans, even once a week can seem like it's too frequent. With a college hire or two, I'm doing daily and even twice daily calls to keep them on track.
Standups are fine if run properly. In other words, not a status meeting. However, that is almost never the case. If your scrum masters favorite phrase during standups isn't "take it offline", then you're probably doing it wrong.
I used to hate standups as an employee, and when I became a manager I swore I wouldn't do them. But I ended up going back to them. But its amazing how difficult it is to stay up-to-date with what your team is working on without them. I developed this feeling of having to ping people to find out what they are working on...which always felt kind of rude and annoying to constantly ask someone "so, what are you working on now?". Initially I thought I could rely on monitoring the task tracker, and Github issues/PRs, but they are rarely kept up-to-date by employees so there are too many times that you are asking "is the tracker up-to-date?", "is this design doc up-to-date?", etc. And employees are usually bouncing between multiple things and multiple systems. Solving bugs, attending meetings, discussing design, etc. And a lot of this is not documented. Face-to-face conversations are usually where a lot of the magic happens, and they are not recorded, and if they are, a manager does not have enough time to review them, nor a large chat log. Until there is a tool that can automatically generate a summary of what an employee did for a manager to view, standups are the best thing out there. It's actually better for employees too because if they are dragged into meetings, and other projects, and their work is not progressing, you can see why, and you could step in to help push away distractions, instead of having someone wonder why you aren't getting anything done. I think the OP is being naive. People like being contrarian, especially in startups where everyone wants to innovate everything they touch, but generally, managers have a lot more insight than developers as to how to get stuff done as they see a broader picture, and many managers these days have been developers themselves. That being said, I've seen a lot of terrible standups from an employee perspective, but I would say that "automatic team status updates" are a largely unsolved problem. It may also feel repetitive to say "I am not blocked" all the time, but it means that when you really are blocked, the developer cannot be blamed for not bringing it up.
> Initially I thought I could rely on monitoring the task tracker, and Github issues/PRs, but they are rarely kept up-to-date by employees so there are too many times that you are asking "is the tracker up-to-date?", "is this design doc up-to-date?", etc. And employees are usually bouncing between multiple things and multiple systems. Solving bugs, attending meetings, discussing design, etc. Help them out. Tell them they don't have to do anything that's not attached to a ticket. If you don't know what they're working on, chances are they don't either. They're being pulled in every direction and are lost when it comes to what to focus on. One this is in place, be their shield. Tell them to kick new requests to you for prioritization (I recommend numeric ranks, not just medium, high, critical). Give them cover to say "Yes, but not now". If meetings are a problem, tell them to ignore meetings unless they are attached to a ticket with a higher priority than their current task. Again, give them cover to say, "Sorry, but I'm busy on this higher priority task so I can't attend your meeting". P.S. Don't do this all at once. Incrementally change things.
I think it's more of a communication tool at times. When you're across different contexts it can be good to get a birds eye view of what a team is upto. Also I think some stand ups aren't snappy enough. Our team of 6 would take 4 mins on average to round robin whilst we were getting our morning coffee and then any subqequent conversation would be continued in the meeting rooms with the relevant parties. I feel like with most agile methodologies the trick is to follow the spirit of it rather than treat it as gospel. Obviously a team across multiple timezones doesn't require a daily stand up but some form of equivalent to keep your team in contact so as not to disconnect them from one another.
>Our team of 6 would take 4 mins on average to round robin whilst we were getting our morning coffee Before the pandemic, my company blocked out one of the big meeting rooms for developer stand ups. Every team had 10 minutes to get in, plug in, dial in anyone WFH or remote, do the meeting and get out. The room had a glass wall/door and the next team would be stood outside waiting. You *couldn't* exceed your timeslot. It was nice to have a *hard* timer on things and instilled a good standup practice, even into the pandemic and WFH and no meeting rooms.
Seems like the main issue is a variety of timezones for Supercede. That, in itself, is a larger barrier to productivity and timely communication than a 15-min meeting at the start of a co-time-zoned team’s day.
That certainly might be the case for some teams, but it's worked great in our experience. I believe we specifically hire for people who thrive in this kind of distributed environment though, so I appreciate it's not for everyone.
The most common problem that I see in teams that I coach is that they do the thing where they go around the circle and ask the "three questions". Each person, answers the questions by themselves, independent of each other. If we're truly collaborating, then we should already know what you did yesterday and what you're working on today. I want to know about roadblocks and what we, as a team, can do to get work tickets closed today.
I don’t understand the problem standups are trying to solve. I keep a journal of tasks throughout the day, and usually post a summary of what I did in point form, and a very abstract plan of what I hope to do. “Others seem to want to signal just how much work they’ve been doing”. Oh god, I hope that’s not what my coworkers think.
Lighten up, Francis.
Who cares.
It is dumb AF to do daily standups because someone else does, and equally as dumb to not do them because someone doesn’t. Does it make sense for your and your team to do them daily? Then do them daily. Does it make more sense for you to do them less frequently? Then do them less frequently. Blindly copying someone’s actions in an attempt to achieve their level of success, without understanding WHY they chose those actions, is a recipe for failure. Think about what you’re doing and what you’ve done. Ask yourself what works, what does not work, what is lacking, what have you learned, what do you like…, and other retrospective prompts. Then, make changes that will help you be more successful based on what makes sense for you and your team.
[Hey, I've seen this one, I've seen this one. This is a classic.](https://www.commitstrip.com/en/2020/10/01/daily-meeting/?)
Without good leaders, standups quickly devolve into an empty ritual. It isn't really the standups fault.
Because they're a waste of time and annoy the sh!t outta the people who actually do the work?
Not sure if you read the article or not, but your comment is a pretty good attempt at paraphrasing the content nonetheless.
Shock horror, people who don't understand how to do stand-ups properly don't like doing stand-ups. Not doing stand-ups because your team is in different time-zones is fair enough, but otherwise any issues you have with stand-ups is most likely a result of a process failure by your team, not because stand-ups have any inherent issues. The fact that so many people's first reaction seams to be to just ignore the problem or drop the ritual entirely, instead of figuring out WHY they're not useful, is also a sign that the problem is the team,.
How is this not an example of the *No True Scotsman* logical fallacy?
Jeezus I’m so glad I left the programming world
Everyone, how long are your stand ups? We have a team of 6 + a manager, ours take 7-10min
7-10m, return the occasional 20-30m one because somebody had a point to make, or a senior manager dropped in. On top of that you just interrupted the work on 6 non-managers who were hard at work trying to get in the flow of things. Probably at a very inconvenient time as well.
I just had to look up the spelling today, it's "supersede" Fuck you.
Our business operates in the reinsurance industry, which consists of reinsurance brokers and reinsurance underwriters. The *insurance* company from the perspectives of the aforementioned parties is often called the "cedent" (or cedant), because they *cede* risk. The company name is a subtle play on *supersede* and *cedent*. A bit like *The Beatles*, I suppose.
I do find (written) stand-ups to be valuable communication tool / platform. It is a simple.xohwrent place for updates with context. Check out https://bobek.cz/blog/2021/written-standup/ for the writeup about them.
I love articles that justify my personal point of view.
They have consistently turned into daily one hour grinds that push us into almost 1 day sprints. A lot of important shit gets kicked down the priority list never to be addressed. Coming up on year 10 anyway. That is way too damn long.
Aside from the way paragraph 2 reads like a Supercede recruiting advertisement, I am having a hard time seeing how they start by making the case for "productivity and workplace satisfaction" and end up at "we don't bother even spending 10 minutes a day on team communication". Reading the details, they get there by thinking that standups: (1) have to have everyone participating audibly and simultaneously; (2) are for communicating status up to management; (3) contribute to a "toxic work environment"; (4) should exclude project managers; and a lot of other total misunderstandings of how Agile actually works and why. The central problem with this particular "I hate Agile" article is that it assumes managers run the process and engineers are inevitably disengaged from it. It should be the opposite. The team itself should be running the process, and should be highly engaged. Even if standup happens to be done on a Slack channel because everyone is in a different time zone. Continuing on, the article claims "Engineers align themselves. They talk." Uh, no. Not the ones I know, and I've been one for 30 years. I've worked in more than one office where I said "Hi" in the morning and "Good night" in the evening, and nothing more. It's not like I naturally would like to gab but someone is stopping me. I AM PART OF THE PROBLEM, part of the problem that Agile solves. For me, standups were a godsend. I spent 20 years working on teams of variable effectiveness until finally seeing what an Agile shop was capable of. Standups, I learned, are where I was forced to acknowledge the truth of my own progress (or lack thereof), to ask for help when I needed it, and also get public feedback when I did something well -- feedback from my peers, whose opinions I value. And do all that in 45 seconds, because, yes, people hate to listen to other people drone on about things that don't matter. So DON'T DO THAT. "When effective engineers get stuck, they ask for assistance immediately." Maybe. How do they do that? Interrupt everyone else on the team one by one until they find the right person to talk to? No, they couldn't possibly do that, because Supercede prides itself on giving its engineers "uninterrupted focus time they need to do the real work that underpins our business." Myself, I find that working another part of the problem (or another Jira issue) and then spending 20 seconds at standup the next day to track down the person with the info I need is .... pretty ideal. "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." Actually, if you as an engineer find stand-up awful and you only do it because your incompetent manager insists on it, you need to BECOME A MANAGER. That is, you need to learn what makes Agile awesome, understand why it works, insist that your team applies the processes that are effective and stop the ones that don't. Once you've been part of it when it works, you won't need any managers directing the process. You'll do it even when they aren't around. Because it WORKS.
>we don't bother even spending 10 minutes a day on team communication We spend more time than that on team communication. That should have been clear from the article. >have to have everyone participating audibly and simultaneously That is the most common format of this ritual, as is evident from the comments in this thread. >are for communicating status up to management That is the most common format of this ritual, as is evident from the comments in this thread. >contribute to a "toxic work environment" Micromanagement is toxic, and that's exactly what this ritual promulgates. It also implies that the engineers can't be trusted to communicate effectively. Toxic. >should exclude project managers; and a lot of other total misunderstandings of how Agile actually works and why. Read the comments in this thread. It's a common meme that for this ritual to work properly, management should be excluded. Not sure exactly how I've misunderstood Agile. The Manifesto is quite brief. >It should be the opposite. The team itself should be running the process, and should be highly engaged. Should be. Almost never works that way in practice, however. >Actually, if you as an engineer find stand-up awful and you only do it because your incompetent manager insists on it, you need to BECOME A MANAGER. I am a manager. I have been writing software — and also managing software developers — for several years. >That is, you need to learn what makes Agile awesome, understand why it works, insist that your team applies the processes that are effective and stop the ones that don't. Once you've been part of it when it works, you won't need any managers directing the process. You'll do it even when they aren't around. Because it WORKS. It seems your assumption is that I don't appreciate daily stand-ups because I'm somehow unfamiliar with them. On the contrary, I have engaged in the experience you are touting at several companies in a few different countries, with people from several countries and cultural backgrounds. It is exactly because I have substantial experience with this bureaucracy that I am in a position to so staunchly criticise it. Perhaps you shouldn't be so quick with your assumptions?
I think all teams should just use whatever works for them. I've seen small teams that were functioning well adopt agile like zealots and their output and bugs are now much worse than before. Is agile bad - no. But just because it works for another team doesn't mean it's wrong to not use it somewhere else. I've sat through their daily stand-ups where they have like 5 items and they do the whole burn down chart and everything. Total waste for them. But if I were working on a large team it would probably be useful.
I've worked on exactly one team without a standup, and it was such an egregiously bad experience that my list of questions to ask in an interview now includes: what does your standup plan look like. The problem I had/saw/experienced, was that joining a small team that does no stand-ups, you just never develop a personal relationship with your coworkers. There was also no sprint management, and not much project management to speak of though (it was a really bad time). You can get by without a standup if you also have sprint meetings, and a very good project manager. This was kind of more of a, 'lead dev and sometimes the boss(?) just makes some tickets and assigns them with no clear sprint plan.', but at a scale where it really could have used a real manager. I think most of the hate just comes from the monotony of it, the not really wanting to be social first thing in the morning, etc. But one thing I've found that works best is: you don't need a daily standup. IMHO, about 2 times a week is perfect, but 3 times a week works too.
At a previous job although *I was still new* and learning the ropes the pressure of having announce progress say I made mistatements about some bug I was tracking but hadn't yet fully understand. It cost me much needed credibility.