Agile Software Development / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 95%)
Other sellers (Paperback)
  • All (19) from $1.99   
  • New (3) from $64.98   
  • Used (16) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$64.98
Seller since 2006

Feedback rating:

(14)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
2001-10-22 Paperback New NEW stated FIRST Printing Oct 2001 Large Softcover Alistair Cockburn [author] Addison-Wesley Publishers 1~*Usually same or next day service with ... possible use of recycled materials by a reliable seller~GUARANTEED~FIVE STAR SELLER~ Read more Show Less

Ships from: Columbia, SC

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$65.00
Seller since 2014

Feedback rating:

(113)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$65.00
Seller since 2014

Feedback rating:

(113)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

"Coming of age for software developers means understanding that software is a cooperative effort, not something individuals do in isolation. This is a book that teams of software developers can thrive upon, full of sensible advice for a cooperative development approach."

--Tom DeMarco, The Atlantic Systems Guild

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:

  • The principals behind agilemethodologies
  • Which methodologies fit different projects--including appendixes to select the appropriate methodology on a project
  • New vocabulary for describing methodologies
  • Just-in-time methodology tuning
  • Managing the incompleteness of communication
  • Continuous methodology reinvention
  • The manifesto for agile software development

Today's software developers need to recognize that they have a number of methodologies to choose from. With this book as a guide, they can break free of nonproductive habits, move beyond old routines, and clear a new path to success.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
Today's most thoughtful programmers are engaged in some pretty deep thinking about software development nowadays. On first glance, some of it looks awfully abstract (but then, that's how most of us reacted to objects and patterns, first time we encountered them). On second glance, this stuff isn't "merely" profound: It can help you get your job done a whole lot better -- starting right now.

Take, for example, Agile Software Development by Alistair Cockburn, the codeveloper of IBM's first object-oriented methodology and creator of the well-respected Crystal family of methodologies. Cockburn, who's interviewed more real-life developers than just about anyone, begins this book about as abstractly as you can get: by proving the impossibility of accurate communication between human beings. (A category that even includes software customers, developers, and the writers of requirement specs!)

If we can't communicate, how can we build software that meets our goals? By "managing the incompleteness of communication." And by considering development as "a cooperative game of invention and communication." What, Cockburn asks, would software development be like if we weren't developing software? Maybe it would be like a community attempting to write epic poetry together: a team made up of both temperamental geniuses and average workers, facing difficult requirements, communications, and synchronization pressures. Or, perhaps, it would resemble a cooperative team of rock climbers facing real danger with limited resources, a careful plan, the flexibility to improvise, a clear goal (the summit), and a driving desire (to have fun on the journey).

Cockburn's metaphors prove extremely fruitful and lead toward a set of powerful insights that each of today's "agile methodologies" seems to be groping towards in its own way. For example, when you think of developers as participants in a cooperative game, you realize they're not the antisocial drudges they've been made out to be. They actually love to communicate, as long as you're talking about something that's technically relevant to them. (Which explains why pair programming is turning out to be far more popular than many pundits expected.)

A software development project is an ecosystem, says Cockburn, "in which physical structures, roles, and individuals with unique personalities all exert forces on each other." Since no two projects share the same collection of forces, no single methodology can possibly fit every project, and none will ever work "straight out of the box." (Which explains why so many attempts to impose a methodology fail so badly.)

"Lightness" is a blessing, but it's possible to be too light. Cockburn shows how to balance lightness against sufficiency, by introducing the "sweet spots" that naturally make software development easier, and helping you compensate where your projects don't quite fit the ideal. (For example, agile methods rely heavily on face-to-face communication, but when your development team is scattered across multiple time zones, how can they be adapted to provide sufficient documentation so that everyone can work together, without sidetracking developers from their primary responsibilities? How can agile methods transform "tacit" team knowledge into long-lasting organizational wisdom?)

