In the book The Checklist Manifesto, Atul Gawande recounts how the building industry has adapted to successfully manage complex projects.
The Wisdom of the Group
Traditionally, a master builder was in charge of overseeing all aspects of the successful completion of a building. But this began to change in the early to mid 20th Century, when the tools and capabilities of buildings increased their complexity beyond a point where one individual was able to manage all of the intricate details of the project.
The solution to managing this explosion in complexity was to shift away from empowering one expert (the master builder) to a system where a group of experts are empowered to resolve and troubleshoot problems. When presented with uncertainty, the team of builders established a communication process that allowed everyone to communicate about and ultimately sign off on the resolution to an issue when the issue crept up.
“They didn’t believe in the wisdom of the individual…. They believed in the wisdom of the group.” And the most important technological advance for the construction industry has been the perfection of tracking and communication.
Software Development Teams
The analogies of these concepts to software development are intriguing. In The Mythical Man Month, the software development world also has an analogy to the master builder; the chief programmer (interestingly, the chief programmer concept derives from the world of surgery, which Gawande discusses as problematic in The Checklist Manifesto.) This chief programmer team composition as I learned about it in school, however, is generally understood to be impractical, due to difficulties in finding qualified candidates for the chief programmer role and due to team scale limitations. At least that’s what the textbook says; I would imagine another major reason the chief programmer team structure fails is similar to the reasons Gawande discusses; the explosion of complexity and the inability of one individual to master all of the nuances required for the entire software project.
Gawande also discusses how building inspectors will trust the team to perform their work, realizing that some details of the inner workings of the building are too complex for one individual inspector to approve in a black box fashion. Instead, the constructors of the building sign off on the legality of their work, thereby being held personally liable for the work performed. In software teams and for software developers, I equate this to the responsibility developers should hold in writing the best quality code to achieve the intended business objectives, and to support that code with developer written (unit) tests. Other quality measures should be adhered to in a team, including quality assurance tests and frequent customer reviews to ensure the results are meeting the intended objectives and that the customers are satisfied with the overall results.
My take on this is that a project will be more successful when individuals are proactive and empowered, take responsibility for their actions, and when they communicate and collaborate frequently among themselves and with their customers. While there are many ways that a software team can be successful if they follow these basic principles, I believe that the Agile software methodology and the Scrum framework provide especially useful and practical processes to ensure this communication and collaboration happens. Highly effective teams understand that trusting the wisdom of the entire team will lead to improved chances for overall success.
