Rating: 
Summary: The most important book since "The Mythical Man-Month"
Review: "Agile Software Development" is easily the most important book on software development since Brooks' "The Mythical Man-Month".
Cockburn's insights on the nature of software development are invaluable in understanding why the software industry faces project failure rates of 50% (or greater) and what can be done to turn this around.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.
Rating:
Summary: The most important book since "The Mythical Man-Month"
Review: "Agile Software Development" is easily the most important book on software development since Brooks' "The Mythical Man-Month".
Cockburn's insights on the nature of software development are invaluable in understanding why the software industry faces project failure rates of 50% (or greater) and what can be done to turn this around. 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.
Rating:
Summary: Thought provoking - keep it light weight when you can
Review: Agile Software Development is one of 5 books in the Agile Software Series under the auspices of the non-profit Agile Alliance. This Alliance was created by some of the leading experts in software design and it's mission is to enable software professionals to develop cost-effective applications. There is no "one size fits all" methodology, but a number of different techniques that can be applied as circumstances warrant. The details of the more robust methodologies are covered in texts covering the specific methodologies. The impetus for this approach came from the realization that more was not better. A common statement from successful project teams was: "...what we want to express doesn't get captured in ... models...(it's) what we say to each other while drawing on the board." From this Cockburn found "...successful teams were still delivering software without using our latest energy-saving ideas... a well-functioning team of adequate people will complete a project almost regardless of the process or technology..." Cockburn gives his recommended standard methodology structure of 13 inter-related elements as well as a discussion of Agile Techniques and his own Crystal Methodology. Cockburn stresses the human equation as well as using tools that are appropriate to the circumstances - i.e., the particular project and available resources. Tucked away in the Appendices are more gems. Appendix A covers The Agile Alliance group and it's Agile Software Development Manifesto - a 12-point summary of key principles. Appendix B has brief summaries of three interesting works along with Cockburn's commentaries: Peter Naur's 1985 article, Programming as Theory Building, Pelle Ehn's now out of print, Work-Oriented Development of Software Artifacts, and 17th- century samurai Miyamoto Musashi's The Book of Five Rings. The book contains a wealth of information for the experienced designer or programmer; it is not a book for beginners. Cockburn ends his commentary of Ehn "...I evidently wasn't ready to read very many of his words in 1993...(I) wonder how many other concepts he mentions, but which I haven't yet noticed. I hope you take the time to reread this article in another year or two." I would suggest that Agile Software Development be reread every year or two also.
Rating:
Summary: Thought provoking - keep it light weight when you can
Review: Agile Software Development is one of 5 books in the Agile Software Series under the auspices of the non-profit Agile Alliance. This Alliance was created by some of the leading experts in software design and it's mission is to enable software professionals to develop cost-effective applications. There is no "one size fits all" methodology, but a number of different techniques that can be applied as circumstances warrant. The details of the more robust methodologies are covered in texts covering the specific methodologies. The impetus for this approach came from the realization that more was not better. A common statement from successful project teams was: "...what we want to express doesn't get captured in ... models...(it's) what we say to each other while drawing on the board." From this Cockburn found "...successful teams were still delivering software without using our latest energy-saving ideas... a well-functioning team of adequate people will complete a project almost regardless of the process or technology..." Cockburn gives his recommended standard methodology structure of 13 inter-related elements as well as a discussion of Agile Techniques and his own Crystal Methodology. Cockburn stresses the human equation as well as using tools that are appropriate to the circumstances - i.e., the particular project and available resources. Tucked away in the Appendices are more gems. Appendix A covers The Agile Alliance group and it's Agile Software Development Manifesto - a 12-point summary of key principles. Appendix B has brief summaries of three interesting works along with Cockburn's commentaries: Peter Naur's 1985 article, Programming as Theory Building, Pelle Ehn's now out of print, Work-Oriented Development of Software Artifacts, and 17th- century samurai Miyamoto Musashi's The Book of Five Rings. The book contains a wealth of information for the experienced designer or programmer; it is not a book for beginners. Cockburn ends his commentary of Ehn "...I evidently wasn't ready to read very many of his words in 1993...(I) wonder how many other concepts he mentions, but which I haven't yet noticed. I hope you take the time to reread this article in another year or two." I would suggest that Agile Software Development be reread every year or two also.
Rating: 
Summary: Brutal, boring, redundant, stay away
Review: Agile Software Development is one of the few software books that I would return. It is full of abstract fluff (which is repeated in several different ways). This reminds me of an academic textbook. Just take a simple concept and invent some terminology to wrap around it in several different ways. I can't stand the author's writing style. Better make the coffee strong or this one will put you to sleep. Get an XP book or one of Steve McConnell's books on software design and methodologies instead, this one stinks. ...
Rating:
Summary: People over Process, Interactions over Tools
Review: 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.
Rating:
Summary: Best book on "light" software development methodology
Review: 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.
Rating:
Summary: Best book on "light" software development methodology
Review: 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.
Rating:
Summary: Best book on "light" software development methodology
Review: 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.
Rating:
Summary: Fluffy, Arrogant, Wrong Title
Review: I am suprised to see so many 5 star reviews. They must be friends with the author, or very ignorant. I just finished reading half of this text tonight (about 125 pages, over the course of a few months), and I plan to go no further with it. I was planning on finishing it but I just can't stand reading it. I skimmed the rest, finding the same drab boring text throughout. First off, the author is very cocky, and attempts to demonstrate his superior "level 3" attitude throughout the text. This can be very annoying to read. Second, the text is written as if it were a thesis. He makes -constant- references to other texts such as (Shmo, Software Engineering). Write something original already! Sometimes it's important to make references, but he makes so many of them that the text itself appears to me as just a collection of references. Further, several times throughout the text he makes...references to his own texts such as (Alistair, Crystal Clear). Not only that but he makes references to texts that he has not written yet! (e.g. Alistair, Text, forthcoming) Also, this text should perhaps be more accurately titled 'Analysis of Software Methodologies'. The first part of the text contains extremely generalistic fluff, where the author puts down the reader in so many subtle ways. The next part of the text provides an analysis of various practices that are used in methodologies, which is partially useful, but the text is written in such an annoying and undigestible manner that it gives me this sick feeling when reading it. The third part of the text provides examples of actual methodlogies, but is too general to be of any practical use. Despite not liking this text several dozen pages in, I made a real attempt at finishing it since I paid for it, but I just can't finish it. This text just doesn't work for me. I dislike the author's writing style and I would not recommend it to anyone. From what I read so far, the useful portions of this text can be boiled down to a few HTML pages on a website. This text is no 'masterpiece' as another reader put it. He must be friends with the author. If you're looking for a true masterpiece read The Pragmatic Programmer by Andy Hunt and Dave Thomas... a truly intelligent and practical text!
| 
