> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it.
No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a thing done. If and when it becomes clear that this feature is too complex, too big, or whatever, then it can be reestimated, or decomposed or reevaluated. It's supposed to be agile, not rigid and fragile.
Whats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business.
Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and that a sizeable (if not the majority) amount of developers loath working in SCRUM teams. So wouldn't we just be better off if the industry ditched SCRUM entirely?
The "do what makes sense" is limited because you have to ask questions to ascertain what makes sense.
Some questions are easy to answer, but many questions can only be answered by doing a thing that takes work. And Scrum gives you a framework that tries to put a limit on how much work goes by with no answers.
So it uses a simple schedule.
The team works for X weeks, working on implementing specific tasks. (Which in turn answer some questions.)
Then the team stops, reviews their progress on the larger product, and adjusts plans accordingly. Now "do what makes sense" has demonstrably advanced.
Working is not vacation. Sticking to a process is a hygiene factor which doesn't necessarily has to be fun but it makes it possible for companies to be properly managed.
That being said, stop complaining. If you can find room to complain, you surely can find room for improvement right? It might just be me, but everywhere I've worked I've never encountered a manager who isn't open to solid ideas for improvement.
I never said I wanted software engineering to be fun. I have worked on 4 different teams that followed Scrum and all four of those teams suffered from the same problems - low productivity and poor management. The most entertaining was a recent place I worked where we had a certified Scrum master who had been "trained" by one of the two founders of Scrum, when I joined I told him about some of the bad experiences I've had with Scrum and he said "yeah that annoys me, those teams are not really following scrum and so teams think that scrum is bad but really they are not doing it right". Of course in the months to come I realised that we ended up with the same exact issues I saw in previous teams. In contrast theses problems were just non-existent in teams that did not follow a set methodology.
Scrum is just not a good way to manage a team. I find Scrum to be a lot like religion - it means different things to different people but its evangelists always have a pre-prepared answer to every possible criticism, usually containing lots of jargon, buzzwords and double speak.
It's to keep everyone in the loop on what's happening in the codebase, and give people a time to ask for help on whatever's blocking them (so you hopefully get it sorted in a 10 second conversation instead of having to break their flow later to get help).
In the traditional waterfall model, you don't do what makes sense. The Plan has been set, and you have to find a way to do even the parts that don't make sense, because it will be a huge disaster if The Plan isn't complete.
Sometimes it's even the right development model! If you're building the control system for a new power plant, you'd better follow the agreed-on spec even if you realize it's not the best way to do things.
No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a thing done. If and when it becomes clear that this feature is too complex, too big, or whatever, then it can be reestimated, or decomposed or reevaluated. It's supposed to be agile, not rigid and fragile.