If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are.

This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.

No amount of "this is not the purpose of a standup" and "you're doing it wrong" can fix human nature. Management is mostly interested in progress and timelines, and will give unintentional (or not) feedback, even through body language, whenever a task is delayed or impacted in any way. They have some authority over team members' performance eval. Hence people will end up reporting to them no matter how hard you try. The only possible fix is to remove management or product from the standup, which is how it was originally supposed to be - but that seems unthinkable in the "agile at scale' format most companies have adopted today.

Also, the meetings are a bit useless for the developers -- they can just chat directly instead, and look in Trello/sth to see what the others are doing.

So the for oneself most meaningful thing to do, during the meetings, is to impress the managers / others listening?

Since the meetings barely hello with getting real work done anyway

Exactly. There's no point in blaming scrum for problems that are ultimately rooted in your corporate culture.... because those problems are going to (re)-appear no matter what methodology you adopt!

It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).

If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.

As a literature graduate, this made me laugh. Maybe literature courses are more leisurely stateside, but for me it was a book a week (not 4 to 6 weeks, as OP suggests). That was literally how classes were run.

And it was stupid for the reasons outlined. I remember my class on Ulysses mostly because a) I was acutely conscious of not having been fully keeping up in the 250 pages before the closing chapter and b) when I arrived at class it became clear after about 2 minutes that only I had finished it, because I had read it over the summer break because I was really keen on those bragging rights, but everyone else has tried to read it in one week, which is a doomed endeavour if ever there was one. It would have been a better experience for everyone concerned if more than one person had done the reading, but that was not realistic on the assumption that Ulysses can be polished off in the same time as The Power and the Glory.

The devil is in the definition. As an example, we have a tool that bootstraps a new Git repo and we're adding a feature that will include our company Rubocop config if it's a Ruby project. There is no reason on earth that this should take 3-5 developers a week to accomplish (never mind two). But it's a feature and it could be useful. And on top of all the other features, the tool is quite useful nowadays compared to the first extremely thin slice we did.

The trick is reducing what you're counting as a feature to the smallest thing that is actually worth bothering to use. It won't always fit into one or two weeks, especially if you're dependent on hardware manufacture, or beholden to the iOS store approval timetable or whatever. But for your line of business SAAS apps there's absolutely no technical reason why you can't do it; there may be human obstacles to doing so. (Hell, maybe we're all wrong and you shouldn't do it.)

It's as if somebody were to declare that house music died in 1990, with the only evidence being an analysis of records from that year, and everything subsequent to that year simply ignored.

That is not to say that there's nothing wrong in these scenes, but we then get to the sort of economic arguments he dismisses at the outset; eg, the effect of gentrification on night spots, and so on.

Things like this are never requirements, at least in the conventional sense of 'things the stakeholders ask for the software to do'. Nor should they be: it's our job as professionals to know how to do our work. I don't want a PM or sales rep worrying about the Liskov substitution principle (unless I'm working for code climate or something): it's a waste of their time.

Code cleanliness should make future changes easier. Of course, some 'cleaning' expeditions do the opposite, so there should still be code review etc.

I can remember the exact moment I fell in love with the style - I was traveling north on a streetcar on Spadina avenue in Toronto, back in 2005, and I caught a glimpse of the John P Robarts library, and it really did change my outlook. I grew up in Plymouth, which was blighted with poor examples of the style imposed on the town after heavy war damage. Much of the hatred of brutalism stems from the contemptuous attitude these planners and architects displayed to the pre-existing urban fabric.

I felt like the only one until about 5 years ago however, then suddenly there was this revival.

Now I'm more into medieval cathedrals, but it's worth noting that 'sophisticated' tastes were against them for centuries (hence the pejorative term Gothic). I don't think anything can be beautiful without irritating somebody ...

I don't think it's all that recent. The Barbican has been widely admired for a long time, say.