I.e. the old "you are doing it wrong" argument. My experience is that there is no right way that you can blindly apply on any project. There is no set of magical agile dogmas that works everywhere. And there is no substitute for decent engineers doing what needs doing.
Agile was a neat idea 20 years ago and it changed the engineering practices. However, unlike the methodology, engineering practices continued to change and modern software development practices automate away a lot of what agile processes tried to orchestrate.
If you are doing continuous delivery and lean development, you should be conceiving of and shipping software features in time units smaller than a sprint (i.e. continuously). That was very rare 2 decades ago and has become the norm for a lot of tech companies. It requires asynchronous processes and practices. It's enabled by having automated builds, automated tests, and automated deployments. These tools barely existed 2 decades ago and have had a far larger impact on software development then any form of agile.
Lots of large OSS projects and software companies have made the shift from doing feature based software delivery to time based software delivery. E.g. MS famously kept missing its own deadlines with windows vista, windows 7, etc. and shifted to having a more predictable release schedule. Ubuntu's LTS releases appear regular as clockwork in April of every second year. Linux ships a kernel every 2-3 months. Mozilla ships Firefox every month.
Time based releases are basically about releasing an unknown quantity of software at specific intervals and with a high level of quality. It involves having multiple asynchronous tracks of development and instead of planning which of them need to be ready they simply use quality gates to determine which of them are actually ready to ship. It's a shift from what to when and it emphasizes quality (i.e. good engineering) over schedule.
Most agile methodologies are still stuck trying to do feature based planning. It's the project mentality from the nineties where things get commissioned and have to be delivered on a particular schedule. Worse, these things are often under specified and then blow right by their planned deadlines. Just like in the nineties. I've seen a lot of agile projects shipping low quality software doing the wrong things right on time.
Agile was a neat idea 20 years ago and it changed the engineering practices. However, unlike the methodology, engineering practices continued to change and modern software development practices automate away a lot of what agile processes tried to orchestrate.
If you are doing continuous delivery and lean development, you should be conceiving of and shipping software features in time units smaller than a sprint (i.e. continuously). That was very rare 2 decades ago and has become the norm for a lot of tech companies. It requires asynchronous processes and practices. It's enabled by having automated builds, automated tests, and automated deployments. These tools barely existed 2 decades ago and have had a far larger impact on software development then any form of agile.
Lots of large OSS projects and software companies have made the shift from doing feature based software delivery to time based software delivery. E.g. MS famously kept missing its own deadlines with windows vista, windows 7, etc. and shifted to having a more predictable release schedule. Ubuntu's LTS releases appear regular as clockwork in April of every second year. Linux ships a kernel every 2-3 months. Mozilla ships Firefox every month.
Time based releases are basically about releasing an unknown quantity of software at specific intervals and with a high level of quality. It involves having multiple asynchronous tracks of development and instead of planning which of them need to be ready they simply use quality gates to determine which of them are actually ready to ship. It's a shift from what to when and it emphasizes quality (i.e. good engineering) over schedule.
Most agile methodologies are still stuck trying to do feature based planning. It's the project mentality from the nineties where things get commissioned and have to be delivered on a particular schedule. Worse, these things are often under specified and then blow right by their planned deadlines. Just like in the nineties. I've seen a lot of agile projects shipping low quality software doing the wrong things right on time.