Me: 5-6 years doing Scrum (more or less) at 3 companies. 25 total years doing software dev. First: Agile "Agile" has no meaning on its own to me. Typical

Me: 5-6 years doing Scrum (more or less) at 3 companies. 25 total years doing software dev. First: Agile "Agile" has no meaning on its own to me. Typically an ad-hoc free for all with a Kanban style board in my experience. It's a way for companies with no process to feel like they have a process. I'm not saying this is wrong but since the term is so amorphous I feel it is impossible to discuss. To me Scrum is a specific flavor of "agile" with some specific ceremony and convention. I will be talking about Scrum below unless otherwise noted. TL;DR -- I think one's opinions of Scrum largely depend on how good or bad one's experiences outside of Scrum are. If you have been on amazing and healthy teams, then Scrum surely seems like a bunch of unnecessary bullshit. Sadly I'm not in that boat, so I have found Scrum to be a net gain. Overcomplication, with an entire industry of trainers, books, and seminars evolving around it [...] sprint planning seems overly complex For most engineering efforts, we're going to need some meetings, planning, review, and collaboration no matter what -- right? At some point we have to herd the cats. My experience is that Scrum does not represent an increase in ceremony/meetings relative to the somewhat chaotic and meeting-filled reality I have experienced outside of Scrum. I don't think that Scrum is perfect, but I appreciate that it is a somewhat standardized process. It's like MVC or Git or 90% of the other shit we use. It's not perfect but there is value in a standard thing that is more or less understood by everybody in the industry. Autonomy. I'm not sold on this either. I find Scrum almost entirely orthogonal to developer autonomy. I have generally found that management/product rams shit down developers' throats no matter what. Scrum doesn't help here but I don't find that it hurts. One small exception: if management has bought into these concepts, story points + sprint velocity do provide a somewhat objective or quantitative way to measure developer work. Again, I'm comparing this to the alternative, which is "the industry has never figured out a way to measure this." If management has bought into the concept, it can provide a way to push back against their demands when it comes to deadlines and scheduling work. Thus, some small boon to autonomy. we want a drama-free, predictable, and coordinated work environment where we're respected Well, Scrum adds to the predictability for sure IMO. The other attributes... well, they have not typically existed in this industry anyway IME. If so, why and how do you make [sprints] work? A common failure in agile/Scrum/sprints whatever is pressuring developers to estimate work (story points, whatever) before they have had a chance to really explore what needs to be done. For example, adding a feature to some legacy code the developer isn't familiar with... will it be easy or hard? No way to know until they've done some spelunking and maybe even an initial POC. It's actually a fundamental concept in Scrum and I guess "agile" in general. However, I see teams absolutely dooming themselves with a failure to understand it all the time. https://www.agile-academy.com/en/agile-dictionary/spike/ https://www.agile-academy.com/en/agile-dictionary/spike/