Agile Mythical Man-Months — Part 1: Teams
A modern day agile analysis of the Mythical Man-Month and the system that almost destroyed IBM.
In writing “The Mythical Man-Month”, Frederick P. Brooks, Jr. provided insight into the firestorm of software management, innovation, and leadership of the 1960s. Brooks was one of the people leading the delivery of IBM’s OS/360 project, an ambitious family of machines that scaled up in ability and implemented new and exciting technologies. IBM’s OS/360 was also over-due by more than a year, over-budget by five billion dollars, and over-complicated by today’s standards. At the time, however, it was one of the largest software projects ever embarked upon, and the lessons learned from the experience deeply influenced the future of enterprise-scale software development.
In reading thoughts now, it’s impossible to miss that lessons he learned in the 1960s are still problems Agile teams face today. He details out challenges like documentation, team organization and roles, and the seminal lesson known as Brooks’ Law, that adding more people to a late project only makes it later. Somewhere, an Agile team is struggling to document their microservices. Another team doesn’t know who’s in charge of their project because they have three different managers with conflicting job descriptions. The next team recently hired on two more senior engineers because they have too much work, and the onboarding probably won’t take too long.
Probably.
How does Agile development differ from the OS/360’s development? Are those differences improvements? What tools and resources do we have now that affect Brooks’ advice? These questions are necessary because history is vital to software development. In analyzing our past, we can more effectively move forward.
The posts in this series will tackle different themes from The Mythical Man-Month and how they apply to software development today. Topics include how people are structured, how organizations are structured, how projects are measured, and other constraints unique to each time period. Following, Brooks’s lead, I’d like to start with something we’ve all been a part of:
Teams.
PART 1: Team Models
[Note: all “he/him/his” pronouns used in reference to programmers have been changed to “she/her/hers”, because it delights me.]
Brooks depicts a team structure based on Harlan Mills’s proposal of a “surgical team” model. It consists of ten people, detailed below:
Surgeon
The surgeon is the chief programmer. She defines the program specifications, designs the program, codes it, tests it, and writes its docs. She needs access to a computer at all times to she can write and test her code at her whim. She also need great talent, at least ten years of experience, and knowledge across all fields she might come in contact with. She likely has a degree or education in “applied mathematics, business data handling”, or whatever is relevant.
Copilot
The copilot is the surgeon’s side-kick, her right-hand woman, in that she is able to do all that the surgeon can but is likely less experienced. The surgeon isn’t beholden to the copilot’s advice, but the copilot can contribute her thoughts to the design. She knows all the code, she researches alternative designs, and she’s a sanity check when the surgeon needs a review.
Administrator
The administrator is in charge of implementing all decisions related to people. While the surgeon decides personnel, raises, space, and whatever else goes onto the operational-people side of the project, the administrator makes it happen. Mills advises that if the project isn’t related to legal issues, the administrator can likely serve two teams adequately.
Editor
The editor takes product documentation provided by the surgeon and edits it, provides sources and references, versions it, and “oversees the mechanics of production” through written word.
Secretary
There will likely be two secretaries needed. These men will handle project correspondence and non-product files. They should serve in non-technical capacities.
Program Clerk
However, to maintain the technical records, a program clerk is needed. She’s trained as a secretary, but all computer input goes to her for logging, and all output listings go to her for filing and indexing. All program interactions “are made visible” through her. She makes sure that the product is interacting properly, and maintains a traceable document history for product integrity.
Toolsmith
With all of this documentation and program design happening, a toolsmith is necessary for making sure the team has all tools necessary to operate. She makes, maintains, and updates any special tools her team needs.
Tester
A tester creates test suites and provides test data to match. She also provides test scaffolding and sequences.
Language Lawyer
To ensure proper use of the tools, a language lawyer is an expert in the programming language the surgeon has been tasked with using. She is able to find neat and efficient algorithm implementation so the surgeon can focus on design.
It is clear that the surgeon provides the driving force behind the project in terms of design, people, and implementation. Her experience and wisdom puts her in a position above all other professionals on the team, and the product is “of one mind — or at most two, acting uno animo”, as Brooks puts it, in the case of the copilot contributing to the product as well.
It is also clear that, as we read through these roles, there are direct parallels to current software roles en vogue.
- Surgeon = Product Owner (PO)
Drives the vision of the product and ensures correct development path - Copilot = Engineer
Gives input on the product but does not drive its future - Administrator = Engineering Manager (EM)
Focuses on the people on the team, not the product - Toolsmith = Operations/Infrastructure Engineer
Creates/maintains infrastructure of the system and ensures availability - Tester = Quality Assurance (QA)
Builds test suites and returns results to engineers - Language Lawyer = Subject Matter Expect (SME)
Shares specialized knowledge of tools to help create the best solution possible
Of course, there are some things that are obsolete. Due to advancement in communication technology, secretaries are no longer needed. Teams now aim to have engineers create their own documentation so the editor has been eliminated. If logging and metrics are in place, the program clerk can also be eliminated since program input and output should be readily available at all times.
It can be argued that in truly cross-functional teams, the tester role, the toolsmith role, and the language lawyer roles can also be removed (because engineers should be creating their own infrastructure and test suites, and tech debt should be low enough that they should be subject matter experts in what they’re working on.)
What can we take away from team structures?
The purpose of the surgeon and the product owner can be boiled down to keeping the integrity and vision of the product. The role exists to keep the product healthy, from a high-level perspective. The model that Brooks describes has the surgeon in the reeds of the work, but the overall purpose was to design and build a product that could survive as time went on (hence leveraging the surgeon’s ten years of experience and expertise). The product owner, while out of the reeds, is still involved with features developed and the future of the product.
We can conclude that the integrity of the product is something a team must maintain in some way or form, and is best maintained by a role filled by a very experienced person (likely technically skilled or savvy) to pave the team’s direction.
We can also conclude that the surgeon/PO role cannot function alone. In the surgeon team model and the agile model, a copilot or co-contributer exists in the form of another engineer that is definitely in the reeds of the work that can provide insight the surgeon/PO might not see. While the surgeon/PO drives the vision, we can conclude that they shouldn’t do it alone, and that engineers play a vital role in helping the product owner make informed decisions. Without the engineers under the PO, the PO would be useless to make decisions about the product. Without a copilot, a surgeon would get lost in her own design.
If the OS/360 taught us anything, it’s that documentation is important enough that at one point, it warranted at least three people to tackle it. To ask our engineers to document their own work likely distributes the documentation load more evenly, but engineers today struggle with writing, debugging, documenting, and deploying their code on a timely basis simply because there’s so much to do and so much pressure to deploy faster. While I don’t think we can say that we should go back to the model Brooks describes of separating documenting the product in separate roles, perhaps we must start thinking of how documentation has lacked in automation to engineers’ detriment.
We can definitely conclude that people are important, and that managing people is a full time job. This is a surprise to no one. If systems are complex, the people who built them are more complex.
Finally, we can conclude that engineers are expected to do more these days than the engineers of the OS/360. Engineers are no longer just programmers. Engineers in Agile/Scrum, in an ideal world, are expected to design for sustainability, document for readability, write for efficiency, deploy for availability, and test for capability. On top of this, they work with clients, customers, and other teams to build the best product they can.
Our teams have changed as a result of new expectations and of new technology nullifying roles. To summarize what we can learn from comparing team models:
- The vision/integrity of the product needs to be maintained, likely directed from a high-level by a person that receives input from others that work on the product.
- Managing people is hard, and is necessary to the health of the team and therefore the product. (A person should fill this need as a full time role.)
- Documentation was a problem, still is, but advanced tech and shifted expectations have removed the separation of documentation and engineers.
- Engineers serve many functions in Agile/Scrum roles, especially when compared to engineers as “programmers” in OS/360.
Next Up: Organizations
Teams are only one part of how people have changed in programming. Organizations have changed as well to reflect new teams. Part 2 of this series will go into how organization structure and expectations have changed how we develop software.
