As sibling comment `@wellpast` commented, but to extend it with my point of view. We can roughly say we can have three out of: (high) quality, (low) time, (low

As sibling comment `@wellpast` commented, but to extend it with my point of view. We can roughly say we can have three out of: (high) quality, (low) time, (low) communication complexity, and (low) money. (time is a dependent here.) People are trying to apply factory processes and structures to a team sport, an engineering discipline. You do not teach or build a basketball team by breaking down each attack phase into steps and checkmarks. You try to minimize communication and make the team work as one. It is a team and individual building, not a process building exercise. You make a plan, and follow the Moltke's the Elder conclusion: "no plan of operations extends with any certainty beyond the first contact with the main hostile force." (Or paraphrased as you have heard: No plan survives contact with the enemy.) All (types of) Engineers know this. But software engineering is "special." And it is not a "move fast and break things issue." That is part of all engineering or team playing too. It is the type of business mentality, that because a plan did not go exactly as expected we need to add more process. Whatever that process may be. Because if "I as a manager add a process, then the next failed plan, I am covered, and I will blame the individuals." Process has a place to ensure things happen in a legal and moral framework. And minimize adverse circumstances -- e.g. we bet all the hedge fund money accidentally when running tests. Process is used differently in most startups and corporations with not the team in mind.