Reply to: Scrum

[fiisch]

Personally, I miss Waterfall, but then as a BA I find my role a bit confused in some Agile teams.

Standups descending into microanalysis of a particular issue, or a person talking step-by-step in minute detail about whatever task they did yesterday does my head in, but particularly in a remote working environment I can see the value, but they should be 15 minutes maximum. It's good to know at least at a high-level what others in the team are working on, and it's a motivator to make sure you have something to talk about in tomorrow's standup. Which reminds me, must invent something to cover for today's brainfog....

[vetran]

That's 3 sentences per person.

If it takes more than 3 sentences then take it "off line" e.g. do your own f$@£ing meeting afterwards with people who are interested in what you are going on about.

totally agree, do your poop get off the pot!

In waterfall there were idiots arguing over a pantone colour for an hour, that did allow me to read the paper when working remotely.

[vetran]

It's disguised employees like you that mean the rest of us have to endure these meetings.

Hardly the bigger ones I have attended are across 3-4 suppliers discussing huge projects. The Agile & standups are the only way to make it work.

Again if the SM is good and contributors do it well they are much less painful than not knowing what is going on.

[Smartie]

Like anything, it works if it's done well. By me.
Never going back to waterfall.

[SueEllen]

It's disguised employees like you that mean the rest of us have to endure these meetings.

That's 3 sentences per person.

If it takes more than 3 sentences then take it "off line" e.g. do your own f$@£ing meeting afterwards with people who are interested in what you are going on about.

[Fraidycat]

I say what I worked on the previous day, what I intend working on and any issues I have or extra information (like if I need to leave early).

It's disguised employees like you that mean the rest of us have to endure these meetings.

[MyUserName]

I find them useful.

I say what I worked on the previous day, what I intend working on and any issues I have or extra information (like if I need to leave early).

Everyone else does the same and we schedule any follow ups for after the meeting.

[vetran]

WTF?

That ain't a scrum team.

I have been in standups that big but the SM was very proficient, took about 30 mins.

We tended to pass up our summary to the lead for the Area before the meeting. He then spoke.

[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.

[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.

[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

[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.

[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.

[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.

[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