Agile Software Development

Rating:
Summary: Excellent!
Review: If you embrace XP methods or traditional engineering concepts this book is definately worth reading. Much of the content the author presents is the _why_ not the _how_ of software methodologies. The information is much more surprising then one might think. If you are looking for a step by step presentation of how to develop software then this is not for you. If you are looking to improve current practices and leverage your existing systems then this is an excellent choice. You will be left with an understanding of how, why and when different software practices work and the trade-off's involved.

Rating:
Summary: The Articulation of Higher Awareness
Review: In Agile Software Development, Alistair Cockburn has quietly authored a masterpiece. With extraordinary insightfulness and encompassing perspective, Cockburn writes of fundamental truths around the business of software development, the people and teams involved, and the nature of methodology.

This book will give you vocabulary and concepts to communicate what you experience on your projects: what software development is all about, the importance of people and their motivations and traits, the adequacy of communication within your team community, and the appropriateness of your methodology for your context.

The first in a series based on the idea that different projects need different methodologies, and that focusing on communication and community is more relevant than focusing on process, the book is primarily concerned with what *is* methodology - and what identifies agile methodology, in particular.

Cockburn begins with the premise that communication is never perfect or complete - and therefore one task of your methodology, which amounts to the set of conventions your team follows, is to ensure that communications are optimal for the purposes at hand.

But what are the purposes at hand? Cockburn adeptly uses the metaphor of game theory to accurately characterize software development as "a cooperative game of invention and communication", whose primary goal is to deliver useful, working software, and whose secondary goal is to prepare for continued play. In so doing he reflects thoughtfully on the characterization of software as engineering, and derides the characterization of software as model-building - observing, thankfully, that building models is not the purpose of the game. The purpose of the game is delivering software.

This characterization frames the book's discussion, which builds in well-considered progression from people, to teams, to methodology, to agility. In a chapter about people, Cockburn stands upon the shoulders, and extends the vision, of giants such as Weinberg, and DeMarco and Lister, finding that people factors predict project outcome much more reliably than choice of process or technology. His treatment of people's motivations, in particular, is the most enlightened to be found outside the leadership literature.

That people participate in teams leads to the next chapter's thorough analysis of communication within teams, and examination of teams as communities. Cockburn implies that a project's rate of progress is a function of how long it takes information to get from one person's mind to another. Through comparison of different seating arrangements and communication modalities, he substantiates the implication and raises the issue of the permanence of communication. To the extent that the people on a team pull in the same direction, they form an effective community defined by "amicability" and "citizenship" - words and definitions provided by Cockburn that are a welcome addition to our vocabulary.

Coordinating a team's activity is the task of a methodology, which is subject of the book's final three chapters. The first of the three lays out a conceptual model of what methodology *is*, in terms of elements of methodology and relationships between elements. It goes on to define the scope of a methodology, and to put forth terms, such as "weight" and "tolerance", that can be used to describe a methodology. It addresses how to publish a methodology. Then Cockburn discusses a number of principles involved in the design of methodologies, and consequences of those principles. Of particular interest is a model for characterizing projects, on which to base the selection of a methodology for a project. This chapter concludes with an examination of Extreme Programming in light of the vocabulary and concepts Cockburn develops.

