[quartesixte]

As someone who works in a hard-tech startup, where daily standups in production manufacturing teams are part of the daily culture.

1) Anything longer than 15 minutes is insane 2) What do you even talk about for an hour? 3) Why do you even do standups for design work? What "blockers" could you possibly have that require daily, 15 minute tagups with the entire crew?

[marcosdumay]

On #2, nothing. People stay an hour trying to look busy because somebody on the meeting expect them to be busy and the meeting to be important. So they spend an hour talking about nothing.

On #3, blockers exist more on design than on operation. But the idea of a daily meeting to solve blockers is crazy-stupid. Imagine if operations did this, every time somebody's work get a wrong input, you'd stop their line until the next morning. That's why operations dailies aren't about blockers, and instead about information sharing. But design work doesn't have separate teams that need to share information, so they invent a bullshit reason to still have the meeting.

[kgeist]

>What do you even talk about for an hour?

We once had 1 hour long standups. The reasons were:

1) large team

2) many devs loved to go into detail about their work, and no one stopped them

3) the expectation was that a standup must be about describing what you did yesterday, in detail

What we did:

1) split the team into subteams where each team has their own standup (down to 5-15 min)

2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"

3) now the expectation is that a standup should be about checking the project status and if there are any blockers, and that's it, you don't have to recount your whole yesterday in great detail

[RHSeeger]

> 2) the standup's facilitator now stops devs from going into too much detail, "you guys can discuss it further after the standup"

I said this in another comment, but a standup I'm part of tables these until the end of the call; and then anyone not involved in that conversation can drop off. It seems like a reasonable compromise to balance the need to get people together to discuss something against the need to not keep people tied up. It helps mitigate the issue of people not wanting to plan a meeting to just "talk about" something (when that's actually what is needed).

[quartesixte]

So I think one thing that seems to pop up in people’s anecdotes is “well someone wanted to just talk about what they did yesterday.”

Which I suspect comes from the manager/PM going “so what’d you do yesterday?”

I’ve been taught, and I teach others, that in the standup you drive the questions. Usually along this framework:

1) I assigned you Task A yesterday. Did you finish Task A?

2) If yes, awesome. I have Task B for you. Or, go help Bob with Task C.

3) If no, cool. Why? What happened? Is there anyone in this circle that can help you? How can I help you.

4) Open Ended Questions/Comments that we need to circle up on later

5) General Announcements

15 - 30 minutes depending on the size of the team, scope complexity, etc. No one should be talking for more than two minutes. If whatever they need takes longer than 2 minutes, that’s taken offline and a flag something is wrong.

If you’re going to treat the software development like a factory, you must assign and manage work like a factory.

If you’re going to treat it like magazine publishing, you must assign and manage work like a publication.

Pick one. And stop having hour long standups y’all are crazy.

[haspok]

> If you’re going to treat the software development like a factory, you must assign and manage work like a factory.

What you described above is more like kindergarten, which is why any sufficiently seasoned developer hates Scrum with all the passion they have. It is mostly belittling, humiliating, and not even very productive at the end.

Interestingly, Scrum almost always ends up like being in the kindergarten, instead of addressing the real pain points, as it should be (eg. involve the business in the development process). But that takes real effort, which is hard, and therefore no PM or manager is interested in.

[quartesixte]

>What you described above is more like kindergarten

You ever try organizing and managing the work of multiple skilled tradesmen that feed into a single integrated product on tight deadlines? Do you know what works really well in that kind of environment?

Telling people what to do and then checking in on them to see if they’re doing well.

Is this kindergarten? I don’t remember being a skilled tradesmen working on building components for complex assemblies on tight deadlines in Kindergarten.

I concede that I am unfamiliar with what a normal “scrum” session looks like outside of what is said in the Agile manifesto and the many anecdotes floating around. I do know that Scrum took a lot of cues from TPS/Lean of the 80s and tried to feed it to Software.

And as far as I can see, it’s not working because the profession and the products do not fit this factory model.

What everyone seems to yearn for seems to match more closely to the model followed by magazines and other such publications. Product Management the profession mirrors more the Editor than the Production Manager, SWEs mirror writers/editors-at-large, etc.

Self respecting writers in any newsroom would balk at being subjected to daily scrums that take away from precious research/writing time. And to put some kind of regular pace on progress, metrics, etc. to what really is very bursty, deep focus work is also ridiculous. Whether it takes you 5 hours or 5 days to write the piece, so long as it is of quality and meets the deadline what does it matter. And even if you miss the deadline, you could alway be slotted into the next issue unless the piece was a cornerstone piece to the issue, in which case a good editor would have assigned it with ample time or given it to the best writer on the roster.

Hell I like this analogy. Might spend more time thinking about it and talking to SWE friends about it. Feel free to expand. Maybe this will free everyone from the shackles of Scrum.

[RHSeeger]

One of the projects I'm on has a standup every day, and it generally lasts less than 15 minutes. Sometimes, a topic comes up that needs more discuss and it's tabled until the end of the call. At the end, anyone that doesn't need (or want, sometimes it's useful to just listen in) to be part of the additional discussion drops off and it turns from standup to technical discussion. It works pretty well.