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