[twunde]

Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted.

A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent on these ceremonies (sprint planning 1 hr, sprint retro 1 hour, daily standup 15-30 minutes. Plus whatever prep is needed and the interruption time.) For many companies this is a 20% or more overhead that's mainly busywork because you still need the additional meetings to understand what you're working on.

[gedy]

This may sound like a no true Scotsman argument, when our company was trained by one of the scrum founders about 18 years ago, they were very clear that the daily standup was only for the team members, and the scrum master. (The scrum master could be a team member, and rotate btw). Managers were not allowed or invited to these. The only thing product managers and engineering managers would participate in and give feedback was in Sprint demos, and the beginning of planning meetings to answer any questions on upcoming stories.

At the time it was incredibly freeing and fixed a pretty awful and behind waterfall project. I was (briefly) at a startup a couple years ago that said they "did Scrum" and what a clusterfuck that was - all the managers meeting daily with devs to see if they were behind and scold them if they were. See ya.

[ta_1138]

But Managers as the center of the scrum is how many, many tech companies the outside world wouldn't call crappy run things. They also use Jira, mostly because they want reports that let people two or three levels up think they have any control over anything.

One of my least favorite standups was even worse than a ceremony for the manager: The manager and the Product representative were there in every single one, but they didn't actually pay any attention: Another 20+ minutes of "parking lot" would be added after the 5-10 minute process as they asked the team all the random questions they thought they needed, in which they also proved that they weren't actually paying attention to the actual updates, or the tickets, or anything. In practice, a sequence of 1:1 meetings where everyone was stuck watching, because after inquisition to one person, it'd come after another.

In practice, I don't think I've seen scrum run without a manager in standup, ever.

[LaGrange]

Your scrum master is management. It’s just a renamed PM.

I can run a very near standup when allowed to. I also think it’s a waste of time. Just send weekly updates to a group email, or something.

[wild_egg]

> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status.

The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.

[Aeolun]

It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers.

They also tend to make the stand-ups one hour long.

[repox]

> They also tend to make the stand-ups one hour long.

I'm Head of Development in a midsized SaaS company. Another team's PM went for paternity leave and I stepped in to lean in on any needs.

I discovered that the team of 10 people were using close to an hour a day on stand-up. A culture thing, apparently.

I joined he stand-up a few times, slimmed the scope of the conversation to roughly 10-15 minutes.

This worked for all three months of the PM's paternity leave.

PM returns, is pissed over the change and in less than two days, the stand-up is back to almost an hour a day.

[jghn]

It Depends.

I said in another post that I hated all the ceremonies, including standup. And it goes without saying that means long standups.

But, one team I was one, we had long ass standup and it was perfect. It was very dev-driven, we were facing hard problems, and that was our time of the day to really nerd out. The PM would get bored after about 15-20 minutes and then we'd be working out how to deal with the issues that faced us. Sure, it could have happened at any point of the day, but that was our designated time where we were all in the office (this was pre-pandemic)

[rerdavies]

That seems unproductive. You end up having a room full of people discussing problems that should be solved by one or two people outside of the standup. That's contrary to what a stand up meeting should be. Don't do that.

[gloryjulio]

That's the issue where the PM has so much power. In our company the engineering team dictates their process. They can do however they like as long as they ship the products on time.

[relaxing]

Why is the PM still employed?

Hasn’t the team all quit?

[geodel]

Because in real world people play with the hand they are dealt with. Team hasn't quit because there are no better jobs with empowered developers are waiting.

[icedchai]

The real question is why is the team putting up with this? They should be complaining about the PM and wasted time every chance they get, at the "retro", team meetings, and 1:1's... Complain, complain, complain.

[osigurdson]

I don't like long daily meetings, but there is essentially no value in the YTNB meeting either ("yesterday, today, no blockers") meeting either.

[lpapez]

> It may be explicitly stated, but I’ve never had a scrum meeting without all managers and project managers.

This, this, this and a thousand times this.

