I have done agile development successfully, and yet, the article rings very hollow for me, because most of its examples have very little to do with the principl

I have done agile development successfully, and yet, the article rings very hollow for me, because most of its examples have very little to do with the principles the author tries to explain. For instance, he talks about working strategies, and puts Google as an example. Google is a terrible example for almost every other company out there. They have a gigantic monorepo, which is only manageable because they have custom tooling from hell. For most of us, the organization doesn't have said custom tooling from hell: The OSS version of bazel just doesn't work quite as well out of the box. If you aren't running a highly modified version control system like they do, check in performance dies. You might be able to pretend to be Google if you are tiny instead, but anyone in between will just meet suffering. It's a bit like trying to match apple in industrial design. Then there's the talk about feature flags. They are great, useful things, but there is also hidden suffering behind feature flagging all the things. There is much extra gardening required, and a completely different set of headaches when relatively large changes affecting the same parts of the code are being hidden behind feature flags. They have weird interactions too! And don't forget how much fun it is to have intermediate data structures changing for features that aren't active: He is just glossing over big, big problems, that happen to be different than the one he discusses. Given that the author is consulting for tiny startups, chances are he hasn't stared at those problems in the face, but they exist, and they are especially pernicious when your tiny company believes that imitating google will work, and then reaches 60-80 programmers: Then all the advice above starts to crack, and it only gets worse when you get into the 200 engineer range. The difficult part is not being a small company, where any and all practices will work. It's not that hard being huge either: Just invest heavily in your own ecosystem. PHP too slow? Rewrite it! Git too slow? Write a new engine for Mercurial! It is when a company is growing fast, bit isn't really large, when your technical practices can cost you your company, and the article's advice is PRECISELY the way to get murdered.