Product Description

“Agile Software Development is a highly stimulating and rich book. The author has a deep background and gives us a tour de force of the emerging agile methods.”

–Tom Gilb

The agile model of software development has taken the world by storm. Now, in Agile Software Development, Second Edition, one of agile’s leading pioneers updates his Jolt Productivity award-winning book to reflect all that’s been learned about agile development since its original introduction.

Alistair Cockburn begins by updating his powerful model of software development as a “cooperative game of invention and communication.” Among the new ideas he introduces: harnessing competition without damaging collaboration; learning lessons from lean manufacturing; and balancing strategies for communication. Cockburn also explains how the cooperative game is played in business and on engineering projects, not just software development

Next, he systematically illuminates the agile model, shows how it has evolved, and answers the questions developers and project managers ask most often, including

· Where does agile development fit in our organization?

· How do we blend agile ideas with other ideas?

· How do we extend agile ideas more broadly?

Cockburn takes on crucial misconceptions that cause agile projects to fail. For example, you’ll learn why encoding project management strategies into fixed processes can lead to ineffective strategy decisions and costly mistakes. You’ll also find a thoughtful discussion of the controversial relationship between agile methods and user experience design.

Cockburn turns to the practical challenges of constructing agile methodologies for your own teams. You’ll learn how to tune and continuously reinvent your methodologies, and how to manage incomplete communication. This edition contains important new contributions on these and other topics:

· Agile and CMMI

· Introducing agile from the top down

· Revisiting “custom contracts”

· Creating change with “stickers”

In addition, Cockburn updates his discussion of the Crystal methodologies, which utilize his “cooperative game” as their central metaphor.

If you’re new to agile development, this book will help you succeed the first time out. If you’ve used agile methods before, Cockburn’s techniques will make you even more effective.

---

Product Details

• Amazon Sales Rank: #239561 in Books
• Published on: 2006-10-29
• Number of items: 1
• Binding: Paperback
• 504 pages

About the Author

Dr. Alistair Cockburn is an internationally renowned expert on all aspects of software development, from object-oriented modeling and architecture, to methodology design, to project management and organizational alignment. One of the pioneers who coined the term “agile software development,” he co-authored the 2001 Agile Software Development Manifesto and the 2005 Declaration of Interdependence. Since 1975, he has led projects and taught in places from Oslo to Cape Town, from Vancouver to Beijing. His work has covered topics from design to management to testing, in research, in government, and in industry. His most recent book is Crystal Clear: A Human-Powered Methodology for Small Teams. His books Writing Effective Use Cases and Agile Software Development won back-to-back Jolt Productivity Awards in 2001 and 2002.

Excerpt. © Reprinted by permission. All rights reserved.

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 late 1960s, 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 an...

---

Customer Reviews

Well Deserved Jolt Award
I picked this book up because of the Jolt Award. I was amazed as what I read. I give kudos to anyone who tries to apply game theory to their decision making process. This has grown to be the accepted way economists discuss decisions between agents, so why shouldn't we apply that to architecture or project decisions?
Still more kudos to any author who heavily references 'philosophy' and then correctly references a real contemporary philosopher (Wittgenstein)!
Sadly though, I would have loved to see cooperative game mapped out a bit more. The tools of game theory are there, so we should use them.
My favorite take aways: ShuHaRi analogy, Cooperative Game analogy, Selection of *implemented* project methodologies as starting points, and a methodology to create methodologies. All in All this is an excellent book to get you started in Agile or to bring you up to date with the 'why' questions of Agile.

Any needing a basic introduction to Agile principles, history, and construction must have this.
The agile model of software development has become an industry leader, making the second updated edition of Agile Software Development: Cooperative Game an even more essential reference. Agile's pioneering developer updates his Jolt Productivity winner to cover all aspects of the agile model, from its applications in an organizational structure to how to blend agile ideas with others. Any needing a basic introduction to Agile principles, history, and construction must have this.

Diane C. Donovan
California Bookwatch

useful if you don't get into XP
Cockburn emphasises a flexible approach to writing code, especially when you have a team of programmers. Unlike other approaches, like CMMI, the methodology advocated by the book seems deliberately informal. Now, certainly, the book does enumerate various steps typical in an agile approach.

For example, we see a list of methodology design principles. One of which is independent of whether you use Agile or not, and which especially caught my eye. It says that larger teams need heavier methodologies. There are several methodologies floating around in the IT industry. And Agile is only one of these. But that particular principle can be very useful. As the text explains, with 6 or less people, say, you can put them in one room, and have little or even no methodology. Because people can just talk and plan things together. But as teams get bigger, and they get dispersed over different rooms, buildings and cities, then you need more elaborate methodologies. And your choice need not even be Agile.

The book also has a writing style with lots of little side notes or anecdotes, that can help some readers assimilate the ideas in the main narrative.

The biggest problem to me with the book is its relatively uncritical acceptance of XP (Extreme Programming). It quotes that the first XP project was successful, in delivering results, compared to a larger team that had failed. But the first XP project that I am aware of, from another text, "Extreme Programming Refactored", was at Chrysler, and it failed to meet its deliverables. That book gave a far more plausible analysis of XP and its brittleness. Cockburn's text does allow that XP can have its limitations if the team gets too big. Because both admirers and critics of XP generally acknowledge that an XP team must intensively share knowledge and coordinate actions, and this just does not scale.

But if we put XP aside, then the Agile approach can be useful.