It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".

It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".

Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?

[Viliam1234]

I have seen teams actually do the Scrum-according-to-the-textbook, but those are rare. Most companies are just doing whatever their managers think is a good idea, and they call it "Scrum".

Ironically, the last time my team was doing Scrum-according-to-the-textbook, it was a decision of the developers... and then the higher management told us to stop, because the entire company decided to switch to "Scrum" (as in: endless meetings with managers present, no retrospective, but we call it "Scrum" because it sounds like we know what we are doing), so basically we had to abandon Scrum in the name of "Scrum".

My conclusion from this experience is that Scrum-according-to-the-textbook never happens as a top-down decision. The managers have strong ideas about how things are supposed to work, and they are unwilling to change their ideas, although they may agree to rename them to "Scrum".

I actually get the real-communism-has-never-been-tried vibe from people who say "scrum sucks, agile is the good idea". Scrum is simply what happens when Agile meets corporate reality. Make "agile" a popular buzzword among the managers... and soon you will see people complaining that agile in practice means endless meetings etc.

[RHSeeger]

> Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?

If your process to trim the hedges is much faster than normal, but also involves juggling chainsaws at the same time; it's possible your process is bad, because most people will fail to do it the way you've laid out.

(I'm agreeing with you, if that wasn't obvious... it's a pretty bad analogy, to be fair)

[wild_egg]

> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".

Scrum is a victim of semantic drift. The vast majority of people "doing scrum" have never read the guide and are just doing things that other people have told them is Scrum.

It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.

What people call Scrum isn't really Scrum. What people call REST isn't really REST. What people call DevOps isn't really DevOps.

People using the wrong word for something doesn't mean the original definition of the word is invalid.

It's fairly different from the Communism situation in that people discussing Communism are generally talking about the same concepts and the debate is whether or not they're feasible. With the other terms I used above, people are using the same words to talk about completely different concepts with different definitions.

[knallfrosch]

> It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.

Scrum contains so many pitfalls that it's inevitable to get it wrong. Oh, the Sprint Review is NOT a report to management? Please do tell me where this then happens instead. If a manager can attend a 1 hour meeting to summarize the 2-3 weeks that the sprint was about, it will be abused.

[jjav]

> People using the wrong word for something doesn't mean the original definition of the word is invalid.

It doesn't make the original definition invalid, but words mean what society uses them to mean, which changes over time.

So agile & scrum do in fact today mean constant status meetings, treating professional developers as mindless cogs and keep everyone in line with a constant stream of tickets chosen by someone else.

Perhaps it's not what it meant in some idealistic manifesto lost to history, but it is what it means to developers employed in the industry today.

[rerdavies]

Scrum (or agile) done wrong is a unimaginable nightmare (I actually do have first-hand experience with that). But, overwhelmingly, my experience with scrum has been nothing but sweetness and light. When it is done right, all the stress melts away. Seriously. Just an absolute joy.

Are those who have toxic experiences with scrum actually a majority, or are they just a vocal minority? I'm curious if there's any data on that.

[RHSeeger]

> People using the wrong word for something doesn't mean the original definition of the word is invalid.

Yeah, it's literally the worse thing you can do. I mean, not for the original definition of literally, but the new definition of literally, which is literally not literally, and actually literally in the dictionary with the definition of "not literally".

Just saying, at some point, the definition everyone uses becomes _the_ definition. And yes, I'm not a fan either.

[roenxi]

That similarity is superficial. It is observing that no ideology perfectly survives implementation - which is true, but there is no alternative option so it isn't a useful observation.

We don't have any successful countries that use communist ideologies because central planning is destructive and the abolishment of private property is catastrophic. Calling for communism is tantamount to wishing for death and destruction. The path to success through communism is something like China where they eventually learned to do the opposite of communism and got great results.

We do have lots of successful companies using Scrum. They hire Scrum masters. They see Scrum as adding value. The scrum ideal is generally a bit of a compass towards higher value add. So scrum as an ideology seems to be net-successful even if implemented wrong.

[carlmr]

>So scrum as an ideology seems to be net-successful even if implemented wrong.

How do you get to this conclusion? I haven't seen any implementation of scrum that didn't slow down development speed, due to unnecessary meetings and micromanagement.

This might be that I've only seen 8 or so "implementations". If there's any evidence that scrum is a key net positive I'd like to see it at this point.

Kanban IME can work well if the manager understood the core principle: Limit amount of concurrent work, use daily standup to prioritize work and unblock people hitting the multitasking limit.

Sadly this concept which is the core tenet of Kanban and can be explained in one sentence was still too much to grasp for some managers, but I've at least seen most Kanban implementations be either a net positive, or neutral.

I might be biased by my own experience, but I still need to see a Scrum implementation that doesn't grind productivity to a halt.

[roenxi]

The company isn't optimising for fastest development speed. They typically optimise for low variance, consistent value in support of existing processes.

Interestingly, if you want highest value then for software it is best to use a high-variance strategy. But that is never going to come out of a company large enough to need professional management because it is pointless to manage large numbers of people to a high variance strategy. Google is an interesting case study where they tried that and, by and large, flopped. It makes more sense to spin out separate companies VC-style. I assume programmers occasionally quit companies, build something and sell it back to the company at extortionate prices which would be the right way to do fast development.

That isn't to say professional management is bad - large companies need it. It is just a fact that large companies aren't good at development and something like scrum elevates them from total failure to unproductive but fumbling in a good direction.

[marcosdumay]

The funny thing is that "communism" is a highly overloaded term, with several very precise definitions, one of what is so successful that about every country currently implements and people that dismiss it are ignored and considered radical. (But then, nobody calls that one "communism" nowadays, the the people pushing the others will really hate you if you talk about it.)

While "scrum" is a proper name with a single definition that anybody can look that is absolutely not precise enough for anybody to follow. By definition you can't really do scrum right.

[vannevar]

>It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".

Yeah, that would be the correct response. If we were discussing communism, and you started complaining that under communism everyone has to stand on one leg and hop up and down, a communist would correctly point out that hopping on one leg is not communism.

>Well to both of those camps I say: if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?

This is like saying that exercise isn't useful because most people who attempt it don't stick with it. Doing actual scrum is hard (particularly for managers), so a lot of teams can't stick with it. That doesn't mean it isn't useful.

[kgeist]

>It's like when discussing communism with some diehard fans - when you point out the flaws, the response is always "well that wasn't real communism that's why it failed".

Nitpicking, but the Soviet Union, for example, never claimed they were already a communist state. They were the "Union of Soviet Socialist Republics", not "Communist Republics". Their idea was that, to have communism, you must have a transitional form of government first, "socialist government". The USSR even once had a motto, "we will build communism by 1980".

It's like if someone said they were following some other development process which would eventually lead them to Scrum. But no one does that and just calls it Scrum :)

[northzen]

But ones you are in company which does it right you start appreciate all good things it brings.

I haven't seen working communism though and never heard about it.

[the_other]

> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".

Well, you are.

Give this shitty process you’re being forced to follow some other name and stop blaming Scrum.

Do Scrum properly and you’ll see why it’s actually fairly good.

> if most attempts ended up implementing it "incorrectly" in the end, it's not a very useful framework to begin with then, is it?

You can’t say that as you’ve not actually done the thing.

The main problem is that most managers and senior company people feel like they want more control that scrum allows them to have, and their use their power to overrule it. That’s their problem and not the fault of the Scrum system.

You may be onto something with communism. It’s definitely not resiliant to the kinds of paychopaths that end up dictators for life. I wish I knew why. Probably something to do with threats of violence.

[rerdavies]

But on the other hand, capitalism is not resilient to the kind of psychopaths who end up becoming billionaires for life. So there is that.

[the_other]

It usually seems like that’s a feature, rather than a bug. Sadly.

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

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

[kgeist]

Our PM quit a month ago and now we have stand-ups without any managers. I think it made the developers more responsible and involved: every stand-up a new dev gets the role of a facilitator. Previously, it was a one-man show. The stand-ups have become slightly shorter, too.

2 years ago we had 1 hour long dailies because the team was too large. We split into 3 subteams, each has their own stand-up. Now it's down to 15 minutes max.

[oneshtein]

You never had a SCRUM meeting.

[shepherdjerred]

Surely you're exaggerating about a one hour standup?

[mid-kid]

I've been at companies where this was indeed the case.

[bboygravity]

The goal is always 15 minutes and the reality always (much) longer.

[dathinab]

I wich

while it's not quite as bad for us 30min are the norm and it spilling to 40 min not rare and that is with us trying to cut it short

but too many other things are conflicting with short dailies, mainly sure to company structure/size

[throw-the-towel]

Yeah, can't believe their standups are so short.

(I wish I was joking.)

[thayne]

In my experience, if the PM isn't part of it, the standup doesn't happen, because no one else cares that much. If someone gets stuck on something or needs help we just send a slack message, no need to wait for a fixed meeting.

[erik_seaberg]

That's hard to imagine. In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups). He always joins unless running late.

[oneshtein]

> In big tech it's the team manager who decides that standups should happen and when (maybe this is an expectation from higher-ups).

Then it's not a SCRUM process at all. Case solved.

https://scrumguides.org/scrum-guide.html#scrum-definition

https://scrumguides.org/scrum-guide.html#daily-scrum

[nottorp]

> Then it's not a SCRUM process at all. Case solved.

Yeah and communism also works in theory :)

