4 ms·

It depends on the team. 99% of the time stand ups are there to help your manager/scrum master/team lead get a read on whether there is a problem that somebody o

It depends on the team. 99% of the time stand ups are there to help your manager/scrum master/team lead get a read on whether there is a problem that somebody on the team is trying to avoid mentioning. One of the biggest reasons to time-cap it is that overall...it really isn't a good use of time. On the other hand people are far too over the top acting as if it's the most awful thing they've ever had to deal with (it's 15 minutes and in most cases the only meeting you're going to have that day). People who can't tolerate a 15 minute chat with their team tend to have a lot of issue working well with others in my experience. The "I can't spare 15 minutes" mindset tends to live with people firmly in the "all about me" world. It can be hard to get out of the bubble of the work that you are doing. EDIT: I totally get bad scheduling that interrupts flow time. IMO either beginning of the day, end of the day or just before lunch is the ideal time to do it for that reason. Time zones also complicate it. People need to emphasize that the problem is the bad scheduling of the time slot rather than the 15 minutes itself. Also, it's a good idea to make skipping it periodically totally acceptable.

nine_zeros 5y ago
> It depends on the team. 99% of the time stand ups are there to help your manager get a read on whether there is a problem that somebody on the team is trying to avoid mentioning. In other words - micromanagement.
- brixon 5y ago
  Well, the manager is not supposed to be there. A scrum master is supposed to keep it organized and time boxed, but the team is supposed to self police/organize themselves. It's supposed to be like a restaurant where all the waiters share tips. It is in everyone's interest that one, all customers are being served well and two, that all waiters are pulling their weight.
  - jseban 5y ago
    Yeah which never happens in reality, as it's completely incompatible with a normal (risk averse) corporate environment. And the main premise is that there's recurring daily obstacles that the scrum master somehow can resolve, which never ever happens in reality. The daily is just an idea that never work out that way in reality.
    - vannevar 5y ago
      It does happen in reality. I've seen it many times, and it works.
      - jseban 5y ago
        Almost always the best way to solve an issue or a blocker, is for the person to simply continue to work on the task, alone. Very rarely is it productive to involve other people, and when it is, the person who is closest to this part of the work should be involved. To have a generic "issue solver" that solves everybody's issue is just not a good idea on a software team.
        vannevar 5y ago
        Almost always the best way to solve an issue or a blocker, is for the person to simply continue to work on the task, alone. No. There may be occasional cases where that's true, but it's almost always better to get another pair of eyes (and accompanying different experience) on a problem. There is some great software that comes from solo devs, but most commercial projects are simply too big for one person to accomplish in the time necessary. Business software is very much a team sport.
      - malermeister 5y ago
        But why does anyone need a daily scheduled meeting for this? If I get blocked by something, I message the appropriate folks on slack immediately. Why would I wait for some meeting the next morning?
        vannevar 5y ago
        Why would I wait for some meeting the next morning? You wouldn't. Why are you under the impression that scrum prohibits communication outside standup? Daily scrum is a floor on communication, not a ceiling. It guarantees that focused communication happens at least once a day. Sometimes people miss slack posts and emails. Scrum makes sure the entire team is aware of progress and blockers. It's a tiny slice of the day when it's done properly.
- papito 5y ago
  Stand ups are not as much for developers as much as they are for transparency. But this overhead is deadly in a small, under-resourced team. Kanban is a better choice. Just let people blow through cards with as little communication as possible. The wonderful dynamic of a tiny team is that everyone still sort of knows what everyone else is working on.
  - jseban 5y ago
    > Stand ups are not as much for developers as much as they are for transparency. Except the requirements for transparency is only for the developers, which makes it feel very degrading, all of the other people in this meeting, the leads, scrum master, product owner, ux etc, don't say anything about what they're doing, and they have no board with their tasks either so no transparency whatsoever.
