Preface to the Second Edition

The agile model of software development took the world by storm in 2001. Within a year there were books and conferences on it around the world. Within five years, it had influenced everything from project management and how corporate executives write contracts with their clients, to military procurement procedures, and even to college curricula.

It is time to look at the changes and see what we can learn about the agile model, and more generally, the cooperative game.

At the time that the Manifesto for Agile Software Development was writtenFebruary 2001I was already deep into writing about software development as a cooperative game and the tailoring of methodologies to individual projects. The manifesto merely echoed what I and others were already doing.

The agile model took the world by storm. Hundreds of developers signed the online signing board (the original, informal Agile Alliance, not to be confused with the AgileAlliance corporation that was formed later and runs the Agile conferences in the U.S.) to show their alignment with its values and principles.

After the initial questions around "What does this mean?," people asked:

• "Where does it fit in the total set of development situations?"

• "How do we blend these ideas with others?"

• "How do we extend these ideas to other fields?"

These are the questions picked up by the additional text in this second edition.

The cooperative game model grew alongside the agile model. Originally constructed to explain software development, it struck a chord with business people, who rightly saw that business is also predominantly a cooperative (and competitive!) game of invention and communication.

You would imagine that during the past five years, something should have come as a surprise to me. I highlight four:

• Engineering is also a cooperative game of invention and communication. With a bit of reframing, we can now place software engineering as a proper member of the engineering fields.

I leave intact in the second edition the fairly strong words I wrote originally against the idea that software development should be treated as engineering. I do so because those words still apply to the way in which most people still incorrectly view engineering and draw from it correspondingly incorrect ways of how to manage software development. In this second edition text, I turn the investigation back to the question, "What is engineering?"

After the second world war, discipline envy of applied physics caused wishful thinking in engineering academia, and popular understanding of engineering got off track. Looking afresh at engineering practices, we notice that it is itself a cooperative game of invention and communication. From this, we can create an updated notion of software engineering that makes sense both practically and pedagogically.

• The specialty area of user experience design has made strong inroads in the last five years. It was ignored by the authors of the manifesto, and deserves serious attention.

All of the early agile methodologies skipped completely over this issue, probably because none of the manifesto authors had strong expertise in that area. That area has been and still is an area of hot debate, with few solid conclusions. I discuss the conclusions and points of contention in that section.

• I have learned how to separate project management strategies from methodologies.

Project management strategies too often get placedincorrectlyas part of a corporate process or methodology. Encoding what should be on-the-scene strategies as fixed policies often forces managers to make ineffective strategy decisions and costs the organization greatly. It is therefore important to learn to separate the two.

• In addition to the surprises, all of the development around "agile software development" has occurred since the writing of the first edition.

This means that there are a lot of topics to cover, with a lot of misconception to clear up around the meaning and practice of agile software development.

Thus, the chapter on the evolution of agile software development is considerably longer than the other evolution chapters. This is natural and appropriate. I hope that readers already knowledgeable about agile development will find new nuggets of information in that chapter, and that newcomers to agile development, confused by some of these issues, will gain some clarity and insight.

Reading This Book

The second edition is to be read in much the same way as the first edition.

Those interested in "the rules of the game," including but not restricted to software development, will find the first four chapters (including the Introduction) their main meal.

Those who want to get quickly to the agile model of software development and the construction of methodologies for their teams may want to leap to the second half of the book, or Appendix A on the Agile Manifesto, and from there, go to the methodology sections.

Some will come to this book to read about the foundations of the Crystal family of methodologies. They should start with Chapter 6, "The Crystal Methodologies," which I have updated with an improved description of the family. They can then go back to the beginning and read about the communication and cooperative game, as that is the anchor for the Crystal family.

Those who have already read the first edition may want to read each "Evolution" chapter. These new chapters are easily identified by the gray thumbtab along the edge of the page. I have limited the changes in the rest of the book to corrections of mistakes, so you would not have to reread every page to search for the newer ideas.

However you read this book, I urge you to dip into Appendix B, with reprints of key writings by Musashi (the 17^th Century samurai), Peter Naur, and Pelle Ehn.

Over the past five years, I have come to appreciate their writings steadily more. I now teach from Musashi in the first hour of agile training, use Naur's theory as a core element in describing software development, and revisit Ehn's paper periodically to help mature my own views. I suspect you will find them similarly valuable.

Thanks to Specific People

The reviewers at the Silicon Valley Patterns Group were once again very considerate and helpful in helping me tune the text. They found errors and quarreled, and in the rare case I decided against their wishes, I take full blame on myself.

Russ Rufer and Tracy Bialik in particular held my feet to the fire on several occasions to make sure I meant what I wrote. Thanks to them, I removed a couple of assertions I couldn't back up. They also helped improve the explanations of several diagrams.

Other reviewers who kindly read the draft and sent in wishes, comments, and corrections include John Rusk, Paul Old-field, Brandon Campbell, Romilly, Dave Churchville, Ilja Preuß, Géry Derbier, Mark Levinson, and Paul McMahon. John's agileKiwi.com site is an excellent resource for more information on burn-up and earned-value charts (and other topics agile); Dave's ExtremePlanner.com site focuses on agile planning and tracking software; Paul's comments on agile and CMMi were major enough that I asked him to contribute a sidebar around them.

Celeste Rosell bent her schedule out of shape on many occasions to help get article and page cross-references worked out in time. I'm not sure how she worked out correct answers, given (on occasion) nothing more than "???" in the middle of a paragraph.

The production staff at Addison Wesley / Pearson Education and their contractors were extremely helpful. Leslie Sweeney of Carlisle Publishing did an outstanding job of creating a clear and memorable diagram of decision flows in software development (Figure 1.1-2). Alan Clements of Pearson came up with the fabulous cover designs for both my Crystal Clear book and this second edition.

On a happy note, the Salt Lake Coffee Break still serves Turkish coffee and is open until 2 a.m. every night. I've relied on both in writing this second edition.

On an unhappy note, marketing squatters took the crystalMethodologies.org site when I unwittingly let it lapse, so that site no longer provides useful material and certainly is not connected with my work. I have created Alistair.Cockburn.us, which currently holds all my papers, talks, and other material. With luck, I'll be able to keep that site intact and useful.