[randomdata]

To be fair, it probably also works in practice, but by very definition post-scarcity is a necessary precondition. And that is still an ongoing effort that has never been realized. Granted, the UN has declared food to have achieved post-scarcity status so clear progress is being made, but we still have more work to do.

[nottorp]

> it probably also works in practice

I've lived the first 14 years of my life under the Romanian communist dictatorship so no.

Let's put it this way. If it's the property of the people it's not everyone's in practice, it's no one's. So you're free to slack, cheat and steal from your "property of the people", you're cheating "no one".

> post-scarcity is a necessary precondition

There is no post scarcity. The goalposts for scarcity just move up.

[bigstrat2003]

Be that as it may, if the scrum guide explicitly says they shouldn't then it isn't really fair to blame scrum for that.

Honestly, the recurring complaints with scrum, agile, etc basically boil down to this: shitty organizations can make any system miserable. People generally are blaming the intermediate cause (how we do scrum sucks) rather than the root cause (our company sucks and nothing would work).

[Aeolun]

We blame scrum because the framework provided makes it a lot easier for life to be miserable.

[rerdavies]

Compared to what?

You haven't truly experienced process misery until you've done a 4 year death march in a waterfall process.

[bboygravity]

Oh, the good old "the user is doing it wrong, the product is fine" with scrum being the product.

