Customer Reviews

Agile Software Development

People over Process, Interactions over Tools, November 18, 2001

By	Dave Thomas "pragdave" (TX USA) - See all my reviews

Why is there such a gap between these great books? Possibly because
the message they contain isn't the easy-to-digest dictate: "run your
project this way and everything will be fine." Instead these books all
focus on the fundamentals of projects: people and the way they work
together. These books treat people as people, and not replaceable
parts in a process. The books accept people's foibles and
inconsistencies, and work out how to work with them, rather than how
to try to stamp them out. The books ask: how can we help these funky
people work better together to produce great software?

Agile Software Development has some great answers, which makes it a
significant book. It deals with the issue that programming is
essentially communicating. It looks at the success factors of
individuals, and how to help align the project with these. It
discusses practical ways to reduce the latency of communication (do
you know how much each extra minute taken finding things out costs on
a 12 person project? How do you line your walls with information
radiators?) The book mines the metaphor of development as a
cooperative team game, and looks at development organizations as a
community, where good citizenship pays.

So how _do_ you organize all these people, these team players, these
citizens? The answer is with methodologies. But not with something you
buy off-the-shelf. Cockburn argues that teams should work to define,
and then refine, their own methodologies, bringing in standard ones
where they fit. To help the teams, he has a wonderful section
describing what methodologies _are_, and how to build them. This is
good, solid, practical advice. He talks about when it's good to be
light, and when you need to be heavier, when laissez-faire works, and
when you need ceremony to reduce risks. Then, not content with helping
you create a methodology, Cockburn explains how to adapt what you have
to a changing world.

If you work in or with a team developing software, then you owe it to
yourself (and your team) to read this book. You'll come away with a
far clearer understanding of the dynamic at work in your team, and
with lots of ideas for improving it. And that's the whole point.

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

The Articulation of Higher Awareness, December 2, 2001

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

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

This book has changed my mind - to some extend..., May 6, 2002

But for me personally the most practical and relevant chapter was Chapter 5: "Agile and self-adapting". In this chapter Cockburn covers issues such as how much documentation, team structures, and most importantly: a methodology growing technique. This chapter is closely followed in importance by chapter 4: "Methodologies". In this chapter Cockburn covers methodology concepts and design principles, including how to publish and introduce (role out) a methodology (before going on to dissect XP). Chapter 6: "The crystal methodologies" consolidates these ideas. Cockburn takes you along while describing and shaping his family of Crystal methodologies.

The book is rounded of with the agile software development manifesto, a formal proposal drawn up by several software authors; and philosophical contributions from other authors. Many good references can be found in the appendix.

Cockburn acknowledges that the chosen methodology must fit issues such as the project and team size and environment. And although I can see the benefits of many aspects of the agile philosophy, there are other aspects I am still cynical about. However, my review is not about XP, but about this book. And the book is well written, well argued, sensible, with plenty of stories and examples, which makes it easy to read. In my case, Cockburn was NOT preaching to the converted, and I gained much value from reading the book. It helped me to question some of my preconceived ideas and long-held views.

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

Best book on "light" software development methodology, February 4, 2003

I think the book is especially applicable to small teams (up to ~20 people) working on in-house development (so that the users are close) in organizations with light hierarchy. The book shows us the best way to improve a team is to improve the communication and environment, rather than to impose rules and procedures. However, there are at least two potential problems when deploying these methods. First, in some sense, Cockburn states the obvious: if we have a good team of people in a room with good communication, we will achieve the most efficient development. The problem is it's very hard to have a good team of people in the first place. Also, because of culture differences, this kind of 'light' methodology might not earn good results outside the US, where some people actually prefer heavy procedures and are less proactive in communication. Second, it is very hard to change the mind-set of senior management with little software development experience. Cockburn rightly points out that rules and procedures come out of the insecurity of the upper managers who don't know what's going on in the development team. It's quite hard for them to appreciate an environment that builds on trust and understanding. Cockburn didn't directly address this problem.

One suggestion regarding efficient documentation that I think is extremely useful is to the use of digital camera and video camcorder to record meetings. It's so obvious yet I never thought about it!

A related book I highly recommend is "The Mythical Month" by Brooks, a true classic on software engineering.

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

A signficant achievement, December 20, 2001

By	Janise G. Pries "book-devourer" (El Paso, TX USA) - See all my reviews

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!

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

Individuals and interactions over processes and tools, October 24, 2002

By	Maxim Masiutin (Chisinau, Republic of Moldova) - See all my reviews

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.

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

Worth buying. Gets to the root of the development process., February 1, 2002

This book fills the niche between cookbook approaches to process and zen-like handwaving books. It WILL help you understand the principles behind process and be able to pick the concrete parts of processes that make the most sense for the problem at hand.

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment

The most important book since "The Mythical Man-Month", July 15, 2002

Cockburn sees software development as more art than science. "A Cooperative Game of Communication and Invention" where the individuals on a team and the dynamics within a team influence the success or failure of a project far more than any specific process. The singular, often paradoxical imperfectness of people - what Cockburn refers to as "Failure Modes" - drives software development.

A key premise running throughout Cockburn's book is that people make mistakes - often at the worst possible times - and are often inconsistent in the most frustrating of ways. Yet paradoxically, they are also creatures of habit - both good and bad. They are predictable most times, but unpredictable others (and you never know which times). Most importantly, Cockburn writes, people are different. They think differently; solve problems in different ways; relate to each other differently. Some are emotional while some are stoic. The diversity is breathtaking. Yet most of the tenets of "software engineering" (and the myriad of "formal" processes emenating from these tenets) simply ignore the imperfection of people and the uniqueness of individuals. And we've paid the price for the last 25+ years.

This is not a book for those looking for a step-by-step recipe for success. How could a single approach work anyway? Instead it is a book that sheds a penetrating light on the mistakes of the past and what we can do to correct most of these mistakes.

A must read for any person who has a stake in software development - from senior executive footing the bill to individual developers currenty involved on projects.

Help other customers find the most helpful reviews   Was this review helpful to you?

Report this | Permalink  Comment