Why Teams Are Responsible for Successful Product Delivery
Recently, Alistair Cockburn, one of the authors of the Agile Manifesto, commented that “anything where a need for 100% reliability exceeds the need for flexibility would be better off using traditional methods with a rigid specification defined up front and adhered to.” He went on to explain in his Computerworld interview that there are many projects where the need for 100 percent reliability far outweighs the desire for flexibility.
In his discussion with Computerworld, Alistair graphed the number of people that need to be coordinated in a development process against the number of people likely to die if something goes wrong (the graph was not reproduced). Web projects, mobile apps, etc., fell in the lower-left quadrant. Due to the possible risk involved, projects like a space-shuttle development or something related to pharmaceuticals fell in the upper-right quadrant.
The idea is that the heavy investment of time and money in requirements gathering and process oversight will lead to a more reliable or safer software product. But is that really the case?
Numerous high-profile software failures run counter to Alistair’s supposition. NASA itself has had two spectacular failures in its Mars program. First, in 1999 the Climate Orbiter overshot its target and burned up on entry. The reason? One team used metric measurements; another used Imperial. The second example happened later that same year when the Polar Lander crashed due to a malfunction that prematurely shut down its main engines. The total cost of the two incidents was $357 million. NASA investigated both incidents and made several process recommendations.
The overriding theme of these recommendations is the need for accountability, and this is one of waterfall’s biggest weaknesses. All of the accountability is put in the hands of the project manager and the metrics used to measure performance. Individual contributors are responsible only for their own tasks and not for the product as a whole. The process is designed to identify someone to blame if there is a failure and, since no one is truly responsible for the end product, not to reward the team for success.
Typically, the project manager is set up to be the ultimate scapegoat for any failures that occur. This idea runs through NASA’s recommendations.
On the other hand, agile makes team members responsible for the successful delivery of their product. Ryan Hanisco does an excellent job of illustrating how internal team accountability leads to ownership over the final deliverable and why this leads to agile's delivering great software. Alistair Cockburn’s fall back to command-and-control methodologies for high-pressure projects only reflects a lack of trust in teams and results in using process as a crutch.
I have seen the effects of waterfall’s fixed deadlines and the pressures put on teams. I also have seen the quality of code produced by frequent iterations with stakeholder feedback. Having worked in both environments, there is no question in my mind which process I would prefer to be used to develop the software running a medical device that I might be hooked up to. How about you?