The second of the three methodology chapters discusses agile methodologies, and what identifies them. Included are recommendations for documentation, an interesting contrast of open-source development to commercial development (it's a different kind of game), and a prescriptive technique for selecting and adapting a methodology on a project. Along the way Cockburn suggests a good definition of software development project success (at least, from a methodological perspective), and thankfully debunks some of the broken thinking that is prevalent in our industry today -specifically, around outsourced overseas development.

The last of the three methodology chapters introduces Cockburn's own family of methodologies, the Crystal Methodologies, each of which corresponds to a particular space within the project characterization model.

Three appendices are included, of such significant content that they can hardly be considered an afterthought. The first discusses The Agile Software Development Manifesto, a product of seventeen advocates of "lightweight" development processes who gathered in early 2001 to discuss what they might have in common. Cockburn was party to the meeting and the manifesto, and in the first appendix provides his own report on the meeting and interpretation of the group's values and principles.

The second appendix excerpts and annotates earlier works, of other authors, that are significantly germane to Cockburn's arguments. One of these is by Peter Naur (of Backus-Naur Form), titled "Programming as Theory Building". In the vein of communication, Cockburn writes that "Using Naur's ideas, the designer's job is not to pass along the design, but to pass along the theories driving the design. The latter goal is more useful and more appropriate." Another excerpt is from The Book of Five Rings by Miyamoto Musashi, a 17th-century Japanese samurai who never wrote software, but whose words apply as equally to software development methodology and tool schools today as they did to martial arts schools in 17th-century Japan.

The third and final appendix is a bibliography of 65 entries.

Taken as a whole, the chapters and appendices form a seminal book on methodology that promises to have significant influence within our industry. Agile Software Development is an epiphany for the field of software development. Buy it. Read it. Use it. Urge the people on your teams to do likewise, that you may discuss methodology with higher awareness, and adjust yours to be appropriately agile. For, as Alistair writes, "software developers should come to know this material simply as part of being in the profession".

Randy Stafford
Chief Architect
IQNavigator

Rating:
Summary: Teaches you how to be successful
Review: In this book, Alistair Cockburn gives amazing insight into what successful software development is all about. It is an essential read for anyone involved in a software development project.

The "successful" word is very important - I have read many books on software development that provide helpful techniques and methodologies, but don't really have much bearing on the success of your project. I have seen specific techniques and methodologies applied extremely successfully in some teams on some projects, and really poorly for others. Personally, I am interested in being very successful in every project I embark on, and Cockburn's book is the only one I have ever read that contains everything you need to know to be successful every time. It is the essence of software development.

Over the years I've developed a good feel for how a great project runs, but have found it remarkably hard to communicate what it is that makes the difference between successful and failed projects. I was delighted to find that Alistair Cockburn has worked out how to articulate the difference and how to make sure that your projects are the successful ones.

For anyone that has done the hard yards through real-world software development projects where time-to-market is a crucial factor, you will be overjoyed when reading this book. You will find you now have a vocabulary to use when talking to others about your projects. After every chapter you will find yourself bursting with excitement to tell someone about what you have learned. The book will change the way you look at your projects and will give you the key to being successful.

For novices to software development, read this book and count yourself lucky that you found it right at the start of your career. The amount you will gain from Cockburn's insight is immeasurable.

Rating:
Summary: Just the preface alone...
Review: Just the preface alone has more valuable information for anyone in the software development arena, than any other book I know of and/or read! Cockburn did his homework! After reading the preface alone, I felt the book was worth more than its purchase price.

Rating:
Summary: Agile Methods Dissected
Review: Review Summary : the broad sweep of the human psychological team element classifies this book as useful beyond software in understanding teams and peoples motivations.
Review: Agile Software Development is a highly stimulating and rich book. The author has a deep background and gives us a tour de force of the emerging �agile� methods. He is neutral, in spite of being the developer of agile methods himself. He gives a large number of interesting case studies from his own practice. He is practical not �academic� and never boring. He is systematic but keeps it simple. He keeps reminding us of the human element, in great depth. And to top it off he offers an appendix by Musashi, a 17th Century samurai �who never wrote software�. This book, while focussed on the programming activity, has a great deal of systems engineering insights about how people work together and various types of human communication. His international experience is a relief from the USA-centric view of too much of our technical literature. I can heartily recommend this book to my friends.
[e-mail], August 24 2002

Rating:
Summary: Agile Methods Dissected
Review: Review Summary : the broad sweep of the human psychological team element classifies this book as useful beyond software in understanding teams and peoples motivations.
Review: Agile Software Development is a highly stimulating and rich book. The author has a deep background and gives us a tour de force of the emerging 'agile' methods. He is neutral, in spite of being the developer of agile methods himself. He gives a large number of interesting case studies from his own practice. He is practical not 'academic' and never boring. He is systematic but keeps it simple. He keeps reminding us of the human element, in great depth. And to top it off he offers an appendix by Musashi, a 17th Century samurai 'who never wrote software'. This book, while focussed on the programming activity, has a great deal of systems engineering insights about how people work together and various types of human communication. His international experience is a relief from the USA-centric view of too much of our technical literature. I can heartily recommend this book to my friends.
[e-mail], August 24 2002

Rating:
Summary: A signficant achievement
Review: The consensus is that this work is a masterpiece. I, as a real-time, embedded software development manager have tried a variety of "heavy" methodologies. Experience has shown me that the lighter techniques have a better chance of success.

I would like to mention Cockburn's reference to Wittgenstein. Wittgenstein started out with a little masterwork usually known as the 'Tractatus Logico-Philosophicus' in English. This book can be viewed as relating the real world to a LOGICAL model. Wittgenstein later realized that this does not necessarily hold and came up with the idea of 'language games.'

The 'heavy' methodologies (B-method, RUP, MIL-STD-498, etc.) try to build a conceptual machine that accepts an input and reliably delivers the desired output. The 'language game' is top-heavy and frequently irrelevant, not to mention, expensive.

The 'light' methodologies use the minimalist principle of Musashi (quoted in the book): "Do not do anything useless."

I could rave on. Try this book out--it is one of the most intelligent software books I have read in years!

Rating:
Summary: Good agile overview, but a bit longer than it needs to be
Review: The high points were all of the great attitude around how to tune a methodology to your specific team, project, and environment. It emphasizes a lot of the crucial points around the people differences that are critical to success.

The downside is that a cover-to-cover reading will feel a bit belabored; the point could've been made in a bit less space. Especially noticiable were the places where sections had been copy/pasted from earlier sections of the book. I can see where it adds to random-search readability, but the third time I read the same anecdote, I was feeling a bit abused.

Also, there was a very interesting framework around 'levels of criticality' that I was really interested in. However, he had one category that implied loss-of-life. Okay, I got that. Then, later in the book, he talks about categorizing a financial project (that nowhere involved mafia hitmen) as that level! I guess I understood the analysis process, but the labeling of the levels totally lead me down the wrong path. I was thinking space shuttle, and he went RC racer. Not necessarily a bad thing, but I left the book not too confident that I was as grounded in the categorization process as I could've been.

Rating:
Summary: Treating a software team as an art commune
Review: There is a lot of sensible advice in this book, the most important of which is "if you have a system that works, use it." I have read many books on software development over the years and have slowly been moving towards a conclusion that is inconsistent with current development strategies. Namely, software development will never advance to the highest levels until the principle of software engineering is dropped. Using that phrase, we try to make people interchangeable parts and think of development as a process similar to changing to a thicker steel beam or adding a few more inches of concrete to a wall based on the examination of formulas. That is nonsense, people are spontaneous, imaginative and creative at irregular and largely unpredictable intervals.
Software development is much more like the writing of novels than it is the building of a bridge, so we should plan our development that way. Set down a general story line, but let each individual page and paragraph be crafted with only the general story in mind. It is this theme that endeared me to this book. Over and over, the authors talk about "funky people", those contradictory but productive creatures that can thrive in one environment but have their creativity shrivel in others. As I read the book, my impressions were that the authors were describing the management of a communal colony of artists, commissioned to create a series of artworks. Soft communication is the order of the day, and each participant naturally gravitates to their area of expertise. They use the metaphor of how heat radiates from an air duct to describe how project information naturally flows to and through the members of the team. As a participant in far too many of the meetings where information transfer was hard in more ways than one, I definitely vote for their techniques.
Agile software development is more than just a mechanism for making software so that you have the ability to make changes rapidly. It is also designed to treat people as individuals and a software project as a form of art. Many of the rigid tenets so beloved by some practitioners of software engineering and methodology madness are rejected in favor of more sensible approaches. I strongly recommend that this book be part of your reading over the next month if you are in the first stages of a software project. Quite frankly, if you are in the later stages of one, reading it might depress you.

Rating:
Summary: Individuals and interactions over processes and tools
Review: This book is often compared with "The Mythincal Man-Month" by Brooks or "Peopleware" by DeMarko and Lister. While Brooks mostly emphasize that the term "man-month" can't be applied to software development, DeMarko and Lister focus to productive environment and jelled teams, Alistair Cockburn with the book "Agile Software Development" covers much wider area, including the choice of the right methodology, problems of individuals and aspects of communication.

The author has found the common denominator among all "agile" methodologies like Extreme Programming, SCRUM, Crystal Clear, Responsibility-Driven Design and Adaptive Software Development.

That common denominator is individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The book describes how to accomplish that, not only describing the problems and encouraging to put some attention into that, but gives some advices that can be found valuable.

The author recommends that each project should have its own methodology, that fit its best. The author have methodologies to recommend for large and very large projects as well.

I recommend "Extreme Programming" by Kent Beck and "Adaptive Software Development" by James A. Highsmith in addition to this book.