Browse Books

Reviewer: Anne Gunn

This is one of the two anchor books in the Agile Development Series, published by Addison-Wesley. The series is edited by Alistair Cockburn, the author of this book, and Jim Highsmith, who recently published the other anchor book, Agile software development ecosystems [1]. The official series has, as of this writing, five titles, including Cockburn’s Writing effective use cases [2] and Surviving object-oriented projects [3]. But there’s also a larger virtual series (if you ignore publishers) that includes Highsmith’s own Adaptive software development [4], Scott Ambler’s Agile modeling [5], Martin Fowler’s Refactoring [6], and all the books on extreme programming (XP). The series is tied together by the tenets of the Agile Alliance (www.agilealliance.org). The alliance, started by 17 practitioners of “lightweight” development methodologies, maintains the Agile Manifesto (www.agilemanifesto.org), a document that records their agreement on four core values, prioritizing: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan. In this book, Cockburn lays out the practical and theoretical foundations for the agile movement. He has been “collecting” methodologies for 20 years, both by using many himself, and by debriefing development teams. His criteria for a “methodologically successful project” are minimal: The project...went out the door and was useful. The leadership...didn’t get fired for what they were doing. The people on the project would work the same way again. Even so, Cockburn claims to have only found a handful of successful methodologies. This has led him to believe that the methodology has to be tailored to the project and the team, not the other way around. The introduction and first chapter of the book are pretty abstract. They argue that, rather than trying to fit software development into an engineering paradigm, it is most useful to characterize it as “a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal...is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system.” The second and third chapters remind us that it is “people who design software” and that we have to take their strengths and weaknesses into account if we are going to meet our business objectives. These chapters, which talk about the ways in which people are “funky,” how they prefer to fail, and what exactly they are good at, are the most entertaining of the book. They also have the most in common in spirit and tone with the other books in the virtual series mentioned above: what makes great team s work is not radical new techniques, but many small things done right. Principals like increasing communication, decreasing distractions, and helping team members pull in the same direction rather than in different directions, are the building blocks of agile software development. The long fourth chapter is about methodologies: how they are designed, how to evaluate a candidate methodology for applicability to your project, and how to tweak it once you’ve started. I have to admit that in the middle of this chapter, I had a moment where I had to think hard about why I cared. I don’t design methodologies for a living, I build software. But Cockburn argues that anyone who uses any methodology has to be willing and able to modify it from time to time, or at least from project to project. Although each chapter ends with a short section that focuses on real-world issues, chapters 5 and 6 are all about trying to put the principles of the earlier chapters into practice. Chapter 5 does this in very generic terms, with an emphasis on periodic reflection and adjustment as critical components for success. Chapter 6 is a brief introduction to Cockburn’s Crystal methodologies, a “copy-and-alter family of methodologies that can be tailored on each project.” A forthcoming book in the series will cover the Crystal methodologies in detail. Appendix A presents the Agile Manifesto in its entirety, along with a discussion of its origin and intent. Appendix B soars into the ideas behind the book, with extracts from two very philosophical works, and from the Japanese samurai tract, The Book of Five Rings . Appendix C is a thorough pair of indices to reference material, organized both by title and by author. An unusual feature of the book is a “List of Stories” in the front of the book, and good indexing into the stories. When you want to find the story that uses backyard dandelions as a parable for explaining why constructing a successful reward structure is always hard, you just look for dandelions in the index. Online Computing Reviews Service

Reviewer: Puneet Singh Lamba

Software development organizations understandably yearn for a one-size-fits-all software development methodology. It would certainly be wonderful to have one methodology to master that could be applied consistently to all projects. Consequently, the major methodologies are constantly jockeying to project themselves as agile enough to be applicable to any type of project. The heavyweight methodologies, such as the rational unified process (RUP), are eager to demonstrate their flexibility in response to the challenge posed by lightweight or agile methodologies. As Jim Highsmith recently noted, “No one is willing to concede ‘agility’ to the other side” [1]. However, as children learn at a relatively young age, square pegs just do not fit nicely into round holes. More often than not, organizations run their projects using methodologies that they are comfortable with, as opposed to those that are best suited for the project at hand. Cockburn’s thoughtful book has a very sensible solution for organizations that have struggled to find methodologies that fit their projects like a glove: roll your own. In other words, learn about what methodologies are and how to construct them so that you can create methodologies custom tailored to your projects. In support of Cockburn’s approach, Robert Glass writes, “Because software tackles such a diverse assortment of problems, it is becoming more and more obvious that there are few, if any, universal solution approaches” [2]. Glass lists four criteria that influence the diversity of a software development project: size, application domain, criticality, and innovativeness. Plauger says it best: “anyone who believes that one size fits all belongs in a pantyhose commercial” [3]. Rather than recommend a one-size-fits-all methodology, the author encourages each project team to define their own unique methodology by borrowing some standard ones that fit and inventing new ones. He presents the why as opposed to the how of software methodologies. Once you understand why certain methodologies work well in certain situations, you are equipped to determine which methodologies suit your project. He also lists a set of principles to enable a cost and benefit analysis for moving to heavier methodologies. Furthermore, even once a methodology has been determined, the author recommends constant flexibility and just-in-time tuning to achieve maximum benefit. This book makes a significant contribution in two major areas of software development. First, it presents a tour de force of emerging agile software development methodologies. Second, it is a worthy successor to pioneering works in the psychology of software development by Weinberg [4], and DeMarco and Lister [5]. In a broad sweep of the human psychological element, Cockburn discusses numerous promising approaches, including how to align a project with the success factors of individuals working on the project, practical methods for removing latency in communication, and coming to terms with the fact that people are imperfect and make mistakes, often at crucial moments. Cockburn defines three levels of learning: following, detaching, and fluent. These learning levels apply to most human activities including listening, reading, and understanding methodologies. Those at level 1 (following) require specific advice. Level 2 (detaching) is about exploring the boundaries of the rules learned at level 1. Finally, level 3 (fluent) entails moving with freedom without regard to the rules. This book targets level 2 and 3 readers and practitioners. The book attempts to synthesize the common denominator among agile methodologies like extreme programming (XP), Scrum, Crystal Clear, responsibility-driven design, and adaptive software development. This common denominator, also documented in the agile software development manifesto, is as follows: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. The author suggests that software development is much more like writing a novel than building a bridge. Projects should set down a general storyline but create each chapter and page creatively. Cockburn implies that a project’s rate of progress is a function of the length of time for information to flow from one mind to another. He stresses the importance of managing the incompleteness of our communications. Therefore, a phone call is preferable to email, and a face-to-face conversation is preferable to a phone call. While Cockburn acknowledges XP’s limitations with respect to larger teams due to its reliance on tacit knowledge, he also offers ideas on how to reinvent XP for larger teams. The two insightful works that Cockburn includes as appendices to his book are the icing on the cake. In Cockburn’s words, Peter Naur’s 1985 paper, “Programming as theory building,” is “the most accurate account of what goes on in designing and coding a program.” The second appendix contains extracts from Pelle Ehn’s works, which Cockburn credits for having inspired many of his own ideas and thoughts. Online Computing Reviews Service