This is why Perl6 is not Perl5.
You're very close to how I'd word it with babies. See, if you want one baby you wait 9 months. If you want 5 babies and you have one mother, you wait 55 or 60 months. If you want five babies in 9 months, you can totally have five mothers. You can't get one full-term baby any faster than 9 months by adding mothers. DevOps doesn't solve the one baby problem any faster nor the five babies by one mother problem any faster. It can solve the five babies problem if you're okay with the babies having different mothers (team leads or sub-project managers) and different DNA (team implementation styles). If the other parent (the overall project lead or the solution architect) is the same, the five babies may learn to live together as a family, although there's the possibility they won't.
This is my point. It works very well for a well-defined, well-understood, practically standardized stack to be used to write a new application. That's not the same thing as breaking new ground on a project without all that supporting code and voluminous standards documents already helping you out. The Mythical Man Month hasn't been disproven at all. It's just that in some areas it's possible to change the scope of the project. Smaller projects don't take as long.
Server with automatic upgrades and video drivers?
No backups, either? You had to reinstall the OS?
The generation of random numbers is too important to be left to chance.