What methodology is closest to the Surgical Team in The Mythical Man-Month? [closed]

Question

The Mythical Man-Month is now classic, but the "Surgical Team" methodology is still interesting. What methodology most closely resembles it or has the same essence?

To summarize the Surgical Team analogy: A surgeon understands the problem/business domain and is the expert. They are the authority when there are questions or conflict with in the team. The surgeons work between themselves when there are issues, say with design, functioning as a smaller tight team of experts. So in essence they have the knowledge of the domain, are entrusted to do they think is right, and do the actual coding? The rest of the team focuses on support, testing, documentation, and project plans are delegated tasks. Consequently the surgeon is also the most skilled/trained resource.

The answer could be project, programming, design methodologies as it seems to have implications across main methodology domains. Agile, MDA, Extreme, in sourcing development? This question also make more sense for software that is large in a complex business domain, think air traffic control, not a COTS developer to or common utility.

Casmey

In TMM the surgeon presents a precarious bus factor. If you haven't seen it I recommend reading Dave Thomas' article titled Agile is Dead and consider the 4 values of software agility—one which is working software. – Isodynamic

Answer 1

One of the patterns mentioned in Organizational Patterns of Agile Software Development is titled "Three to Seven Helpers per Role"; it differs from Surgical Team in that it pays attention to every role, for example it isn't only that the surgeon 'role' that has helpers or relationships: all roles have some number of relationships.

Another pattern from the same source in named "Architect Also Implements", which may be analogous to "Surgical Team" in that the Architect in particular is (presumably) highly skilled.

Resurrectionist

Good references to some interesting patterns, and Agile seems to be the consensus. – Casmey

To be honest, te book's intro says, "[...] These notions of healing, repair, and growth are the foundations of Agile development. O.K., we'll be frank: we chose "Agile" for the title out of marketing concerns. [...] This manuscript has been evolving piecemal for more than a decade, and [...]" – Resurrectionist

Answer 2

In the case of a surgeon, the key actor is both the domain expert and the implementor.

I.e., he's both the software program manager (architect) and the developer.

This sort of methodology might fit certain short-burn situations: for instance, a complex operation like a live server migration or software upgrade.

For general development, however, there are a few issues with such "hero" methodologies:

• Few key developers understand the problem domain to a sufficient degree, and must rely on domain experts. This is simply a function of specialization--it's tough to find kick-butt programmers who also are lawyers, doctors, accountants, or otherwise are experts in the domain the software is modeling.

• Scalability is limited by the number of "surgeons" you have available.

• There's a lot of down time for the other staff while they wait on instructions, since the highly-focused "doer" is also managing the team. That's ok in the OR, since you're dealing with a "zero-bug" mandate and "live software." But in this economy, a more distributed workload is more efficient, even if it results in the occasional sync problem between team members.

Volost

I don't find your third bullet much of a problem really. The goal isn't for everyone to be busy at all times. The goal is to produce the same quality software faster/cheaper. – Forwardlooking

Answer 3

I'm not sure any methodology really addresses that, as it is really a matter of prioritizing the developers and bending everything to their needs, rather that being anything about how those developers actually develop their software.

If you were looking for some methodolgy that impements this, I suppose this may be bad news. I prefer to consider it good news, in that it means you can use this approach with pretty much any software development methodology.

I've worked on exactly one project that was run that way. It was so enjoyable, I nearly feel bad calling it "work". Four of us developers (with extra support personell, including the occasional extra junior code monkey) got a truly prodigous amount of code written and running properly in only 9 months. Other places I've been couldn't have done as much with a team of 20.

Forwardlooking

Answer 4

From the text I see the following:

Agile Like:

• Small teams focused on solving specific problems
• Collaboration among the surgeions

Non Agile Like:

• Surgeons are the authority, driving the plan, determining the design, allocating support tasks (viewng them as subservent to coding) and doing the coding. All of those are very command and control in approach and contrary to self directing teams (vs a directed team)
• There appears to be no collaboration with the business partner (let alone frequent collaboration with the busines partner)
• There appears to be no prioritized product backlog, thus the surgeon picks what is important not the business partner
• There appears to be no incrmental delivery (tight feedback loop)

For a waterfall project, it is suggesting to use a team of experts (surgeons) to do the planning, designing, coding etc. and allocating tasks to the "support" staff. On an agile team, testing is not treated as support but an integral part of delivery.

One can't say with certainty the methodology being advocated. However, it does appear to use the language (project plans, tasks) and assume that the waterfall approach is being followed (phases like design, coding, testing driven by a plan). Whatever methodology is being used, it one for which the few determine the work for the many.

Womack