Gerald Weinberg has an interesting (and more finely grained) take on this. - Level 0, the Oblivious pattern, corresponds to one or two people just solving prob

Gerald Weinberg has an interesting (and more finely grained) take on this. - Level 0, the Oblivious pattern, corresponds to one or two people just solving problems with code. They don't have any external customers, and they don't even think of what they're doing as software development. Think accountant scripting a spreadsheet and you get the idea. This is obviously a culture with little process. You will likely not even find best practises like version control, testing, code review, etc. - Level 1, the Variable pattern, is a lot like level 0 except there are now external customers. These make demands, but the software developers generally still spend time doing what they feel like. This scales up to something like 12 people (as suggested by Boehm), and Brook's surgical team of experts (from The Mythical Man-month) is probably a good model for team composition in this pattern. To support collaboration, you start to see things like version control, code review, etc., based on the likes and dislikes of the team involved. In this pattern, failure is often ignored or downplayed in the interest of moving on with things. Still a low-process, winging culture. - Level 2, the Routine pattern, is what usually happens when organisations grow. The Variable pattern stops working because the organisation can no longer hire exclusively experts. Management is tired of the unpredictability that comes of a Variable team of non-experts, so they Institute processes based on best practises. However, since the processes are enforced from above, and nobody really understands their purpose, and they aren't fit for that purpose anyway, most real work gets done by secretly abandoning the processes. Especially during time pressure, even management will suggest to throw out the process because "we don't have time for that". Since nobody understands why the process is there anyway, the Routine pattern tends to devolve into the Variable pattern at the first whiff of failure. The Routine pattern is effectively the organisation trying to be systematic but not having the necessary understanding to do so. It honestly sounds like the author was suffering under the Routine pattern, to me. - Level 3, the Steering pattern, is a better but more demanding approach than the Routine pattern. The Steering pattern starts with a respect for observation, understanding, and feedback. It institutes processes that are appropriate for their purpose. It treats failure as an opportunity to adjust process. Most normal projects in the Steering pattern looks like the Routine pattern. The difference is that a lot more projects become normal in the Steering pattern, because they don't throw out processes when they need them the most. They understand their purpose and collectively adapt them to always be relevant. ---- As some sort of summary: - In levels 0, 1, and 2, people aren't very good at using feedback at all. It's mostly ignored or used as a stick to beat people with. - In level 3, people can use feedback from individual projects to evaluate and adjust the same projects. - In level 4 (not described above), people can use feedback from individual projects to evaluate and adjust the processes and teams that drove those projects, meaning feedback gets used more generally. - In level 5 (not described above, also never observed by Weinberg), people do all of the above observation, but also meta-observes: they use feedback from projects to evaluate and adjust how they use feedback from projects.