Browse Books

Reviewer: Richard John Botting

Half a dozen recent books on software development advocate iterative or evolutionary processes. This book quotes popular 1990s authors as evidence for a high-risk variation called Adaptive Software Development (ASD). The book is not a textbook. It has no aids for the student and uses unchecked theories. The author derives his ideas from his experience as a consultant and mountain climber. He uses Microsoft and Netscape as examples. The book will help managers who understand Joint Application Development and function points to manage “extreme projects.” An extreme project is a project in a changing environment that demands results as soon as possible. Highsmith defined ASD to fit extreme projects. Waterfall command-and-control processes are fine when the situation is stable, with time to work out the details first. Projects in an unpredictable situation and with time to spare can use evolutionary delivery. When the client needs results quickly in a comparatively stable area, rapid application development (RAD) fits. Highsmith aims at high-speed/high-change projects. In these projects, the original ideas may become useless in the time it takes to develop the software, so Highsmith recommends a new philosophy in ASD. ASD uses three or more speculate-collaborate-learn cycles. In a “speculate” phase, managers, clients, users, and developers schedule a set of the work products for the cycle. These include pieces of software, requirements, specifications, models, and documentation. During a “collaboration” phase, teams develop them. Unlike Extreme Programming and the Rational Unified Process, ASD does not prescribe techniques. Unlike the Capability Maturity Model, it does not ask organizations to prescribe work procedures. ASD requires the teams to choose their own procedures. It monitors the refinement of work products by teams, from outline to acceptance. This is management by objectives for the 1990s. Highsmith calls the degree of refinement of a work product its “work-state.” Improvements in work-state trigger work on other products. In the “learning” phase of a cycle, the developers, users, and managers review the products. This allows the products, teams, and goals to improve in the next cycle. ASD puts developers and managers into the “groan zone” where they must confront and resolve differences quickly. Management sets up communications, provides resources, and expects results. Teams choose their own techniques and methods. ASD gives teams partial autonomy, so they can adapt to changes by reorganizing themselves. Feelings run high. Teams maintain a balance between stability and change. Highsmith believes that order will emerge in a system when the parts have just enough connections. In this theory, the system tends to a balance between order and chaos. On the edge of chaos, systems embrace change. Several mathematicians, physicists, and others have noted real or simulated systems that work like this. There is no evidence that “emergent order” always gives beneficial outputs, however. Other factors incorporated in ASD should help ensure that the emergent structures produce software that is good enough. ASD cannot guarantee success. Highsmith states that no process can guarantee results with extreme projects. He argues that non-adaptive processes, like those encouraged by the Capability Maturity Model, are worse than ASD. First, extreme projects demand creativity. Repeatable, documented procedures tend to block creativity. ASD forces creativity. Second, extreme projects demand a rapid response to change. Preprogrammed processes develop bugs when unexpected things happen. ASD does not force adherence to a program. Fast delivery and regular product review help the software and requirements to co-evolve. Chapters 1 and 2 set the scene and introduce ASD. Chapter 3 covers the documentation needed to initiate an ASD project. Chapter 4 shows how to plan a set of adaptive cycles. Chapter 5 describes the teamwork needed to work at the edge. Chapter 6 describes suitable quality control procedures—focus groups, technical reviews, and inspections. Chapter 7 explains why even good managers cause projects to fail. Chapter 8 addresses the changes a manager must make in attitudes and organization. Chapter 9 focuses on the shift from managing procedures to managing work products. Chapter 10 describes the kinds of communication needed: two-way, flexible, not too much, and including work-states. Time management and scheduling are covered in chapter 11. Finally, chapter 12 explores topics that do not appear elsewhere. The bibliography includes recent sources but omits some older ones. The index is more than adequate. This book does not mention Extreme Programming, and its brief description of the Rational Unified Process is inaccurate. Also, the author uses words in unexpected ways. As an example, instead of “work-product, ” Highsmith uses the word “component.” He uses “linear” to mean “sequential.” “Optimizing” and “deterministic” may be buzz phrases. The author states that good results “emerge” from complex adaptive systems. Biologists talk of emergent properties, and modern systems theorists talk of emergent order. These are not results. They are higher-level abstractions. Shared goals and learning help adaptive teams to produce desirable software, not misnamed “emergent results.”