3. The Surgical Team
Opposes: A view that small sharp team is more effective than a large team of medium-skilled engineers. Also opposes the "conventional team"
Supports: Harlan Mills and centralized workflow organisation.
Claim: the problem with the small team concept is that it's too slow for really big systems (31).
Method: Comparative analysis of the two models, the "conventional one", where several features of the product are developed simultaneousy and the centralized one supported by Brooks, where "one does the cutting and the others give him every support that will enhance his effectiveness and productivity". While acknowledging that the latter approach supported by Brooks was a step ahead of the other model, both of them lacked the flexibility required for building a more effective workflow.
Notes:
It is easy to notice that the model described here has an abundance of roles that have nothing to do with neither production nor decisions, which could be explained by the absence of powerful enough documentation, issue tracking or project management tools. For example, the "program clerk" is now replaced by Jira and Confluence, the "toolsmith" is outsourced to IT department, and the "language lawyer" is now embedded into back-end developer role. The lack of computational resources also means that front-end development is completely absent, since the visual side of software and other functionality it covers today was not there yet.
Setting aside the tendency of using "he" when detailing the roles in the model, it presents interest as a showcase of which methodological approaches to software engineering existed prior to agile. I would argue that scrum is improving this model at least in one major way - the whole of decision making is not any longer concentrated in one role. In Brook's model, "the surgeon", has the final say on all things software product. This role is quite mixed and complex and includes responsibilities for not only for designing the product, but also for coding, testing and documentation. The "copilot" is a product owner limited to only making suggestions and in any other way being secondary to the "surgeon", with the rest of the team hardly having any weight in decision making at all. Additionaly, the "administrator" role is overloaded with elements of different other roles, handling both communication between the team leader and the team together with office logistics. "The system, - Brooks says - is the product of one mind", in other words, it doesn't account - or accounts only externally - for the client and the user. This is crucial for understanding in which ways the view on software production has changed just a decade later.
