At the risk of being reductive - yes, it’s fine. Most of the complaints you see are a result of people basing their opinions on whatever broken processes they h

At the risk of being reductive - yes, it’s fine. Most of the complaints you see are a result of people basing their opinions on whatever broken processes they have at their broken company which are kind of semi-agile, and this applies to the caricature you paint as well. You cannot fix bad management or ineffective teams by applying a methodology, and many companies have both broken management and broken teams. Sprinkling “Scrum” on top won’t fix that, and there’s a widespread failure to realise that the symptoms people see are not the result of Scrum or Agile or anything else, but would exist regardless of the development process being used. So, for example of how I find this working well: total process overhead for my teams is about two hours a week, averaged over the two-week sprint. This incorporates all of the planning, reviews, and daily standups. Outside of rare or one-off events like project kickoffs, post-mortems, or long-term roadmap discussions there are no other process-related meetings. Daily standups are very much a “good morning” meeting to say hello, discuss plans for the day, and make arrangements with anyone who wants to team up or get some input from others. 10 minutes maximum. Development team and product owner only. Fortnightly review meetings are the chance for all of the teams to get together and briefly talk though what they’ve been working on, since they don’t necessarily interact with each other all the time. This is a good chance to highlight anything that might affect others or ask any questions. 30 minutes with all the teams, including business development, management etc. The retrospective is a chance to flag up and discuss any general issues or ideas - maybe proposing spending some time on fixing a frustrating bug, calling attention to something you’ve found that works well, or proposing some process change. Also a chance to thank particular people or teams for stuff they’ve helped with. Another 30 minutes again with everyone. And finally the planning meetings. Reviewing what was completed and not completed in the previous sprint, picking out the tickets (from the backlog of work) that we want to do for the next, and then running through them to make sure we have all the details required for each one. Maybe adding some additional tickets for anything that’s missing. Then a quick planning poker estimation of story points, agreeing on an estimate for each amongst the team, followed by comparing the total estimate with the previous sprint to see if it looks roughly in-line or we have tried to pack too much in. Usually 1 hour, developers and product team only. The developers will also spend a bit of time over the course of a sprint documenting anything they want to do as a ticket and collecting the appropriate requirements. The product team will also file tickets for anything that has to be e.g. delivered to a customer, as well as long-term roadmap items that form the bulk of the work. That’s basically it. There are no teams of bureaucracy, or micromanagement, or “progress signalling”, or reporting, or piles of useless meetings. Just regularly checking in with each other, and periodically reviewing and adjusting what we are doing. The goal of any of these systems is to help produce quality work at a steady pace. Take the bits that work and drop the bits that don’t. We have small teams so I’m sure the nature of the process will change over time, but I’ve worked with far larger teams that were pretty much the same. Honestly, at this point I find it hard to think of a method of development I would prefer.