Agile Software Development

by Alistair Cockburn

Book Overview

The agile model of software development took the world by storm in 2001. By 2002, there were books and conferences on agile development. By 2006, it has influenced everything from procurement... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0201699699
• ISBN13: 9780201699692
• Release Date: January 2001
• Publisher: Addison-Wesley Professional
• Length: 278 Pages
• Weight: 1.19 lbs.
• Dimensions: 0.6" x 7.4" x 9.2"

Customer Reviews

Best book on "light" software development methodology

Excellent book on software development, but this book is not for everyone. As Cockburn mentions in the preface and the introduction chapter, the book is for "level 2 and 3" people who already have some experience managing software projects, who can think from a higher level and can better appreciate the whole eco-system of software development. This book does not talk about detail implementation of software development methodologies, but rather focuses mostly on the people dynamics of software projects. From that Cockburn presents his agile methodologies and how we can adopt them for different types of projects. A central theme of agile software development is the focus on people's communication and skill rather than procedure and documentation. "Discipline, skills, and understanding counter process, formality, and documentation," as Cockburn puts it. Although the first 4 chapters are fairly high level, chapter 5 "Agile and Self-Adaption" summarizes the principles and offer concrete steps on how to put everything to use in actual projects. I found it extremely helpful.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.

Treating a software team as an art commune

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.

A signficant achievement

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!

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

People over Process, Interactions over Tools

Every fifteen years or so, a great book pops up that describes whatprojects 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 becausethe message they contain isn't the easy-to-digest dictate: "run yourproject this way and everything will be fine." Instead these books allfocus on the fundamentals of projects: people and the way they worktogether. These books treat people as people, and not replaceableparts in a process. The books accept people's foibles andinconsistencies, and work out how to work with them, rather than howto try to stamp them out. The books ask: how can we help these funkypeople work better together to produce great software?Agile Software Development has some great answers, which makes it asignificant book. It deals with the issue that programming isessentially communicating. It looks at the success factors ofindividuals, and how to help align the project with these. Itdiscusses practical ways to reduce the latency of communication (doyou know how much each extra minute taken finding things out costs ona 12 person project? How do you line your walls with informationradiators?) The book mines the metaphor of development as acooperative team game, and looks at development organizations as acommunity, where good citizenship pays.So how _do_ you organize all these people, these team players, thesecitizens? The answer is with methodologies. But not with something youbuy off-the-shelf. Cockburn argues that teams should work to define,and then refine, their own methodologies, bringing in standard oneswhere they fit. To help the teams, he has a wonderful sectiondescribing what methodologies _are_, and how to build them. This isgood, solid, practical advice. He talks about when it's good to belight, and when you need to be heavier, when laissez-faire works, andwhen you need ceremony to reduce risks. Then, not content with helpingyou create a methodology, Cockburn explains how to adapt what you haveto a changing world.If you work in or with a team developing software, then you owe it toyourself (and your team) to read this book. You'll come away with afar clearer understanding of the dynamic at work in your team, andwith lots of ideas for improving it. And that's the whole point.