5 ms·

> I did not do morning standup's because I did not think I was going to get buy-in from the rest of my team Standup is expressly designed to function as a sub

> I did not do morning standup's because I did not think I was going to get buy-in from the rest of my team Standup is expressly designed to function as a substitute for meetings - and to avoid the situation where employees waste time in meetings where only 10% of the meeting content is relevant to their particular domain/work. The reason individuals are required to stand, is so that there's a slight physical discomfort in order that people report quickly (ours are about 1 minute per person). If there's some topical convergence on a bit of work that emerges from standup that requires further elaboration and communication between members - then the idea is that those team-members will be able to self-organize a meeting outside standup. The key benefit is that noone else on the team needs to be distracted with things that don't concern them. It really puzzles me, that so few seem to comprehend the basic principles behind Agile workflow.

chris_wot 11y ago
How do you do standup with a remote workforce?
- mindcrime 11y ago
  Don't be overly literal, and use a conference call, Google Hangout, etc. If time zone differences prevent even that, do a "virtual standup" using email, wiki, blog, or whatever you have available.
  - chris_wot 11y ago
    How is that different to a meeting? I'm not an agile practitioner, so apologies if I've missed something important.
    - mindcrime 11y ago
      The thing about the "standups" in Agile, (and Scrum in particular) is that they're supposed to be about intra-team communication. They're not status reports for management, etc. in particular. The goal is to share with your colleages what you're working on, what you're about to work on, what issues you're having, etc., in order to make sure everybody is on the same page and to eliminate misunderstandings. If you have a remote team and people can't meet F2F, you can accomplish the same end using something like I mentioned above. You lose a little something if people are in different time-zones because it makes the whole thing more asynchronous, but you do what you have to do to accommodate your circumstances. Remember, one of the tenets of the Agile Manifesto involves not having rigid adherence to strict ceremony for ceremony's sake (I'm paraphrasing a bit). "Figure out what works for your team, and do that" is kinda how I'd summarize the whole thing.
noname123 11y ago
Thanks julian_ for your explanation of the purpose behind morning standup and how they improve people's work life. I have to respectfully respond that I've not experienced such successful implementation of morning standup's (and btw not discounting at all your own very positive experience at all). I'll give you a few counter-examples just to offer the other perspective, Morning standup's used as a pulpit box by the tech lead or team members who like to talk; e.g., "I was working on this ticket yesterday, and I learned something new about Java and garbage collection, let me tell you guys..." (+5-10 minutes/per person) Morning standup's that become quick resolution and priority meetings for project managers for either early or late tickets; e.g., "Mr.PM, I finished this ticket; and now my queue is empty, I am not sure which ticket I should work on next ... Let me see, Mr.Developer, let me take a look at this large post-it board to figure out the priorities and we can go and forth and gauge your interest on several tickets I'll propose for you next..." (+5-10 minutes/per ticket) Morning standup's that combine two teams or force separate people who have been working on completely unrelated projects for quite some time but report to the same PM, listen to the unrelated details. You can imagine how eyes glaze over for people not involved at all on those projects every morning during stand up. (perceived waste of time). However I even agree that morning standup's are great for tech shops with very well-defined workflows and teams that has buy-in. But I also have to be respectfully honest and say that I haven't met any person who enjoy standup's except the project manager (but it might also just be a selection bias since I don't favor standup's, people who only hate standup's confides to likely-minded people aka "non-management material").
- nl 11y ago
  I'll give you a few counter-examples just to offer the other perspective So.. fix those problems? None of them are hard for a good Scrum master (or whoever has the job of keeping standup moving) to fix: "Ok, we'll take this offline. Moving on".
- julian_1 11y ago
  I very much understand that there needs to be developer buy-in, that management can and will attempt to derail the process, and that dominant personalities who don't understand their purpose may use them as a pulpit. I would still argue, that those particular issues will create worse outcomes under other management approaches. The distinguishing feature of scrum is that it is a bottom-up approach created by developers. itil and prince look ridiculous in comparison - and in terms of their rigidity in trying to formulate a set-of-rules that can be used to cover all software management processes. At the very least scrum is a baseline of principles, created by developers for developers that can be used to argue against unproductive intrusion by management.
douche 11y ago
The problem with standups is there's never a good time to schedule them. You can't schedule them for right at 9:00, because then half the team will miss it because they're dragging in, and if you schedule it for a little later on, like 10, 10:30, 11, you're basically destroying flow for the entire morning. Throw in the fact that they are completely useless. It's like Twitter - if you've only got such limited space to talk, you can't actually say anything worthwhile. As a general rule of thumb, if a meeting can be replaced by an asynchronous group chat or email, it doesn't need to happen.
- cultureulterior 11y ago
  You schedule them right before lunch, I've always felt
thatfrenchguy 11y ago
Aren't standups mostly a way for management to say "now the standups are at 9:30 and everyone have to be at work at 9:30" ? :-). Also it's clearly micromanagement: Why does everyone, including your boss, have to know what you did yesterday ?
- julian_1 11y ago
  > Why does everyone, including your boss, have to know what you did yesterday ? To identify blockers. If a member is blocked by some external factor over which they have no control, then the team leader is required to intervene/escalate to solve it to allow the member to progress. Formulating what you did yesterday, what the goal of work is today and identifing blockers in a few short sentences (literally 30s-1m) is less management overhead than anything else I have experienced. Certainly beats filling in reporting documents.

chris_wot 11y ago

How do you do standup with a remote workforce?

mindcrime 11y ago
Don't be overly literal, and use a conference call, Google Hangout, etc. If time zone differences prevent even that, do a "virtual standup" using email, wiki, blog, or whatever you have available.
- chris_wot 11y ago
  How is that different to a meeting? I'm not an agile practitioner, so apologies if I've missed something important.
  - mindcrime 11y ago
    The thing about the "standups" in Agile, (and Scrum in particular) is that they're supposed to be about intra-team communication. They're not status reports for management, etc. in particular. The goal is to share with your colleages what you're working on, what you're about to work on, what issues you're having, etc., in order to make sure everybody is on the same page and to eliminate misunderstandings. If you have a remote team and people can't meet F2F, you can accomplish the same end using something like I mentioned above. You lose a little something if people are in different time-zones because it makes the whole thing more asynchronous, but you do what you have to do to accommodate your circumstances. Remember, one of the tenets of the Agile Manifesto involves not having rigid adherence to strict ceremony for ceremony's sake (I'm paraphrasing a bit). "Figure out what works for your team, and do that" is kinda how I'd summarize the whole thing.

