4 ms·

> 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

> 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

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.