In The Mythical Man-Month: Essays on Software Engineering, published in 1975, Frederick P. Brooks, Jr. shared lessons he learned from the massive project he led to build the OS/360 operating system for IBM’s System/360 mainframe computers. IBM bet its future on the System/360 in the early 1960’s, and the bet eventually paid off as a major success. But it wasn’t perfect in its execution; the project ran woefully late and cost several times its estimate. The book deconstructs what Brooks felt went right – and what went wrong – and tackled popular myths concerning management and manpower issues in large, complex software projects along the way.
Brooks also offered some ideas, long before Scrum, Kanban or XP were ever dreamed of, on how to improve large projects and give them more agility and efficiency. One of these was “The Surgical Team,” an idea Brooks adapted from a colleague of his at IBM, Dr. Harlan Mills, who imagined it as a means of eliminating mediocre software code. Mills proposed dispensing with large teams of conventional developers and replacing them with specialized resource teams dedicated to assisting exceptionally skilled software engineers, allowing these mavens to write and implement code unencumbered by distractions or tedium. Each team would have one such programming genius as its team lead in a role Mills likened to the chief surgeon in a medical team.
Although Mills’ approach was very different from mine, I could clearly see that we shared a similar doctrine concerning software management: If you want great code and you want it quickly, find the best people you can afford, give them everything they need, and eliminate all the time-wasting tasks you can. Then, get out of their way and let them code.
The analogy of a “chief surgeon” as a software team lead intrigued me. Not for the reasons Brooks and Mills had in mind, though, but for something else. When I pictured a chief surgeon, I thought of the tremendous responsibility a chief surgeon has, and I pictured a software team lead having that same kind of awesome burden. A question formed in my mind: What if every person on a software team “owned” the code it creates, but only one person was ultimately responsible for that software?
You see, I’m not a big fan of the concept of “team ownership” commonly found in Agile environments. One issue most Agile methodologies fail to address adequately is software quality, and I think the idea of shared ownership tends to be part of the problem rather than a solution. In almost every company I’ve worked at, I’ve observed some developers for whom ownership doesn’t mean “We own this together;” it means “The team owns this, not me. So I’m not personally responsible for doing anything except my part.” Sometimes, giving everyone on a team shared ownership of a software product unintentionally backfires, leaving no one with a duty-bound obligation to ensure the entire team creates quality software it can be truly proud of. Team ownership is not a quality control process or a standard of care; it is simply an ideal – a chain-like bond between team members that is only as strong as its weakest link.
In contrast, few activities in human experience hold greater demand for painstaking quality control than the practice of surgery. The risks of not getting a procedure exactly right can include anything from failure to improve the patient’s condition, to infection or other complications, to the loss of a limb, organ or body function, to – in the worst cases – death. Dosages, tolerances, and vital signs must be monitored constantly and carefully. No procedural step can be missed or done in the wrong order, no incision can be too deep, and no tool or sponge can be left behind in the patient’s body for fear of life threatening complications.
The medical field has a time-honored method for insuring every surgery is performed as perfectly as possible. In every surgical team, a head surgeon bears total responsibility for the procedure and makes all the decisions: What will be done, when, and how. Comprehensive support comes from a skilled team including other surgeons, anesthetists, nurses, and nurse practitioners. These teammates may do any number of things, including, in some cases, surgical procedures. However, everything they do is under the direction of the chief surgeon, and he or she remains totally accountable for the outcome of the operation on every level and in every way.
In logic, when a proposition is so incontrovertible that it is beyond dispute, it is said to be apodictic. This word aptly describes the head surgeon’s accountability in the operating room; it is absolute, automatic and certain. Although every participant has a job to do and responsibility for doing it well, the chief surgeon has ultimate accountability for everything. If anyone makes a mistake that harms a patient, the chief surgeon will be held liable.
Before I go on, allow me to digress very briefly. There’s a rather long story I’ll tell another time about this, but in 2014 my firm needed to build a large software application for a new contract we had won. With our own developers swamped, and being leery of outside contractors after a bad experience, they wanted to know if I was interested in building a new team. I responded with a proposal for a rather unorthodox team I would set up and manage, using some ideas I had been thinking about for a while. As part of the proposal, I set some conditions that would allow me to have complete authority over how the team would run, operating within the company but much like an outside contractor in terms of hiring, policies, and practices.
At first, only a couple of my ideas didn’t adhere to accepted Agile norms; the rest was very typical Scrum and XP stuff with a Kanban board for pull-based workflows. But once our ideas began to show impressive results, we decided to allow ourselves the freedom to think completely outside the box of typical Agile insights and explore new ideas. The outcome was a whole new toolset of processes, methods and basic tenets which we gave names to for working purposes. In early 2017, I started my own company and began building more teams using this toolset. Eventually, we decided on a name for the whole toolbox – the Denver Method. The ideas shared in this blog come from that toolbox, in the hope that they may benefit other development teams the way they have benefited us. I will use the names we came up with to distinguish Denver Method tools and ideas from popular Agile methodologies.
When the surgeon idea I’m discussing in this article came to me, I had been dealing with frustrations I wanted to get away from for at least the remainder of my natural life, if not longer. I didn’t want any more “coaches” who were really project managers, nor “servant leaders” who were really whip lashers. I had already formed the image of a new kind of “servant leader” who truly belongs to the development team and doesn’t tell the developers they need to “increase their velocity” (Scrum jargon for “work faster or put in more unpaid overtime”). No, this person, whom I decided to call an Aegis, would work side-by-side with them as part of the solution, not the problem. He or she would keep away the distractions that prevent developers from focusing on writing code, mentor them continuously, write code if necessary, protect the autonomy of the developers, and help make the software created by the team the very best it can possibly be.
Fred Brooks’ book made me realize one more duty the Aegis should have: Apodictic responsibility for all software developed by his or her team – the same kind a chief surgeon has.
In the Denver Method, the Aegis is apodictically accountable for every line of code delivered by the team. This is for the same basic reason as the chief surgeon’s accountability: To ensure the best possible service to the customer. While the Aegis trusts his or her developers to design and create software with great care and quality, he or she is the one person the customer or the organization will ultimately look to if there is a problem. This means the Aegis must read and approve every line of code before it is released to production, without exception. If the Aegis believes the code could be problematic, represents a design that might be burdensome to maintain, or simply falls beneath the developers’ normal standard of design and quality, the Aegis returns the software to the developer for rework or has the developer work in concert with another team member to improve the code.
In my experience, apodictic responsibility on the part of an Aegis produces better software than simple peer review. Since the Aegis becomes familiar with every block of code in the repository, he or she has a concise picture of how new code will work within the overall application or module. Also, developers know their work will be reviewed not just for functionality, but for efficiency, simplicity, flexibility and other aspects of quality software design. They quickly learn what the Aegis expects and they deliver it as a matter of habit.
Very few safeguards exist against mediocre peer review. I’m not saying lapses in review standards happen regularly, or even often, but developers might sometimes allow other team members a “pass” on less than stellar code to avoid conflict or extra work for themselves. I’ve seen teams where anti-patterns that don’t seriously affect functionality, such as long methods or duplicate code, will prompt nothing more than a note to the developer recommending optimization or refactoring whenever the developer “has the time” – a day that will likely never come. The Aegis’ apodictic responsibility makes such anti-patterns rare.
In Scrum, the Scrum Master makes sure each iteration is properly sized and completed. Meanwhile, the Property Owner ensures that the software focuses on customer-driven features and priorities. But in my experience, these roles usually only resolve quality issues from a functional or UX perspective. There isn’t one lone individual, experienced in software development, who reads every line of code and won’t release code unless it’s flawless… someone tasked with the responsibility of guaranteeing the product delivered to the customer is the very best the team can produce.
In more traditional organizations, managers and project managers have substantial (but not apodictic) accountability for the product delivered. However, those project managers are too busy counting hours, manipulating Gantt charts, frantically trying to find ways to fit another new feature request from customers into the schedule, or trying to make sure that a roll-out date doesn’t get missed. They rarely look at the actual code being created – they don’t have the time (and frequently don’t have the knowledge). Meanwhile, managers are too busy trying to make sure budgets are met, attending meetings, hiring new people and dealing with HR issues. They never get more than a bird’s eye view of the thousands of lines of code written by their teams.
There is a danger in these situations. If a Scrum Master, project manager, or department manager becomes overly concerned with meeting a target delivery date, pressure may be applied to developers. Under duress, a team may take “shortcuts” that increase technical debt or create buggy code just to get software delivered faster. In the short run this may speed up delivery, but it creates technical debt that demands greater and greater rework later, slowing down development in the long term. High technical debt is already one of the more recognized problems with Agile, and “pressure cooker” negligence may add to rework created by other debt-creating techniques. To use the words of Alistair Cockburn, “If there is anything that’s inefficient and hard to defend in Agile, it’s the amount of rework we do.”
Without ultimate responsibility for code quality and without reading code before it is deployed, these managers and team leaders not only don’t know if the code is up to the standards expected by the enterprise or the customer, they may encourage poor quality unintentionally (or even not so unintentionally) by emphasizing speed. And since they don’t have direct responsibility, they could potentially even blame developers when a serious problem occurs for which someone must be held accountable. Assigning apodictic responsibility for code quality to one person who reads every line of code makes this scenario virtually impossible.
From my experience after using it for several years now, and for all the reasons I’ve listed above, I resolutely believe in giving total responsibility for all code development in a team to one person. Like the team in a surgery room, there are many team players who work together and bring about a successful challenge – and every team member’s role is just as important as anyone else’s – but in the end all accountability comes back to one person. In the Denver Method, that is the Aegis.