Can anybody (not PM/leader) give 1 example of a company where they saw scrum being done "correctly"?

crickets

I guess scrum is fine and people just don't know how to do it properly.

[albedoa]

Man, I agree with your specific criticism of the "No True Scotsman" refrain and with the larger criticisms of scrum, but this is an example of scrum prescribing X and companies doing !X, the literal opposite.

How could scrum, the product, possibly be to blame for that even if it sucks? Or, at what point is it reasonable to blame the PM/leader for actively and knowingly practicing !$scrum while pretending it's $scrum?

[randomdata]

Companies try prescribing X, but as developers have no reason to care X doesn't happen without strict oversight by management, thus leading to !X to keep them in line.

Is the gun with a 180º bend in the barrel, with a caution label that says "WARNING: Don't shoot yourself in the face", that sees everyone who tries using it shoot themselves in the face the user's fault, or could we say that the product is faulty?

If a product relies on weasel words to try and pass its flaws off as being the user's fault, at what point is the product to blame? If one person uses it wrong, perhaps you can say that one person was doing something out of the ordinary, but when every person uses it wrong...?

[rerdavies]

Me. I've worked in a company where scrum was being done properly. It is wonderful.

[jboggan]

Real scrum has never been tried!

[scotty79]

Right. So in one team I worked in, the team leader had to take notes during stand-ups of what everyone is doing to deliver them to managers so they can browse at their leisure.

