I have only seen three principles work consistently in software engineering: tight iterations, divide and conquer and fixed max sizes. All of these principles w

I have only seen three principles work consistently in software engineering: tight iterations, divide and conquer and fixed max sizes. All of these principles work because development is a NP problem and the best we can hope for is a local optimum. In general you see best practice anti-patterns come up that break one or more of these things and math takes over. Take a product backlog for example. In general these backlogs become the one place that everything is put but then you break divide and conquer and fixed max sizes. Since scheduling is an NP problem, if I have an unbounded backlog I have just created an NP problem to solve. the correct way to do things is to admit that you will not find the optimum solution, so the best you can do is break the problem into pieces, assign teams and minimize communication between the teams so that the pieces don't get combined into one again. The teams then need to do the same if the individual pieces are still too big. Massive monolith teams break all the principles and are basically guaranteed to fail. Or they are guaranteed to fail until someone proves that P = NP.