3 ms·

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

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.
julian_1 11y ago
> Morning standup's that become quick resolution and priority meetings for project managers for either early or late tickets; How it works for us :- In our standups, no questions are allowed, and no dialog. If PMs and a team-member need to convene it's strictly after/outside standup so no-one else's time is wasted. If something urgent (production server is down) needs to be prioritized, it goes on the board as a VIT ticket. No team member is ever compelled to interrupt what they are currently working on to pick up a VIT ticket. This forces management to correctly estimate the value of automated fail-over, redundancy, one-click deployment/roll-back systems etc.

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.

julian_1 11y ago

> Morning standup's that become quick resolution and priority meetings for project managers for either early or late tickets; How it works for us :- In our standups, no questions are allowed, and no dialog. If PMs and a team-member need to convene it's strictly after/outside standup so no-one else's time is wasted. If something urgent (production server is down) needs to be prioritized, it goes on the board as a VIT ticket. No team member is ever compelled to interrupt what they are currently working on to pick up a VIT ticket. This forces management to correctly estimate the value of automated fail-over, redundancy, one-click deployment/roll-back systems etc.