Sort of a whirlwind tour of all the misconceptions the average dev might have about agile/scrum. Yet again, here goes. - The problem here is dogmatism, both y

Sort of a whirlwind tour of all the misconceptions the average dev might have about agile/scrum. Yet again, here goes. - The problem here is dogmatism, both yours and whoever is "doing scrum" to you. There is no Scotsman! He ran away. That is, it's only if you're insisting whether you're doing it right or wrong can you start to have the conversation about what is right or wrong. Your premise is invalid. - Confusion over terms. These things are much better represented mentally by the image of a bookstore. You arrive at a bookstore and want to read up on some stuff related to teams and planning. Cool! There's a scrum section, just next to the agile section. Guess what? The books don't all agree with one another, and that's fine. It's a marketing term, a place to go for ideas. It gets worse after that, with dysfunctions of estimating and so forth, but you start out with your head in the wrong place, whether you love X or hate X, it's not going to end well. Do stuff you like, make stuff people want, and get stuff done. If that's not working for you, here's some titles of sections in the bookstore where you might want to read some other stuff. There are other sections. If you find some sections that have cool stuff, let me know. I might could learn some neat stuff I might use one day. That's it. It's nothing more complicated than that. You can go to those sections and learn a whole bunch of stuff about various problems you might have. Try some if you like. Or not. What you can't do is go to that section and pull some book out as if it were a recipe and then "implement" it on a team or organization. It doesn't work like that, and it's never going to work like that, whether your view is from the top or bottom of an org. You're doing it backwards. It hurts when you do that? Ok. So stop doing it that way.