Scrum

[Fraidycat]

Anybody else despise daily scrum meetings?

[WTFH]

Yes

[TheDude]

A complete waste of time.

My current ones tend to descend into micro analysis of individual tickets and often overrun to an hour from the allocated 20 mins.

I switch off and listen for my name. I have told the scrum master the same but he loves the sound of his own voice.

[ladymuck]

So glad new clientCo doesn't do those. A weekly 1h meeting where everyone talks about what they're up to is all they do. They do that iterative deployment malarkey but no tickets, no daily stand ups, no "ceremonies". Just JFDI

[vetran]

A complete waste of time.

My current ones tend to descend into micro analysis of individual tickets and often overrun to an hour from the allocated 20 mins.

I switch off and listen for my name. I have told the scrum master the same but he loves the sound of his own voice.

Sadly that is my experience in the main.

I found asking participants to email a report to the scrum master before the scrum helps.
with Done, need help on, working on, todo as a slide with ETAs.
SM flicks through them as the dev talks. The scrum master should be fairly quiet unless there is an issue. Also gives the SM time to think.

SM should be able to get the data from JIRA if its up to date (the problem is it rarely is,) SM compare the two and remind them to keep JIRA up to date at first privately then publicly if needed.

[Snooky]

Anybody else despise daily scrum meetings?

I'd rather not have them but in the last couple of months we've forced the scrum master to recognise that they should only be for potential blockers / issues or things that immediately affect the whole team, rather than everyone spending ages talking about exactly the same pieces of work they talked about yesterday. So most of us just say "all going well, no blockers".

As a result, we've gone from 20-25 minutes drudgery to max 10 mins most days.

However, all the other Agile crap - refinement, planning, retros etc, still goes on and is mind-numbing.

[dsc]

I'd rather not have them but in the last couple of months we've forced the scrum master to recognise that they should only be for potential blockers / issues or things that immediately affect the whole team, rather than everyone spending ages talking about exactly the same pieces of work they talked about yesterday. So most of us just say "all going well, no blockers".[...]

Good on you, this is how a scrum should look like, who gives a feck what person X works on, if others are not even part of the task? bloody waste of time.

[vetran]

Good on you, this is how a scrum should look like, who gives a feck what person X works on, if others are not even part of the task? bloody waste of time.

Nope it isn't, from pretty much the horse's mouth.

https://www.atlassian.com/agile/scrum/standups

Recounting your successes or lack of it pushes people forward. I frequently think at 3pm, oh I am stuck or bored on that, let me finish a few tasks off quickly tonight so I can brag not hide in the standup.

Also knowing work is done and can be reviewed allows me to plan. If I intend to review stuff en bloc I can encourage others to complete the bloc early. e.g. there are some DB changes I need to bless / critique then me doing that early in the sprint is good, it gives my colleagues a chance to fix their mistakes. So if there are three parts of DB work in a sprint I will ask for them to be done in the first week if possible.

Looking at the mountain still to come means allocation issues are sorted quickly, either taking issues off someone struggling with something nasty or getting someone to mentor them. I will frequently take stuff off colleagues or jump in and help.

Blockers shouldn't be discussed in detail, the conversation should be :
Dev : "I need help"
SM "What is the difficulty?"
Dev "the nut is too tight"
SM : should say "who do you think can help you with this?"
Dev : "oh NAT or NLUK"
SM : "can either of you guys help? I Know NLUK is great with nuts"

Remember don't dump it all on Vetran

I normally do "round robin" but running the report allows you to "walk the board" at the same time. Forcing attendees to look at their personal queue pretty quickly gets the mis assigned jobs moved

[anonymouse]

20+ participants with a new scrum master, daily stand up was a sit down affair for 3 hours, with people coming and going, usually for a brew. Typical PS BS.

[SueEllen]

20+ participants with a new scrum master, daily stand up was a sit down affair for 3 hours, with people coming and going, usually for a brew. Typical PS BS.

WTF?

That ain't a scrum team.