- cloche 5y ago
  It's not micromanagement when the manager is trying to understand what is happening on the team. That's part of their job. If they were asking for updates from you every 5 minutes, that would be micromanagement. How long do you think your manager should go without knowing what you're doing?
  - nine_zeros 5y ago
    > How long do you think your manager should go without knowing what you're doing? A weekly status update is good enough for regular status. I must mention that if you are looking at status reports from the time dimension, you have already failed. The manager should cultivate an environment where engineers and managers talk in small groups at any time. There is no need for a standup for this. Everyone can decide for themselves if they need to spend time with someone else. The manager can decide for themselves if they need to chat with a report instead of taking away time from all reports everyday. Of course, this would require the manager to do the work to chat with reports and figure out what's going on.
    - TheCoelacanth 5y ago
      Weekly status updates are probably enough if the team is 100% senior devs who know how to work independently and who know how to proactively reach out if they need someone else to get involved with something. That is not the team composition most people are working with. The median developer in the industry only has a few years of experience.
  - skydhash 5y ago
    If you want to know immediately, ask me. If not, I guess a good indication would be the slack channel for the team (I'm working remotely), or the JIRA board update.
    - imbnwa 5y ago
      Thank you. There are multiple tools and channels for reading and querying all of this information. Between JIRA, and, if necessary, your VCS remote, you can figure out almost everything about what a team is doing. Any grey areas? Ask directly, with whatever channel suits the urgency. I once suggested that instead of standups developers write an end-of-day comment into whatever ticket they're working on. This would enable managers, others, by filling the blanks that status change/VCS timestamps might not tell you. People just looked at me like I was crazy when this would be even more efficient. Don't like the Burndown Chart over the course of a year? You can literally look at the Sprint Reports to see what issues/assignees are spilling over a course of time. Managers have all the tools they need but that's not the point of this stuff. The point of this stuff is to reinforce that they are the boss. They could even make the SCRUM Master's job actually useful and be responsible for this kind of research but I've yet to see a SCRUM Master be anything but a proxy for this antiquated posturing. Just as much as there's a general fear that labor is hiding behind process, so is management.
brixon 5y ago
Agreed, views against stand ups are either team members hiding issues or the team is not doing stand ups like best practices suggest. Most of my teams problems with Agile/SCRUM come down to skipping steps or not following best practices. Once we fix those, it gets better.
- mdtusz 5y ago
  What are the steps to agile? If you read the agile manifesto, there are no specifically prescribed steps or rituals, and in my experience, most teams implementation of scrum is entirely counterproductive to actually being agile. The core tenet of being agile is essentially people over process, and things like daily stand-ups, extremely formulaic retrospectives and backlog grooming meetings do nothing to empower the people and allow them to be truly agile.
  - icedchai 5y ago
    It's supposed to be "people over process", yet most "scrum" is all about process: too many meetings and other assorted bullshit like filling out your sprint planning and retrospective report every 2 weeks.
    - ryathal 5y ago
      Scrum is about getting people to talk to each other and that's what all the process is about. If you already have good communication between developers and those making the business decisions, then sure scrum is probably a waste. Places that actually have that communication without having scrum force those people into a room aren't common. It's also common that places that don't really do scrum don't have empowered PO's or devs, so the meetings are wasted time.
- d0gsg0w00f 5y ago
  Yeah, but devs can be finicky about waking up early. Half my team was fine with 9am and the other half preferred working more of a 11am-7pm shift. We experimented with asynch Slack standup but it fizzled out after a few weeks.
d23 5y ago
It’s not that the 15 minutes isn’t tolerable. It’s that it’s going to be scheduled poorly for someone, perhaps the entire team, in such a way as to break focus and drop context. A previous team I was on had standups at 10 am. This meant even if you wanted to start working earlier and get heads down on something, there wasn’t much point. Add in the typical context loading time and that meant you weren’t really able to get going until 10:30. And guess what? At that point, lunch is an hour and a half away.
- papito 5y ago
  Oh, God, I hate that. I would rather get the stand-ups out of the way first thing in the morning so I can have interrupted time before lunch, but most software engineers are massive divas, who think it's a horrible affront to be in the office before 10AM. And even then some people are regularly late. And now with no commute for most of is, it's still somehow difficult.
  - dawnerd 5y ago
    Just block out the rest of your day and auto decline meetings. I do that and it works great. Forces everyone to schedule everything before noon. Also make sure to schedule lunch in as well. It make sure you auto decline that’s the trick. If you’re manually approving/declining each one you’ll end up allowing some which signals the blocked out time isn’t that blocked out to the rest of the team.
    - papito 5y ago
      If you are not a manager, that sounds a little agro. I can stand for my untouchable lunch break, but the rest is not up to me.
  - malermeister 5y ago
    Not everyone's circadian clock works the way yours does. I hate having to schlep myself out of bed to join a pointless status update meeting half asleep. 10AM already is before my definition of "first thing in the morning". Maybe we should just kill the synchronous status update meeting altogether and avoid conflicts like these?
g051051 5y ago
> On the other hand people are far too over the top acting as if it's the most awful thing they've ever had to deal with (it's 15 minutes It's awful when it's interrupting valuable flow time. > in most cases the only meeting you're going to have that day If only that were true!

nine_zeros 5y ago

> It depends on the team. 99% of the time stand ups are there to help your manager get a read on whether there is a problem that somebody on the team is trying to avoid mentioning. In other words - micromanagement.

brixon 5y ago
Well, the manager is not supposed to be there. A scrum master is supposed to keep it organized and time boxed, but the team is supposed to self police/organize themselves. It's supposed to be like a restaurant where all the waiters share tips. It is in everyone's interest that one, all customers are being served well and two, that all waiters are pulling their weight.
- jseban 5y ago
  Yeah which never happens in reality, as it's completely incompatible with a normal (risk averse) corporate environment. And the main premise is that there's recurring daily obstacles that the scrum master somehow can resolve, which never ever happens in reality. The daily is just an idea that never work out that way in reality.
  - vannevar 5y ago
    It does happen in reality. I've seen it many times, and it works.
    - jseban 5y ago
      Almost always the best way to solve an issue or a blocker, is for the person to simply continue to work on the task, alone. Very rarely is it productive to involve other people, and when it is, the person who is closest to this part of the work should be involved. To have a generic "issue solver" that solves everybody's issue is just not a good idea on a software team.
      - vannevar 5y ago
        Almost always the best way to solve an issue or a blocker, is for the person to simply continue to work on the task, alone. No. There may be occasional cases where that's true, but it's almost always better to get another pair of eyes (and accompanying different experience) on a problem. There is some great software that comes from solo devs, but most commercial projects are simply too big for one person to accomplish in the time necessary. Business software is very much a team sport.
    - malermeister 5y ago
      But why does anyone need a daily scheduled meeting for this? If I get blocked by something, I message the appropriate folks on slack immediately. Why would I wait for some meeting the next morning?
      - vannevar 5y ago
        Why would I wait for some meeting the next morning? You wouldn't. Why are you under the impression that scrum prohibits communication outside standup? Daily scrum is a floor on communication, not a ceiling. It guarantees that focused communication happens at least once a day. Sometimes people miss slack posts and emails. Scrum makes sure the entire team is aware of progress and blockers. It's a tiny slice of the day when it's done properly.
papito 5y ago
Stand ups are not as much for developers as much as they are for transparency. But this overhead is deadly in a small, under-resourced team. Kanban is a better choice. Just let people blow through cards with as little communication as possible. The wonderful dynamic of a tiny team is that everyone still sort of knows what everyone else is working on.
- jseban 5y ago
  > Stand ups are not as much for developers as much as they are for transparency. Except the requirements for transparency is only for the developers, which makes it feel very degrading, all of the other people in this meeting, the leads, scrum master, product owner, ux etc, don't say anything about what they're doing, and they have no board with their tasks either so no transparency whatsoever.
cloche 5y ago
It's not micromanagement when the manager is trying to understand what is happening on the team. That's part of their job. If they were asking for updates from you every 5 minutes, that would be micromanagement. How long do you think your manager should go without knowing what you're doing?
- nine_zeros 5y ago
  > How long do you think your manager should go without knowing what you're doing? A weekly status update is good enough for regular status. I must mention that if you are looking at status reports from the time dimension, you have already failed. The manager should cultivate an environment where engineers and managers talk in small groups at any time. There is no need for a standup for this. Everyone can decide for themselves if they need to spend time with someone else. The manager can decide for themselves if they need to chat with a report instead of taking away time from all reports everyday. Of course, this would require the manager to do the work to chat with reports and figure out what's going on.
  - TheCoelacanth 5y ago
    Weekly status updates are probably enough if the team is 100% senior devs who know how to work independently and who know how to proactively reach out if they need someone else to get involved with something. That is not the team composition most people are working with. The median developer in the industry only has a few years of experience.
- skydhash 5y ago
  If you want to know immediately, ask me. If not, I guess a good indication would be the slack channel for the team (I'm working remotely), or the JIRA board update.
  - imbnwa 5y ago
    Thank you. There are multiple tools and channels for reading and querying all of this information. Between JIRA, and, if necessary, your VCS remote, you can figure out almost everything about what a team is doing. Any grey areas? Ask directly, with whatever channel suits the urgency. I once suggested that instead of standups developers write an end-of-day comment into whatever ticket they're working on. This would enable managers, others, by filling the blanks that status change/VCS timestamps might not tell you. People just looked at me like I was crazy when this would be even more efficient. Don't like the Burndown Chart over the course of a year? You can literally look at the Sprint Reports to see what issues/assignees are spilling over a course of time. Managers have all the tools they need but that's not the point of this stuff. The point of this stuff is to reinforce that they are the boss. They could even make the SCRUM Master's job actually useful and be responsible for this kind of research but I've yet to see a SCRUM Master be anything but a proxy for this antiquated posturing. Just as much as there's a general fear that labor is hiding behind process, so is management.

brixon 5y ago

Agreed, views against stand ups are either team members hiding issues or the team is not doing stand ups like best practices suggest. Most of my teams problems with Agile/SCRUM come down to skipping steps or not following best practices. Once we fix those, it gets better.

mdtusz 5y ago
What are the steps to agile? If you read the agile manifesto, there are no specifically prescribed steps or rituals, and in my experience, most teams implementation of scrum is entirely counterproductive to actually being agile. The core tenet of being agile is essentially people over process, and things like daily stand-ups, extremely formulaic retrospectives and backlog grooming meetings do nothing to empower the people and allow them to be truly agile.
- icedchai 5y ago
  It's supposed to be "people over process", yet most "scrum" is all about process: too many meetings and other assorted bullshit like filling out your sprint planning and retrospective report every 2 weeks.
  - ryathal 5y ago
    Scrum is about getting people to talk to each other and that's what all the process is about. If you already have good communication between developers and those making the business decisions, then sure scrum is probably a waste. Places that actually have that communication without having scrum force those people into a room aren't common. It's also common that places that don't really do scrum don't have empowered PO's or devs, so the meetings are wasted time.
d0gsg0w00f 5y ago
Yeah, but devs can be finicky about waking up early. Half my team was fine with 9am and the other half preferred working more of a 11am-7pm shift. We experimented with asynch Slack standup but it fizzled out after a few weeks.

d23 5y ago

It’s not that the 15 minutes isn’t tolerable. It’s that it’s going to be scheduled poorly for someone, perhaps the entire team, in such a way as to break focus and drop context. A previous team I was on had standups at 10 am. This meant even if you wanted to start working earlier and get heads down on something, there wasn’t much point. Add in the typical context loading time and that meant you weren’t really able to get going until 10:30. And guess what? At that point, lunch is an hour and a half away.

papito 5y ago
Oh, God, I hate that. I would rather get the stand-ups out of the way first thing in the morning so I can have interrupted time before lunch, but most software engineers are massive divas, who think it's a horrible affront to be in the office before 10AM. And even then some people are regularly late. And now with no commute for most of is, it's still somehow difficult.
- dawnerd 5y ago
  Just block out the rest of your day and auto decline meetings. I do that and it works great. Forces everyone to schedule everything before noon. Also make sure to schedule lunch in as well. It make sure you auto decline that’s the trick. If you’re manually approving/declining each one you’ll end up allowing some which signals the blocked out time isn’t that blocked out to the rest of the team.
  - papito 5y ago
    If you are not a manager, that sounds a little agro. I can stand for my untouchable lunch break, but the rest is not up to me.
- malermeister 5y ago
  Not everyone's circadian clock works the way yours does. I hate having to schlep myself out of bed to join a pointless status update meeting half asleep. 10AM already is before my definition of "first thing in the morning". Maybe we should just kill the synchronous status update meeting altogether and avoid conflicts like these?

g051051 5y ago

> On the other hand people are far too over the top acting as if it's the most awful thing they've ever had to deal with (it's 15 minutes It's awful when it's interrupting valuable flow time. > in most cases the only meeting you're going to have that day If only that were true!