Product Description

Presents sound advice for bringing difficult projects to successful conclusion with a minimum of stress. Written for developers and project managers, comparing software development to a game. Softcover.

Product Details

• Amazon Sales Rank: #487929 in Books
• Published on: 2001-10-22
• Original language: English
• Number of items: 1
• Binding: Paperback
• 304 pages

From the Back Cover

Software development paradigms are shifting. The development group's "team" ability, and the effects of the individual developer, become more important as organizations recognize that the traditional approach of increasing process pressure and overworking team members is not meeting getting the job done. The pioneers of Agile methodologies question the preconceived processes within which development teams work. Rather than adding to the burden of the individual developer, Agile asks "how can we change the process so that the team is more productive, while also improving quality?" The answer is in learning to play the "game."

Written for developers and project managers, Agile Software Development compares software development to a game. Team members play the game knowing that the ultimate goal is to win--always remembering what they have learned along the way, and always keeping in mind that they will never play the same way twice. Players must keep an open mind to different methodologies, and focus on the goal of developing quality software in a short cycle time.

Based on a decade's work and research, and interviews with software project teams, this book presents sound advice for bringing difficult projects to successful conclusion with a minimum of stress. It includes advice on:

Customer Reviews

People over Process, Interactions over Tools
Every fifteen years or so, a great book pops up that describes what
projects are really like. There was Brooks, then DeMarco and Lister,
and now there's Cockburn.

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.

The Articulation of Higher Awareness
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

This book has changed my mind - to some extend...
When I started reading this book I was not a fan of XP, but certainly in favour of lighter methodologies. The book is unusual (amongst IT books) in the sense that it starts off with patterns of human communication. In fact the first three chapters - which analyses game-play, individual communication modes, and team cooperation - covers about 40% of the book. However, it was this section of the book that won me over and convinced me about the basis of the "methodologies" such as XP.

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.