- XP Was Created to Address Project Risks
- But Project Risks Are Symptoms, Not the Disease
- Summary
But Project Risks Are Symptoms, Not the Disease
In reviewing a draft of this book, Andy Hunt (personal communication, February 2002) pointed out that the risks associated with various adverse outcomes are just the symptoms. Project teams could easily go crazy trying to catalog, quantify, and mitigate all of the myriad risks that even a small project faces. Instead, what teams need to do is pay attention to the disease that is causing all the symptoms. Looking at this pragmatically, teams have a much simpler challenge. The disease affecting projects is two headed: ignorance and haste.
Ignorance is difficult to treat because it is hard to admit to our own ignorance. Reframing the problem as "how to be successful with only partial knowledge" makes the conversation more palatable. By talking about partial knowledge environments, we enable a team to talk about the research, investigation of prior art, and learning involved in successfully delivering an application. This is in marked contrast to most teams, which seem to specialize in reinventing wheels and ignoring previous work.
Haste is an endemic problem in the software industry. Project teams are nearly always pressed for time and hence end up ignoring prior work because the team does not take the time to do the necessary research and learning. The problem with haste has been described by Tom DeMarco as a consequence of what he calls Lister's Law: "People under time pressure don't think faster." [DeMarco, 2001, p. 50] When teams are under time pressure, the team members make sure that they look busy, even though they know that what they should really be doing is taking the time to research and think about what they are doing.
Unfortunately, haste makes the effects of ignorance even worse. When faced with partial knowledge, developers can either make assumptions based on their own experience or they can ask questions and do research. In all too many organizations, the developers have been trained to make assumptions. True, the training department does not put on a course called "Assumptions 101," but by word and deed developers are encouraged to keep on working and to ask only really important questions.
Interestingly, Extreme Programming addresses this two-headed disease very effectively. Requiring the customer to work as an integral part of the development team makes it easier for developers to ask questions, and many of the practices are aimed at discouraging developers from making assumptions. By colocating the team, XP encourages the entire team to ask questions rather than make assumptions. This goes a long way toward addressing the problem of delivering quality applications in the face of partial knowledge, because by involving the entire team there is less chance that important issues will be overlooked.
The problem of haste is addressed by talking about the concept of a sustainable pace and small releases. Indeed, the entire planning process in Extreme Programming addresses the issue of haste by the way that it divides up the responsibility for the planning between the developers and the customer [Beck and Fowler, 2001]. Overall, XP addresses haste through a predictable, sustained, and sustainable pace.