> I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups.
I haven’t come into an organization in the past 15 or so years which wasn’t using _some_ form of Agile (generally Scrum). It’s fairly likely anyone who has started their career in software within that timeframe may never have experienced how things were done in the past.
That said, there is certainly always room to improve, which is a critical piece I see teams often miss in Scrum. The two-week cycle isn’t just about planning and doing whatever it takes to hit the commitment. It’s about a) the business having a cycle they can plan to if priorities change and b) the team having a regular feedback loop they can use to help understand where they are doing well and where they aren’t.
Missing a sprint commitment is fine. Missing the commitment for multiple sprints in a row means something is going wrong. This is an opportunity to learn and improve, and the sprint retrospective at the end is as important if not more so than the planning meetings.
And then make time in the sprint to implement improvements in the process, tech, whatever is needed. We use 20% of the sprint time as a rule on this, and move that up and down periodically as needed.