[Lutger]

There are a lot of things better than scrum, but mostly these are all wrong ways to implement it.

Daily: should average at 10 min, 15 min is really the maximum. Including prep. So 5-15 min. No status updates! The daily is about getting people unstuck with their current tasks and quickly aligning on what to do next. If it is not useful for the team, the implementation is wrong. Doesn't mean it always has to be useful and interesting to you, there's a difference. Management stays out of the daily.

Sprint planning: the sprints are the compromise to management so we can have some sense of progress, so this is of course the one meeting that is useless to the team getting work done and can hamper productivity. Just make it quick.

Retro: you should do a retro about if you think the retro is useful and why/why not. If the team doesn't think it is, either change it until it works or make this the very last one. Management stays out of the retro. ("But are you then not doing scrum anymore?" "So what, save the pedantry for writing out the functional and technical requirements please")

Thing is, you do need to understand what you are working on, and it needs to be more or less the same as what your team members think they are working on. If you are 100% efficient at building the wrong thing, your 0% overhead amounts to exactly nothing, and the 80% efficient scrum team is infinitely more efficient. Though these extreme cases are usually a problem from higher up, without any way to align your work you will usually not be efficient. And if you are, then good for you, don't follow scrum like its some cult. But most teams need a little coordination.

Basically if anybody feels a meeting (or anything, really) is a waste of time, there is a problem that needs addressing. And the problem is not the feeling, but what is causing that sense of waste. Take it seriously, it is almost always signaling a flaw in the process. Learn how to talk about this in the retro and get to the bottom of it.

The retro is about debugging anything that isn't working optimal in the team. If you cannot find any bugs and fix them, then you are either perfect or just not good at debugging, and I know which one to bet one to be the most likely. One sure sign a team isn't very capable is when there is a lot of blaming involved. Usually external factors or tools get the blame, but in very dysfunctional teams people blame each other.

If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.

[marcosdumay]

The ages old "you are doing Agile wrong".

When nobody manages to do the thing right, then the thing isn't good. It doesn't matter what platonic ideal you hold for it.

[rerdavies]

But people DO do the thing right. As a loose guideline, I think you can reasonably infer that anyone who is telling "you are doing Agile wrong" has first-hand experience with an agile process that is working reasonably well. So take that as a starting point.

And the reason they are telling you that: because an agile process that is working well is like night and day to all the crazy processes that preceded it. When it works, it is amazing!

[lo_fye]

If I build a manual transmission car, and you insist on driving it like an automatic, it's not going to work for you, even though it's an amazing car. There are steps and processes that you must follow in order for the thing to work for you. If you don't, it won't. Simple as that.

Put another way, if you enter the olympics for breakdancing, and then just move your body around in a floppy way, you will not win the gold medal.

[haspok]

> The daily is about getting people unstuck with their current tasks

This I don't understand. Why do people need a daily to "get unstuck"? Are they not talking to each other? If I have a problem, I can proactively work on it, and contact whoever necessary. Unless you are very junior, this should not be a problem.

[geodel]

> If you work in a team that doesn't adequately address these problems and you have no power to change it, then it may be time to look for another job.

Huh, this is same for all employers I have known or worked at. Maybe on some distant planet it is done right.

[rolisz]

Sprint planning 1h? Lucky you. At the former employer that was 6h (so basically the whole day was wasted)

[usea]

I interviewed at a place whose sprint planning took a full week and was reportedly incredibly stressful. Customers participated. Their product was a website that agile teams used to track their process.