noname123 11y ago

Thanks julian_ for your explanation of the purpose behind morning standup and how they improve people's work life. I have to respectfully respond that I've not experienced such successful implementation of morning standup's (and btw not discounting at all your own very positive experience at all). I'll give you a few counter-examples just to offer the other perspective, Morning standup's used as a pulpit box by the tech lead or team members who like to talk; e.g., "I was working on this ticket yesterday, and I learned something new about Java and garbage collection, let me tell you guys..." (+5-10 minutes/per person) Morning standup's that become quick resolution and priority meetings for project managers for either early or late tickets; e.g., "Mr.PM, I finished this ticket; and now my queue is empty, I am not sure which ticket I should work on next ... Let me see, Mr.Developer, let me take a look at this large post-it board to figure out the priorities and we can go and forth and gauge your interest on several tickets I'll propose for you next..." (+5-10 minutes/per ticket) Morning standup's that combine two teams or force separate people who have been working on completely unrelated projects for quite some time but report to the same PM, listen to the unrelated details. You can imagine how eyes glaze over for people not involved at all on those projects every morning during stand up. (perceived waste of time). However I even agree that morning standup's are great for tech shops with very well-defined workflows and teams that has buy-in. But I also have to be respectfully honest and say that I haven't met any person who enjoy standup's except the project manager (but it might also just be a selection bias since I don't favor standup's, people who only hate standup's confides to likely-minded people aka "non-management material").

nl 11y ago
I'll give you a few counter-examples just to offer the other perspective So.. fix those problems? None of them are hard for a good Scrum master (or whoever has the job of keeping standup moving) to fix: "Ok, we'll take this offline. Moving on".
julian_1 11y ago
I very much understand that there needs to be developer buy-in, that management can and will attempt to derail the process, and that dominant personalities who don't understand their purpose may use them as a pulpit. I would still argue, that those particular issues will create worse outcomes under other management approaches. The distinguishing feature of scrum is that it is a bottom-up approach created by developers. itil and prince look ridiculous in comparison - and in terms of their rigidity in trying to formulate a set-of-rules that can be used to cover all software management processes. At the very least scrum is a baseline of principles, created by developers for developers that can be used to argue against unproductive intrusion by management.

douche 11y ago

The problem with standups is there's never a good time to schedule them. You can't schedule them for right at 9:00, because then half the team will miss it because they're dragging in, and if you schedule it for a little later on, like 10, 10:30, 11, you're basically destroying flow for the entire morning. Throw in the fact that they are completely useless. It's like Twitter - if you've only got such limited space to talk, you can't actually say anything worthwhile. As a general rule of thumb, if a meeting can be replaced by an asynchronous group chat or email, it doesn't need to happen.

cultureulterior 11y ago
You schedule them right before lunch, I've always felt

thatfrenchguy 11y ago

Aren't standups mostly a way for management to say "now the standups are at 9:30 and everyone have to be at work at 9:30" ? :-). Also it's clearly micromanagement: Why does everyone, including your boss, have to know what you did yesterday ?

julian_1 11y ago
> Why does everyone, including your boss, have to know what you did yesterday ? To identify blockers. If a member is blocked by some external factor over which they have no control, then the team leader is required to intervene/escalate to solve it to allow the member to progress. Formulating what you did yesterday, what the goal of work is today and identifing blockers in a few short sentences (literally 30s-1m) is less management overhead than anything else I have experienced. Certainly beats filling in reporting documents.