I hope it's okay to not believe in Scrum while doing it because that's what lots of us have been doing.
I'm a certified Scrum master. I should add: I am not a real Scrum master; I just took a course and got a certificate. Real Scrum masters are people who get paid to deal with all the crap that they get from developers and product owners and basically everyone in the organization, all while trying to keep their faith in the face of mounting evidence against Scrum's superiority. Still, as a senior software engineer on a Scrum team with my little certification, I feel somewhat qualified to comment on the subject, and I can safely say after five years that I really hope there's something better out there, because Scrum isn't good enough for what we've been trying to do. For starters:
Meetings. So many meetings. Meetings about meetings. Meetings where we're supposed to "groom" a backlog, where 2-3 people do all the talking and the rest of the team sits there waiting for it to be over. The daily standup, where nothing is said that a reasonably communicative, colocated team couldn't get across during a normal workday. The sprint review, where everyone complains and many people agree and yet nothing ever gets fixed. Meetings.
The assumption that presence is a worthy proxy for agreement. If you are in the room for the sprint kickoff, then you have "committed" to delivering some number of points. Also: the notion that this commitment is somehow valuable and worth buying with that time.
The farce of the "story point," a supposedly unitless measure that is only unitless until managers convert it to days, which is basically moments after the devs give their estimate. But don't try to pull back the curtain and express your wild, baseless guess in days--that's cheating!
User stories themselves. Does anyone care about the "as a" part? Or the "so that I can" part? How about since the "I want" part is ignored in favor of the acceptance criteria, why don't we just admit we only need those and call them what they are--specifications. Then we can stop torturing product owners with this requirement to write lists of requirements like they are a fun narrative.
The cult of Scrum. Using Scrum means you must deride both waterfall and Kanban, and questioning Scrum leads invariably to someone saying that you aren't doing it right. (If Scrum doesn't work for your organization, it's not because Scrum is imperfect--it's because your organization needs more training!) It is also apparently a one-way decision for nearly everyone; the cost of adopting Scrum is judged to be worth it, but the cost of abandoning it never seems to be. This in turn leads to a lot more people claiming that it must be worth the cost than are justified by their experience.
Estimates. I don't like them--does anyone?--not because they're hard, but because they're worthless. Most of the time, a story which is small enough to get done takes about a sprint to do, and we generally do a certain number of them each sprint. So instead of trying to estimate how long it will take, why not just say, "this is small enough to do," or that it isn't, and get to work, and let the magic of averages take care of forecasting? False estimate precision is expensive, both in terms of the cost of getting the number and in the cost of relying on it, and I personally think it's not worth it.
Mixed metaphors. What do "stories" and "grooming" have to do with rugby?
So these are some of the reasons I'd like to never do Scrum again. As a person who works in Scrum daily, however, and who (one more time, because it's funny) is at least in name an actual certified Scrum master, I find this exhausting. Why is it so empty and so hard and still so central to the work I do, which by the way is supposed to be made better by this framework? Why do I spend almost as much time feeding and nurturing this process as I do getting actual work done?
Now, what if we make the following tweaks:
...Hey look, we get something a bit like Kanban! Or Scrumban, or whatever you need to call it in order to have someone nod in acknowledgement when you talk about it with them. Now our meetings can be focused on things that matter--the code, and the features, rather than the process itself--and so we're taking fewer of these extremely expensive chunks of time and using them for things that are worth spending money on.
So that's it. Rant over. I don't believe in Scrum anymore. I believe in what it's trying to do, and that having a process is important. I just maybe disagree with the notion that slavish compliance to a process invented by someone who has never worked on your team is somehow above reconsideration. Cue people telling me we're not doing it right.