TL;DR:
The repeating symptom here is that your team has no autonomy to make decisions and talk freely, which is crucial to actually being a team. I have seen that in two scenarios: one is that you are actually not given autonomy by management. You have tried but were punished. And the other one is that you are so afraid of showing "weakness" that you don't try to be a team out of fear. The combination, where little mistakes by management (they are new to this, too) are blown out of proportion by fear mongering, is probably the worst.
The only way to find out is to take the risk and be open and transparent yourself, even if that might feel weak and vulnerable if you are not used to it. You will either get pushed back or you will enjoy a team. Even the push back might not be management, it might be other colleagues being held up in their old every-man-for-themselves, if-you-cannot-make-it-fake-it patterns that served them well under dictatorial management.
If you try to form a good team and fail due to management or colleagues, then there is no other way than to fire them and find a job where you can form a team.
Or hunker down and endure. But I urge you to find a team. It's really hard to describe how good a good team is, kinda like how you cannot really describe how a good pizza tastes to people who only ever had that frozen stuff. But I promise you it's worth it, even if I fail to properly describe it. Don't give up on pizza just because your current company only serves the crappy cheap one's. It's not the concept of pizza that's bad.
Long explanation
(Sorry, got carried away)
Well, Scrum operates on the idea that there is a time and place to inspect and adapt. Talk about what went well and what did not and improve it for the next sprint. This is called the Retrospective. So the obvious by the book answer would be "bring it up in the retrospective". The fact that you did not mention the retrospective makes me think you are not even doing "Dark Scrum" (as I understand it, keep to all the rules on the surface but pervert them) but you are just doing "Dark". Because the retrospective is in the book and not having it means it should officially not be called Scrum, "Dark" or otherwise.
I'll go through your list, compare with what should happen and in the end show what you could do.
The sprint coming first. We always deliver the sprint no matter what has happened (including the week we fled our offices and had to set up VPNs for the company) with the idea of just using the bug tracker to compensate.
The Scrum way would be to have a definition of done. A quality standard by the team and for the team so you cannot just sacrifice quality into oblivion. This is so basic that I don't know how or why you can start a single story without having it. If you don't define "done", how can you ever say you are done? In the whole process of Scrum the one thing that could be seen as "bad" in measuring a team as a whole is the number of bugs. If the ticket status is more important than the actual result, then that is a problem outside of Scrum. Tickets and status have existed long before this 30 year old agile hipster idea of teamwork. If nobody in your company brings up the number of bugs you produce as a problem or at least a measurement that has to go down, then that is the root problem, not your process. Yes, your process right now produces bugs, but Scrum is about inspect and adapt. Look at the system, see it produces too many bugs and then change the system. This is not your job and likely you are in no position to change your companies management. In this specific case, the only option you have is to fire the management (aka change the company).
Picking easy tasks so the Scrum Master doesnt interrogate us for "not producing" when we report to them during standup each day.
Well, this one is a sign of a core problem. What you need to find out is whether that problem lies with you individually (as well as your supposed team mates) or if it actually is a problem with your company culture. I had the privilege of seeing multiple teams switch to Scrum simultaneously under the same manager and workplace culture and I have seen teams thrive and enjoy and I have seen other teams falter and fail. So it's not always external, every individual has to be willing to take part in Scrum. The core idea of Scrum are the agile values. Teamwork is essential and there is no teamwork if you cannot be open with each other. The daily standup is to coordinate the team. To coordinate the team, everybody needs to know where the team stands and that can only be found out if each member tells the others where they are on their tasks. This can go two way: in a good team, there is no problem at all. You just tell the truth. Yes, maybe you made mistakes. Maybe you need help. Maybe not? Maybe you just hit a wall with your approach to the problem and will try another today. You can openly say so. Nobody will criticize you. What is important is to know where you are and maybe offer help. In a good team the Scrum master can be a silent observer, because the team will tell. And then there is "teams". Where people aren't a team. Where people are afraid to tell the truth. Where people are afraid to say they need help. Where people think they will be punished if they admit a "weakness". Where the Scrum master needs to "interrogate" people because they do not yield the required information freely out of fear of the consequences. And here is the kicker: I have seen groups where those fears were founded in reality. Because there was a manager present and they would use this team internal feedback against you. There, again, you need to fire management. You have no power to change this. But I have also seen teams where those fears where either completely unfounded or influenced by shadows from the far past. Where people where afraid of "consequences" that only happened in their mind. They never tried to be open, thinking that showing a weakness would somehow diminish their "Senior" status. First, it does not. Asking for help is something I expect from a Senior. It's a sign that you know what you are doing, you know your work and your personal limits. Only stupid or naive people think they can do everything on their own. And secondly, they never tried. Some where too afraid because a manager 10 years ago had treated them badly, some where not confident enough to admit they are not perfect. So you need to find out: as your standups are a red flag of not being an actual team: is that the environment, or is it you. Did you actually try to be a team and were you actually treated unfairly, or did you not even try? Because if being open and asking for help is punished in your company, again, sorry, you need to fire management. But maybe it's not. Maybe it's you. Maybe you need to risk it and find out. Because what you wrote is perfectly explainable with a good workplace culture but people that are afraid because of low self-confidence or bad prior experiences. You need hard evidence, not hearsay and fantasies. So try. Be open. Show a weakness. Worst case is you find out you need to fire management. But as that is already the current status, it seems it's relatively low risk after all.
The part about tickets becoming architecture. A lot of this is just that developers are straightjacketed by the tickets because they want to get them done each day so they just build and then bolt on to what exists so nobody wants to spend time figuring out a how before doing.
This is a straight up developer problem. Scrum is all about building an empowered team. And if the team says we need an architecture meeting that produces guidelines for our software, then that is the case. Who would say "no"? Who defines what the software looks like internally? No Scrum Master or Product Owner is ever going to tell you whether this is a service based architecture, whether is uses proper dependency injection, whether it has unit tests or not. The developers decide what the software looks like. And if they don't, because they are afraid of the next daily, they are doing it wrong. But what is the fix? Well, fix the whole team as above. You should never be afraid to go to the daily and say "yesterday I made a diagram on how our service will communicate after our current story, I have some questions about the database for Alice, maybe we can talk after the meeting, and if it's as expected, I will finalize it today and hopefully start implementing it tomorrow. I'll update our wiki later and send you all a link to the updated pages.". Refer to my part about the daily if the developers think this is not possible in their team.
The talk about focusing on velocity above everything is very relatable. We are pressured to keep our "commitment" to "ever higher velocity."
First, who made this commitment? It's stupid. It's not Scrum. You don't commit to increasing velocity and even he word "commit" in referring to work items in a sprint has been replaced 7 years ago. Find out who is actually doing this and ask them why. Is there a fix? Well, as a quick fix, ignore them? Don't play their games.
My team conspires to boost the velocity number by not qaing all that creatively which ensures that people can meet the daily deadline. It is a controlled infinite defects method thing.
Wow. Your team sure is not lazy enough. All it needs to increase velocity is estimating higher. You got a 3 point story. Great. I estimate another, roughly equal story at 20 points next time. Boom. Instant velocity boost. Improved my work performance by almost six times. Do I get a raise? This alone should show that velocity is not a measurement of anything but how the next sprint will go, because it is not an absolute number one could measure. It's made up points. If you need to produce more, make them up. Problem solved. This alone, the fact that you can make up your own velocity, should show people that it's not a good measurement.
Same with the endlessly being a junior developer as you never work on anything larger than a day long task.
I do not understand this one. Apart from the fact that breaking stories into day-long tasks is not Scrum, but a practice that people use with Scrum and other Frameworks (and for example my team adapted, inspected, found it pointless and adapted again to drop it), I don't see how it involves the seniority of the task. If the task is to implement federated security for your micro services, surely that task gets not less tricky if you do it in 15 daily tasks. You could argue that you do it in 15 daily tasks anyway because that is how work life works, you work a day, you go home, you come back, work a day, go home... the point of seniority is not to grab the task and vanish into a dark basement, hacking away planlessly at your keyboard until a solution mystically appears. You do the very same thing. You think about what steps to take. Then you take the steps one after another, day by day. For our team, we found it pointless to note those steps down, but having a plan of how to tackle a problem instead of blindly stumbling into it is a definition of being senior. I don't see how you arrive at the idea that having a good plan on how to tackle a problem makes you a junior. Also, who creates those daylong tasks? That's a developer, right? So even in the worst case scenario, some developer did get to play senior, the planned tasks did not just come from high heaven.
