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.
They also tend to make the stand-ups one hour long.
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
(I wish I was joking.)
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.
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)
Hasn’t the team all quit?
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?
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.
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.
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.
Where's the evidence for this? I kind of agree on big corporate not being able to achieve great development speed. But they had a system before scrum, and I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.
> I've yet to see scrum not completely destroying every metric of development achievement, whether it's throughput, latency or iteration speed.
It is too hard to argue from vague anecdotes, so I am resisting the urge to try. However, I will say that if that is a demonstrable thing and there was no upside then it would be surprising that scrum sticks as well as it does.
Not necessarily. It's well known that there are many psychological biases in favor of keeping the status quo. Whether it's the sunk cost fallacy, the escalation of commitment or the endowment effect.
Humans tend to stick with bad decisions way longer than rational.
https://en.wikipedia.org/wiki/Escalation_of_commitment#/sear...
I think the problem here is we've had a huge trend in switching to scrum, but then people stick with failed scrum because it's the new status quo. Switching back to waterfall can't be sold by consultants. Even if it would help.
It's demonstratable: https://www.theregister.com/2024/06/05/agile_failure_rates/
> and there was no upside
I'd go on a sarcastic rant here, but it's hard to stop myself. Don't read further if exaggerations upset you.
Sure, there are upsides, but they are hardly benefitting software engineering speed, quality, stability and developer happiness. The biggest upsides are for management:
- keeping the engineers under tight control by one of their business types (PO)
- making sure long-term thinking (like "what am I doing in this company") is suppressed by having a horizon of only 2 weeks in which you are supposed to give all you have to hit an arbitrary deadline. And then you start again! /s
- scrum has the beautiful effect of making engineers feeling either like kindergartners:
1. what did you do yesterday, Timmy? (standup)
2. Let's play with some cards, kids (planning poker)
3. Let's review what we learned last two weeks, children, and let's see what progress you made on your bean drawings (retros and demos)
How can you want a salary increase or question big man POs decisions, when you've just been acting like a kid for the last two weeks? Don't get me wrong, I do see the benefit of retros, demos, and some kind of planning and sync, but the way scrum just dumps it on you and prescribes you how to do it is just humiliating. Adults can sync, plan, retrospect and demonstrate what they did on their own volition and don't need some framework to tell them when and how, and two parental figures (the PO and Scrum master) to tell them what to do and when.
> The evidence is in the company choosing scrum then sticking with it. They believe it helped.
Many people also believe the Earth is flat and are sticking with that belief.
I think you just provided me with a small epiphany...
Another great point. The overhead is insane. 2 people that don't directly contribute work output per team.
It is another great point. But it is another great point about how the process in your organization could be improved. Nothing says you have to have two parental figures.
And why on earth would you have a dedicated scrum master?! It's just not a job that should be requiring that much labor. Just have one part-time scrum master in the entire company who periodically audits and coaches teams who aren't doing the process right. Or coaches teams through the initial learning curve, as required.
In scrum and non-scrum processes that I have worked with, the PO comes from the marketing/sales team. On the theory that, if anyone has the pulse of what customers in aggregate actually want, it's going to be them. Also a part time job. But essential for injecting some realistic sense of "value" into the development planning equation. The direct contribution of a good PO is to make sure that the team is contributing work output to features that customers actually want. A good PO contributes enormously to team productivity.
At most places I worked, having a dedicated Scrum Master on the project was the norm.
Yet another case of "it's not Scrum's fault everyone is doing it wrong".
We absolutely learned something since the 90s that was beneficial. Corporative software projects now have about a two times higher chance of success than they had back then.
Also, we almost certainly learned that thing from Agile. There is no other credible source.
But the article has a clear point that places where people say they are practicing Agile has an even lower success rate than the overall one from the 90s. So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.
Yes, software engineering has evolved, but to attribute its successes to the methodology used is like attributing higher cancer survival rates to better hospital management. In reality, it's due to the availability of better drugs, more understanding, and a lot of R&D, and it has 0 to do with management. Same with software engineering: we use better tooling, libraries, hardware is more commodified, and a lot of things we don't have to do ourselves. All things that have nothing to do with the methodology.
> So it seems that the actual lesson from the Agile manifest was only learned by the people who don't claim to practice it.
No methodology/manifest and no amount of management can compete with smart, qualified adult people being invested in their craft, and having autonomy and ownership on what they are building. The projects that succeeded are projects having those people, regardless of the methodology. In a way, people succeeded despite Agile, not because of 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.
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.
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.
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.
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.
I agree. The issue is that I have literally never seen it done "right". It doesn't practically matter what agile is theoretically supposed to be, it matters what it actually is.
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.
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.
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.
I haven't seen working communism though and never heard about it.
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.
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 :)
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)
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?
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.
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
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).
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.
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.
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.
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.
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).
You haven't truly experienced process misery until you've done a 4 year death march in a waterfall process.
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.
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?
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...?
Then it's not a SCRUM process at all. Case solved.
Yeah and communism also works in theory :)
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.
That doesn't make any sense. Communism's defining feature is that there is no longer a state. How can you recognize Romania, and especially a Romanian dictatorship, without there being a state?
Perhaps you're confusing communism with rule by the Communist Party?
- Communism is a work of science fiction that imagines what life is like in a post-scarcity world – indeed, science fiction that some people would like to see become reality. Star Trek is a more modern adaptation on the same basic idea, which you may be more familiar with.
- The Communist Party is a political group that, at least on paper, is focused on achieving post-scarcity through capturing the means of production. It was once theorized in a certain Manifesto about Communism that post-scarcity would not be achievable through capitalism as the capitalists would set up barriers to seeing it through, and that the way to protect against that was the bring the means of production into social hands. Hence why the Communist Party is so-named.
But that would be like saying that democracy doesn't work because you don't like what the political party known as the Democrats are doing in the USA. Or that workers don't work because you don't like what the National Socialist German Workers' Party (Nazi) did.
> There is no post scarcity. The goalposts for scarcity just move up.
Perhaps. But it remains that communism cannot exist without having achieved post-scarcity. How could it?
Seriously? Who takes all the resources and allocates them "according to each person's need" then? :)
> But it remains that communism cannot exist without having achieved post-scarcity. How could it?
All the scarce resources are being stolen^H^H^Hshared in common.
Communism predates the idea of post scarcity by a hundred years or more AFAIK.
Yes. Communism's key attributes are that it is classless, stateless, and moneyless.
> Who takes all the resources and allocates them "according to each person's need" then?
We'd need to know more about how post-scarcity is achieved in order to answer that question. Star Trek says the replicator is responsible, although that seems unlikely outside of the imagined Star Trek universe. Based on what we can see today, I'd guess robots. But this is all speculative as we don't really know what post-scarcity truly looks like, or if it is achievable at all.
> Communism predates the idea of post scarcity by a hundred years or more AFAIK.
Are you referring to what is oft referred to as primitive communism?
Although I find it hard to believe that humans have ever not thought about post-scarcity. It seems like the first thought/dream anyone would have when first faced with scarcity constraints.
Did communist utopians realize it doesn't work so now they're adding "post scarcity" to it to make it work?
Will they add "AI" next?
Edit: "Based on what we can see today, I'd guess robots." Oh yea, "AI" is next.
Did TV fanatics realize that Star Trek doesn't work? What does this even mean? Communism isn't something real, it is a work of science fiction that details an imagined world after post-scarcity. Always has been, probably always will be.
Hell, even if we actually do reach post-scarcity some day, the chances of going the communism route are about as likely as us going the Star Trek route. Reality has a way of turning out quite different to what you envision. There is effectively no chance of communism becoming more than science fiction.
Is that what you mean by "doesn't work"? That it will never be more than science fiction? In the same way aliens, time travel, etc. "don't work"? Fair, I suppose, but that makes your communism obsession rather bizarre.
> "Based on what we can see today, I'd guess robots." Oh yea, "AI" is next.
How do you foresee AI being useful? Robotics is by and large how we've achieved post-scarcity in food production. If we were to achieve full-on post-scarcity, chances are we would do so by finding additional robot applications. We're not that creative as species. But who knows.
I suppose in your modern communism they'll blame the "AI".
If communism ever is realized as more than science fiction, it will almost certainly be because of the USA's efforts. There is no chance Cuba will get us there. Of course, their official claim of seeking post-scarcity is only for pretend to keep up political appearances. The USA, in contrast, is actually trying. You might say ironically, but I'd say that Marx just got it wrong and that capitalism, not socialism, is the most likely path to communism.