Browse Books

Reviewer: Joan Catherine Horvath

This wonderful, short book is a pragmatic guide to the realities of managing software projects, and to the pitfalls of guiding research and development projects in general. The authors begin by discussing the issues that arise in development projects. With short examples based on the authors' real-life experiences, one sees how "good software practice" in its traditional and literal sense can often lead to something between disaster and frustration. In particular, the authors argue-based on experience with developing lean manufacturing systems-that specifying a software system in its entirety before developing any code ensures there is no flexibility for changes down the road when more is known about the problem. They draw the distinction between creative parts of the development process, during which variability is valued, and later stages, which attempt to stamp out any variances. The latter regime does not really apply to most software development, virtually all of which is a creative endeavor, and so mismatches arise when manufacturing-style practices and metrics are applied to software development. The origins of Toyota's manufacturing systems are discussed. When Toyota started making cars, the Japanese market was small, and capital was scarce. Therefore, traditional mass production was not an option for them. Instead, they built cars as closely as possible to the time the car would be sold. To do this, they did many counterintuitive things, particularly delaying decisions until the "last responsible moment," a term the authors credit to the Lean Construction Institute. The software implementation of this concept is to develop enough of an idea of customer requirements to develop a prototype on a short schedule. Customers then use this prototype, determine changes, and interact with developers on a short (one week to one month) turnaround cycle to be certain that the most important needs are implemented first, and that the features being implemented are actually needed. Structured as a series of tools, or principles, this book takes concepts from lean manufacturing and moves them to the software domain. The authors are careful to note, though, that one of the key elements of developing good practices is to carry only high-level principles from one domain to the next. Best practices are likely only to be best for that particular industry and situation, and one can drown in the consequences of non-applicable analogies taken too far. Each chapter ends with a section of good, pragmatic exercises to try out with a class or software team. The exercises (and the book) build up a clear image of how to think about the development process, which culminates in some suggestions about how to think about systems being developed as a whole, rather than as a series of unconnected parts. To me, this book rings very true, and has quite a bit of advice that runs against traditional management and development wisdom. That is probably a large part of what makes it so much fun to read! It also has detailed, extremely implementable suggestions about how to write contracts without becoming trapped in overly restrictive and ultimately counterproductive business relationships. This would be a great book to give to a new software manager or entrepreneur as a primer on what to look for and think about when leading a team for the first time, and a terrific book to leave on the chair of an established manager who perhaps has gotten a little too enamored of measurement tools. The exercises would work well in a technology-oriented graduate management program as role-playing exercises or structures to use in reviewing case studies of successful or failed software projects. Online Computing Reviews Service

Reviewer: Will Wallace

An excellent foundation is presented in this book for anyone wanting to implement agile software development practices. Authors Mary and Tom Poppendieck present seven principles and 22 thinking tools to help readers develop agile practices. Principles are universal concepts, applying to any discipline. It is sometimes difficult, however, to see how these concepts can be used in a particular discipline. In contrast, practices are the procedures used to implement principles. Principles can be applied to many disciplines, as long as they are translated into workable practices. Lean principles have been used and refined in such areas as manufacturing, health care, and construction. But applying these principles to a new discipline requires a change in thinking and environment. Many software managers and developers will be reluctant to consider implementing these principles because manufacturing practices, not principles, have been inappropriately applied to software development in the past. The first principle presented in the book is "eliminate waste." Waste is anything that doesn't add to customer-defined value. This is a concept many IT professionals will have trouble adopting; they have spent many years knowing what the user needs better than the user. For the user to use the product, however, and not put it on the shelf to gather dust, the user, or a user representative, needs to be a key player in the project. The next principle is "amplify learning." The example of a master chef is used to help explain this principle. A chef makes many iterations of a recipe before it is finalized. This is a process of exploration, discovery, and learning. This concept can be applied to software development to provide more than one possible design for a project. This leads to the third and fourth principles "decide as late as possible" and "deliver as fast as possible." By making critical design decisions as late as possible, fewer changes are needed in the design. By using iterative development, working software can be delivered to demonstrate the current understanding of the project. This allows users, designers, and developers to adapt the design to a changing understanding of what features provide the most business value. "Empower the team" is the fifth principle. As the book points out, this is very counter-intuitive for the majority of software development managers. The best way to get the best results is to let the people with the most knowledge of the details make decisions. By allowing a team of front line developers to pool their brainpower and their knowledge of the details, companies can achieve excellence in software development. Integrity is a quality all IT professionals want their products to have, and the sixth principle is identified as "build integrity in." The authors identify two types of integrity: perceived and conceptual. Perceived integrity is how the user sees the software, usually influenced by the usability of the interface. Conceptual integrity is achieved when all of the parts fit together and function seamlessly. The final principle is "see the whole." Many software developers and managers have a tendency to become myopic when dealing with a project. This causes them to focus only on their little piece of the project, and can lead to the problem of suboptimization, optimizing individual parts of the project. While all parts of the project may be optimized, the whole system may suffer performance problems. The project needs to be optimized as a whole to ensure the best system performance. This can be brought about by trade-offs coordinated by a master developer. When the tools identified with each of these principles are used, the probability of success increases. Two of these tools are feedback and refactoring. By getting feedback on the latest design as quickly as possible from the users, developers and users can collaborate on improvements in the design. In refactoring, users, designers, and developers coordinate what features will add the most value, and what should be included in the next iteration. The authors point out several times that applying these principles is not a silver bullet for software development problems within a company. Implementing these principles will require the management to change thinking patterns and the development environment. The book includes an example of how one team within a company had successfully implemented these principles, but was not able to transfer the practice to other teams within the same company. After readers have completed reading and digesting this book, they can move on to one of the other books in the Addison-Wesley Agile Software Development series, to implement one of the agile software development methodologies. In the last chapter of the book, "Instructions and Warranty," the reader is cautioned to use the principles only as directed. The book contains a very functional index. It is a must read for anyone seriously considering a move to one of the agile software development methodologies. Online Computing Reviews Service