Every chapter in this entertaining book ends with a "What Should I Do Tomorrow?" section -- and you really can do this stuff tomorrow, without jumping whole-hog into a specific agile methodology. (Reconsider your work products based on what you need to achieve your primary goal, and to protect the teams that'll follow you. Increase the use of mechanisms that draw on the strengths of the specific individuals on your team. Try arranging for daily visits between programmers and business experts. Give more thought to the bottlenecks that could impact your project, and invent ways to use excess capacity elsewhere in the organization.)

Cockburn concludes by introducing his own Crystal family of methodologies, designed specifically to address the limitations of communication, the centrality of human beings, and the need for diverse methodologies, even within a single project. But whatever methodologies you adopt or reject, this provocative book is likely to transform the way you manage and participate in software development. (Bill Camarda)

Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. He served for nearly ten years as vice president of a New Jersey–based marketing company, where he supervised a wide range of graphics and web design projects. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

Read More Show Less

Product Details

  • ISBN-13: 9780201699692
  • Publisher: Addison-Wesley
  • Publication date: 10/28/2001
  • Series: Agile Software Development Series
  • Edition description: Older Edition
  • Edition number: 1
  • Pages: 304
  • Product dimensions: 7.44 (w) x 9.22 (h) x 0.55 (d)

Meet the Author

Alistair Cockburn is a recognized expert on use cases. He is consulting fellow at Humans and Technology, where he is responsible for helping clients succeed with object-oriented projects. He has more than twenty years of experience leading projects in hardware and software development in insurance, retail, and e-commerce companies and in large organizations such as the Central Bank of Norway and IBM.



0201699699AB07302002

Read More Show Less

Table of Contents

List of Figures
List of Stories
Preface
Introduction: Unknowable and Incommunicable 1
Ch. 1 A Cooperative Game of Invention and Communication 21
Ch. 2 Individuals 41
Ch. 3 Communicating, Cooperating Teams 75
Ch. 4 Methodologies 113
Ch. 5 Agile and Self-Adapting 173
Ch. 6 The Crystal Methodologies 197
App. A The Agile Software Development Manifesto 213
App. B Naur, Ehn, Musashi 225
App. C: Books and References 261
Index 271
Read More Show Less

Preface

Is software development an art, a craft, science, engineering, or something else entirely? Does it even matter?

Yes, it does matter, and it matters to you. Your actions and their results will differ depending on which of those is more correct.

The main thing is this: You want your software out soon and defect free, but more than that, you need a way to examine how your team is doing along the way.

Purpose

It is time to reexamine the notions underlying software development.

The trouble is that as we look at projects, what we notice is constrained by what we know to notice. We learn to distinguish distinct and separable things in the extremely rich stream of experience flowing over us, and we pull those things out of the stream for examination. To the extent that we lack various key distinctions, we overlook things that are right in front of us.

We anchor the distinctions in our memories with words and use those words to reflect on our experiences. To the extent that we lack words to anchor the distinctions, we lack the ability to pull our memories into our conversations and the ability to construct meaningful strategies for dealing with the future.

In other words, to reexamine the notions that underlie software development, we have to reconsider the distinctions that we use to slice up our experience and the words we use to anchor our memories.

This is, of course, a tall order for any book. It means that some of the earlier parts of this book will be rather abstract. I see no way around it, though.

The last time people constructed a vocabulary for software development was in the late1960s, when they coined the phrase software engineering, as both a wish and a direction for the future.

It is significant that at the same time the programming-should-be-engineering pronouncement was made, Gerald Weinberg was writing The Psychology of Computer Programming. In that book, software development doesn't look very much like an engineering discipline at all. It appears to be something very human-centric and communication-centric. Of the two, Weinberg's observations match what people have reported in the succeeding 30 years, and software engineering remains a wishful term.

In this book, I will

  • Build distinctions and vocabulary for talking about software development
  • Use that vocabulary to examine and anchor critical aspects of software projects that have been pushed to the sidelines too often
  • Work through the ideas and principles of methodologies as "rules of behavior"
  • Merge our need for these rules of behavior with the idea that each project is unique, and derive effective and self-evolving rules

I hope that after reading this book, you will be able to use the new vocabulary to look around at your project, notice things you didn't notice before, and express those observations. As you gain facility, you should be able to

  • Discuss Extreme Programming, the Capability Maturity Model, the Personal Software Process, or your favorite process
  • Determine when each process is more or less applicable
  • Understand people who have differing opinions, abilities, and experience

Audience

Each person coming to this book does so with a different experience level, reading style, and role. Here's how you might read the book to use it to your greatest advantage: by experience, by reading style, or by role.

By Experience

This book is written for the more experienced audience. The book does not contain procedures to follow to develop software; in fact, core to the book is the concept that every technique has limitations. Therefore, it is impossible to name one best and correct way to develop software. Ideally, the book helps you reach that understanding and then leads you to constructive ideas about how to deal with this real-world situation.

If you are an intermediate practitioner who has experience with software-development projects, and if you are now looking for the boundaries for the rules you have learned, you will find the following topics most helpful:

  • What sorts of methodologies fit what sorts of projects
  • Indices for selecting the appropriate methodology category for a project
  • The principles behind agile methodologies

Being an intermediate practitioner, you will recognize that you must add your own judgement when applying these ideas.

If you are an advanced practitioner, you already know that all recommendations vary in applicability. You may be looking for words to help you express that. You will find those words where the following topics are presented:

  • Managing the incompleteness of communication
  • Continuous methodology reinvention
  • The manifesto for agile software development

A few topics should be new even to advanced software developers: the vocabulary for describing methodologies and the technique for just-in-time methodology tuning.

By Reading Style

The earlier chapters are more abstract than the later chapters.

If you enjoy abstract material, read the book from beginning to end, watching the play of abstract topics to see the resolution of the impossible questions through the course of the book.

If you want concrete materials in your hands as quickly as possible, you may want to skip over the early chapters on the first read and start with Chapter 4, "Methodologies." Return to the sections about "Cooperative Games" and "Convection Currents of Information" to get the key parts of the new vocabulary. Dip into the introduction and the chapters about individuals and teams to fill in the gaps.

By Role

People who sponsor software development can get from this book an understanding of how various organizational, behavioral, and funding structures affect the rate at which they receive value from their development teams. Project sponsors may pay less attention to the details of methodology construction than people who are directly involved in the projects. They should still understand the consequences of certain sorts of methodology decisions.

Team leads and project managers can see how seating, teaming, and individuality affect their project's outcome. They can also learn what sorts of interventions are more likely to have better or worse consequences. They will need to understand the construction and consequences of their methodology and how to evolve their methodology—making it as light as possible, but still sufficient.

Process and methodology designers can examine and argue with my choice of terms and principles for methodology design. The ensuing discussions should prove useful for the field.

Software developers should come to know this material simply as part of being in the profession. In the normal progression from newcomers to leaders, they will have to notice what works and doesn't work on their projects. They will also have to learn how to adjust their environment to become more effective. "Our methodology" really means "the conventions we follow around here," and so it becomes every professional's responsibility to understand the basics of methodology construction.

Organization of the Book

The book is designed to set up two nearly impossible questions at the beginning and derive answers for those questions by the end of the book:

  • If communication is fundamentally impossible, how can people on a project manage to do it?
  • If all people and all projects are different, how can we create any rules for productive projects?

To achieve that design, I wrote the book a bit in the "whodunit" style of a mystery. I start with the broadest and most philosophical discussions: "What is communication?" and "What is software development?"

The discussion moves through still fairly abstract topics such as "What are the characteristics of a human?" and "What affects the movement of ideas within a team?"

Eventually, it gets into more concrete territory with "What are the elements and principles of methodologies?" This is a good place for you to start if you are after concrete material early on.

Finally, the discussion gets to the most concrete matter: "What does a light, sufficient, self-evolving methodology look like?" and "How does a group create a custom and agile methodology in time to do the project any good?"

The two appendixes contain supporting material. The first contains the "Agile Software Development Manifesto," signed by 17 very experienced software developers and methodologists.

The second appendix contains extracts from three pieces of writing that are not as widely read as they should be. I include them because they are core to the topics described in the book.

Heritage of the Ideas in This Book

The ideas in this book are based on 25 years of development experience and 10 years of investigating projects directly.

The IBM Consulting Group asked me to design its first object-oriented methodology in 1991. I looked rather helplessly at the conflicting "methodology" books at the time. My boss, Kathy Ulisse, and I decided that I should debrief project teams to better understand how they really worked. What an eye-opener! The words they used had almost no overlap with the words in the books.

The interviews keep being so valuable that I still visit projects with sufficiently interesting success stories to find out what they encountered, learned, and recommend. The crucial question I ask before the interview is, "And would you like to work the same way again?" When people describe their experiences in words that don't fit my vocabulary, it indicates new areas in which I lack distinctions and words.

The reason for writing this book now is that the words and distinctions finally are correlating with descriptions of project life and project results. They are proving more valuable for diagnosis and intervention than any of the tools that I used previously.

The ideas in this book have been through dozens of development teams, eight methodology designs, and a number of successful projects on which I participated.

Agility

I am not the only person who is using these ideas:

  • Kent Beck and Ward Cunningham worked through the late 1980s on what became called Extreme Programming (XP) in the late 1990s.
  • Jim Highsmith studied the language and business use of complex adaptive systems in the mid-1990s and wrote about the application of that language to software development in his Adaptive Software Development.
  • Ken Schwaber and Jeff Sutherland were constructing the Scrum method of development at about the same time, and many project leaders made similar attempts to describe similar ideas through the same years.

When a group of us met in February 2001 to discuss our differences and similarities, we found we had a surprising number of things in common. We selected the word agile to describe our intent and wrote the Agile Software Development Manifesto (Appendix A).

We are still formulating the principles that we share and are finding many other people who could have been at that meeting if they had known about it or if their schedules had permitted their presence.

Core to agile software development is the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules.

Agility implies maneuverability, a characteristic that is more important now than ever. Deploying software to the Web has intensified software competition further than before. Staying in business involves not only getting software out and reducing defects but tracking continually moving user and marketplace demands. Winning in business increasingly involves winning at the software-development game. Winning at the game depends on understanding the game being played.

The best description I have found for agility in business comes from Goldman (1997):

"Agility is dynamic, context-specific, aggressively change-embracing, and growth-oriented. It is not about improving efficiency, cutting costs, or battening down the business hatches to ride out fearsome competitive 'storms.' It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share, and customers in the very center of the competitive storms many companies now fear."

The Agile Software Development Series

Among the people concerned with agility in software development over the last decade, Jim Highsmith and I found so much in common that we joined efforts to bring to press an Agile Software Development Series based around relatively light, effective, human-powered software-development techniques.

We base the series on these two core ideas:

  • Different projects need different processes or methodologies.
  • Focusing on skills, communication, and community allows the project to be more effective and more agile than focusing on processes.

The series has these three main tracks:

  • Techniques to improve the effectiveness of a person who is doing a particular sort of job. This might be a person who is designing a user interface, gathering requirements, planning a project, designing, or testing. Whoever is performing such a job will want to know how the best people in the world do their jobs. Writing Effective Use Cases (Cockburn 2001c) and GUIs with Glue (Hohmann, forthcoming) are two individual technique books.
  • Techniques to improve the effectiveness of a group of people. These might include techniques for team building, project retrospectives, decision making, and the like. Improving Software Organizations (Mathiassen 2002) and Surviving Object-Oriented Projects (Cockburn 1998) are two group technique books.
  • Examples of particular, successful agile methodologies. Whoever is selecting a base methodology to tailor will want to find one that has already been used successfully in a similar situation. Modifying an existing methodology is easier than creating a new one and is more effective than using one that was designed for a different situation. Crystal Clear (Cockburn, forthcoming) is a sample methodology book. We look forward to identifying other examples to publish.

Two books anchor the Agile Software Development Series:

  • This one expresses the thoughts about agile software development using my favorite vocabulary: that of software development as a cooperative game, methodology as conventions about coordination, and families of methodologies.
  • The second book is Highsmith's forthcoming one, Agile Software Development Ecosystems. It extends the discussion about problems in software development, common principles in the diverse recommendations of the people who signed the Agile Software Development Manifesto, and common agile practices. Highsmith's previous book, Adaptive Software Development, expresses his thoughts about software development using his favorite vocabulary, that of complex adaptive systems.

You can find more about Crystal, Adaptive, and other agile methodologies on the Web. Specific sites and topics are included in the References at the back. A starter set includes these sites:

http://www.crystalmethodologies.org
www.AdaptiveSD.com
www.AgileAlliance.org
My home site, http://members.aol.com/acockburn



Read More Show Less

Introduction

Is software development an art, a craft, science, engineering, or something else entirely? Does it even matter?

Yes, it does matter, and it matters to you. Your actions and their results will differ depending on which of those is more correct.

The main thing is this: You want your software out soon and defect free, but more than that, you need a way to examine how your team is doing along the way.

Purpose

It is time to reexamine the notions underlying software development.

The trouble is that as we look at projects, what we notice is constrained by what we know to notice. We learn to distinguish distinct and separable things in the extremely rich stream of experience flowing over us, and we pull those things out of the stream for examination. To the extent that we lack various key distinctions, we overlook things that are right in front of us.

We anchor the distinctions in our memories with words and use those words to reflect on our experiences. To the extent that we lack words to anchor the distinctions, we lack the ability to pull our memories into our conversations and the ability to construct meaningful strategies for dealing with the future.

In other words, to reexamine the notions that underlie software development, we have to reconsider the distinctions that we use to slice up our experience and the words we use to anchor our memories.

This is, of course, a tall order for any book. It means that some of the earlier parts of this book will be rather abstract. I see no way around it, though.

The last time people constructed a vocabulary for software development was in the late 1960s, when they coined the phrasesoftware engineering, as both a wish and a direction for the future.

It is significant that at the same time the programming-should-be-engineering pronouncement was made, Gerald Weinberg was writing The Psychology of Computer Programming. In that book, software development doesn't look very much like an engineering discipline at all. It appears to be something very human-centric and communication-centric. Of the two, Weinberg's observations match what people have reported in the succeeding 30 years, and software engineering remains a wishful term.

In this book, I will

  • Build distinctions and vocabulary for talking about software development
  • Use that vocabulary to examine and anchor critical aspects of software projects that have been pushed to the sidelines too often
  • Work through the ideas and principles of methodologies as "rules of behavior"
  • Merge our need for these rules of behavior with the idea that each project is unique, and derive effective and self-evolving rules

I hope that after reading this book, you will be able to use the new vocabulary to look around at your project, notice things you didn't notice before, and express those observations. As you gain facility, you should be able to

  • Discuss Extreme Programming, the Capability Maturity Model, the Personal Software Process, or your favorite process
  • Determine when each process is more or less applicable
  • Understand people who have differing opinions, abilities, and experience

Audience

Each person coming to this book does so with a different experience level, reading style, and role. Here's how you might read the book to use it to your greatest advantage: by experience, by reading style, or by role.

By Experience

This book is written for the more experienced audience. The book does not contain procedures to follow to develop software; in fact, core to the book is the concept that every technique has limitations. Therefore, it is impossible to name one best and correct way to develop software. Ideally, the book helps you reach that understanding and then leads you to constructive ideas about how to deal with this real-world situation.

If you are an intermediate practitioner who has experience with software-development projects, and if you are now looking for the boundaries for the rules you have learned, you will find the following topics most helpful:

  • What sorts of methodologies fit what sorts of projects
  • Indices for selecting the appropriate methodology category for a project
  • The principles behind agile methodologies

Being an intermediate practitioner, you will recognize that you must add your own judgement when applying these ideas.

If you are an advanced practitioner, you already know that all recommendations vary in applicability. You may be looking for words to help you express that. You will find those words where the following topics are presented:

  • Managing the incompleteness of communication
  • Continuous methodology reinvention
  • The manifesto for agile software development

A few topics should be new even to advanced software developers: the vocabulary for describing methodologies and the technique for just-in-time methodology tuning.

By Reading Style

The earlier chapters are more abstract than the later chapters.

If you enjoy abstract material, read the book from beginning to end, watching the play of abstract topics to see the resolution of the impossible questions through the course of the book.

If you want concrete materials in your hands as quickly as possible, you may want to skip over the early chapters on the first read and start with Chapter 4, "Methodologies." Return to the sections about "Cooperative Games" and "Convection Currents of Information" to get the key parts of the new vocabulary. Dip into the introduction and the chapters about individuals and teams to fill in the gaps.

By Role

People who sponsor software development can get from this book an understanding of how various organizational, behavioral, and funding structures affect the rate at which they receive value from their development teams. Project sponsors may pay less attention to the details of methodology construction than people who are directly involved in the projects. They should still understand the consequences of certain sorts of methodology decisions.

Team leads and project managers can see how seating, teaming, and individuality affect their project's outcome. They can also learn what sorts of interventions are more likely to have better or worse consequences. They will need to understand the construction and consequences of their methodology and how to evolve their methodology--making it as light as possible, but still sufficient.

Process and methodology designers can examine and argue with my choice of terms and principles for methodology design. The ensuing discussions should prove useful for the field.

Software developers should come to know this material simply as part of being in the profession. In the normal progression from newcomers to leaders, they will have to notice what works and doesn't work on their projects. They will also have to learn how to adjust their environment to become more effective. "Our methodology" really means "the conventions we follow around here," and so it becomes every professional's responsibility to understand the basics of methodology construction.

Organization of the Book

The book is designed to set up two nearly impossible questions at the beginning and derive answers for those questions by the end of the book:

  • If communication is fundamentally impossible, how can people on a project manage to do it?
  • If all people and all projects are different, how can we create any rules for productive projects?

To achieve that design, I wrote the book a bit in the "whodunit" style of a mystery. I start with the broadest and most philosophical discussions: "What is communication?" and "What is software development?"

The discussion moves through still fairly abstract topics such as "What are the characteristics of a human?" and "What affects the movement of ideas within a team?"

Eventually, it gets into more concrete territory with "What are the elements and principles of methodologies?" This is a good place for you to start if you are after concrete material early on.

Finally, the discussion gets to the most concrete matter: "What does a light, sufficient, self-evolving methodology look like?" and "How does a group create a custom and agile methodology in time to do the project any good?"

The two appendixes contain supporting material. The first contains the "Agile Software Development Manifesto," signed by 17 very experienced software developers and methodologists.

The second appendix contains extracts from three pieces of writing that are not as widely read as they should be. I include them because they are core to the topics described in the book.

Heritage of the Ideas in This Book

The ideas in this book are based on 25 years of development experience and 10 years of investigating projects directly.

The IBM Consulting Group asked me to design its first object-oriented methodology in 1991. I looked rather helplessly at the conflicting "methodology" books at the time. My boss, Kathy Ulisse, and I decided that I should debrief project teams to better understand how they really worked. What an eye-opener! The words they used had almost no overlap with the words in the books.

The interviews keep being so valuable that I still visit projects with sufficiently interesting success stories to find out what they encountered, learned, and recommend. The crucial question I ask before the interview is, "And would you like to work the same way again?" When people describe their experiences in words that don't fit my vocabulary, it indicates new areas in which I lack distinctions and words.

The reason for writing this book now is that the words and distinctions finally are correlating with descriptions of project life and project results. They are proving more valuable for diagnosis and intervention than any of the tools that I used previously.

The ideas in this book have been through dozens of development teams, eight methodology designs, and a number of successful projects on which I participated.

Agility

I am not the only person who is using these ideas:

  • Kent Beck and Ward Cunningham worked through the late 1980s on what became called Extreme Programming (XP) in the late 1990s.
  • Jim Highsmith studied the language and business use of complex adaptive systems in the mid-1990s and wrote about the application of that language to software development in his Adaptive Software Development.
  • Ken Schwaber and Jeff Sutherland were constructing the Scrum method of development at about the same time, and many project leaders made similar attempts to describe similar ideas through the same years.

When a group of us met in February 2001 to discuss our differences and similarities, we found we had a surprising number of things in common. We selected the word agile to describe our intent and wrote the Agile Software Development Manifesto (Appendix A).

We are still formulating the principles that we share and are finding many other people who could have been at that meeting if they had known about it or if their schedules had permitted their presence.

Core to agile software development is the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules.

Agility implies maneuverability, a characteristic that is more important now than ever. Deploying software to the Web has intensified software competition further than before. Staying in business involves not only getting software out and reducing defects but tracking continually moving user and marketplace demands. Winning in business increasingly involves winning at the software-development game. Winning at the game depends on understanding the game being played.

The best description I have found for agility in business comes from Goldman (1997): "Agility is dynamic, context-specific, aggressively change-embracing, and growth-oriented. It is not about improving efficiency, cutting costs, or battening down the business hatches to ride out fearsome competitive 'storms.' It is about succeeding and about winning: about succeeding in emerging competitive arenas, and about winning profits, market share, and customers in the very center of the competitive storms many companies now fear."

The Agile Software Development Series

Among the people concerned with agility in software development over the last decade, Jim Highsmith and I found so much in common that we joined efforts to bring to press an Agile Software Development Series based around relatively light, effective, human-powered software-development techniques.

We base the series on these two core ideas:

  • Different projects need different processes or methodologies.
  • Focusing on skills, communication, and community allows the project to be more effective and more agile than focusing on processes.

The series has these three main tracks:

  • Techniques to improve the effectiveness of a person who is doing a particular sort of job. This might be a person who is designing a user interface, gathering requirements, planning a project, designing, or testing. Whoever is performing such a job will want to know how the best people in the world do their jobs. Writing Effective Use Cases (Cockburn 2001c) and GUIs with Glue (Hohmann, forthcoming) are two individual technique books.
  • Techniques to improve the effectiveness of a group of people. These might include techniques for team building, project retrospectives, decision making, and the like. Improving Software Organizations (Mathiassen 2002) and Surviving Object-Oriented Projects (Cockburn 1998) are two group technique books.
  • Examples of particular, successful agile methodologies. Whoever is selecting a base methodology to tailor will want to find one that has already been used successfully in a similar situation. Modifying an existing methodology is easier than creating a new one and is more effective than using one that was designed for a different situation. Crystal Clear (Cockburn, forthcoming) is a sample methodology book. We look forward to identifying other examples to publish.

Two books anchor the Agile Software Development Series:

  • This one expresses the thoughts about agile software development using my favorite vocabulary: that of software development as a cooperative game, methodology as conventions about coordination, and families of methodologies.
  • The second book is Highsmith's forthcoming one, Agile Software Development Ecosystems. It extends the discussion about problems in software development, common principles in the diverse recommendations of the people who signed the Agile Software Development Manifesto, and common agile practices. Highsmith's previous book, Adaptive Software Development, expresses his thoughts about software development using his favorite vocabulary, that of complex adaptive systems.

You can find more about Crystal, Adaptive, and other agile methodologies on the Web. Specific sites and topics are included in the References at the back.

Read More Show Less

Customer Reviews

Average Rating 3.5
( 2 )
Rating Distribution

5 Star

(0)

4 Star

(1)

3 Star

(1)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 3 Customer Reviews
  • Anonymous

    Posted November 2, 2002

    Individuals and interactions over processes and tools

    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.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted May 14, 2002

    Excellent!

    The author drives home the ideas that we can be very productive and our work can have increasing quality and value. We're often out of time and out of energy in the home stretch, but agility can give us longevity and endurance at the career level, not just 'per project'.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted February 19, 2002

    useful

    Very clear in language and met my purpose of buying the book in the first place. Though would not be very informative to beginners and laymen

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 3 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)