The Mythical Man-Month

The Mythical Man-Month

When we began the re-read of The Mythical Man-Month my plan was to go through two essays every week. To date the planned cadence of two essays has been out of reach. Each of the essays are full of incredibly rich ideas that need to be shared therefore I am amending the plan to one essay per week. Today we re-read The Surgical Team. In this essay, Brooks addresses the impact of team size and team composition on the ability to deliver large projects.

The concept of a small team did not jump into popular discussion with the Agile Manifesto of 2001. Even before The Mythical Man-Month was published in 1975 the software development industry was beginning to coalesce around the idea that smaller teams were more efficient. Smaller teams are easier to coordinate and information sharing is easier because there are fewer communication paths with less people. The problem that Brooks postulated was that big systems, which are needed. can’t be built by a single, small team in any reasonable period of time. Efficiency does not always translate to effectiveness. Paraphrasing Brooks, the question we have to ask is if having an efficient single small team of first class people focused on a problem is great, how do you build the large systems that are needed? If small teams can’t build big systems efficiently the solution is either to not build large solutions all at once, find a mechanism to scale smaller teams or revert back to using brute force (which is often the method of choice).

The brute force method of developing large systems has been the most often leveraged answer to build large systems before (and after) the publication of The Mythical Man-Month. Brute force is a large project team typically coordinated by a team of program and project managers. Earlier in my career I was involved in systems side of bank mergers. During one of the larger mergers I worked on over 300 coders, business analysts, testers, project managers and others worked together to meet a merger date. Unquestionably the approach taken was brute force and as the date got closer the amount of force being brought to bear became more obvious. Brute force is problematic based on lack of efficiency and predictability. Brute force methods are affected by the variability of an individual’s capability and productivity. The goals of the systems portion of the bank mergers were not the efficiency of the process, but rather making the date given to the regulators for cut over to a single system without messing people’s money up and ending up on the front page of The Plain Dealer.

If brute force is an anathema (and it should be), a second solution is to only use small single purpose teams. Products would evolve as small pieces of functionality are conceived, built and then integrated into a larger whole. Scrum, at the team level, uses small teams to achieve a goal. Team level Agile embraces the effectiveness of small teams discussed in The Surgical Team, however does not address bringing large quantities of tightly integrated functionality of market quickly.

Agile has recognized the need to get large pieces of functionality to market faster than incremental evolution without abandoning the use of small teams by adding scaling techniques. A Scrum of Scrums is a technique to scale Scrum and other team-level Agile frameworks. Other scaling frameworks include DSDM, SAFe and Scaled Scrum. All of these frameworks leverage semi-autonomous small teams with some form coordination to keep teams moving in the same direction. Scaling adds some overhead to the process which reduces the efficiency gains from small teams, but allows larger pieces of work to be addressed.

In The Mythical Man-Month, Brooks leverages the metaphor of the surgical team to describe a highly effective AND highly efficient model of a team. In a surgical team the surgeon (responsible party) delivers value with a team that supports him or her. Transferring the surgical team metaphor to a development team, the surgeon writes the code and is responsible for the code and the backup surgeon (Brooks uses the term co-pilot) is the surgeons helper and is typically is less experienced. The backup is not responsible for the code. The rest of the team supports the surgeon and backup. The goal of the support team is to administer, test, remove road blocks and document the operation or project. While we might dicker about the definition of specific roles and what they are called, the concept of the small, goal-oriented team is not out of line with many Scrum teams in today’s Agile environment.

Scrum and most other Agile techniques move past the concept of teams of individuals with specific solo roles towards a teams with more cross functional individuals. Cross-functional teams tend to yield more of a peer relationship than the hierarchy seen in the surgical team. The flatter team will require more complex communication patterns which can be overcome in Scrum with techniques like the stand-up meeting to address communication. The concept of the Scrum team is a natural evolution of the concepts in The Surgical Team.  Scrum tunes the small team concept to software development where a number of coordinated hands can be in the patient simultaneously, if coordinated through the techniques of common goal, stand-up meeting, reviews and continuous integration.


Previous installments of Re-read Saturday for the The Mythical Man-Month

Intro and Tar Pit

The Mythical Man-month Part 2