1) This book provides an excellent perspective on the issues and challenges of adapting "Agile Processes" for use on large programs. To date, most literature addressing use of eXtreme Programming (XP), for example, state that this method is intended for use by small development teams. Note that this book doesn't focus on XP as "the only way" to do Agile Development; the book is intended to be "method neutral" and it achieves this end. The summaries at the end of each chapter provide valuable reinforcement for the lessons-learned in that chapter.
2) The introduction provides some interesting philosphical discussion regarding how one might consider approaching Agile Development on large teams, and provides initial thoughts on how to scale up proven agile processes for large teams.
3) Chapter 2, "Agility and Largeness", discusses a number of "generalities" that must be considered when trying to work a large project with a large team, using Agile methods. The author identifies several important issues that must be addressed (e.g., communication issues in large teams that cannot be co located). In addition, this chapter contains an excellent discussion of factoring.
4) Chapter 3, "Agility and Large Teams" addresses the "people issues" associated with scaling Agile methods to large projects. gain, communication is addressed, along with team building. Suggestions are provided about how to implement "virtual teams" on a large, agile project.
5) Chapter 4, "Agility and the Process" seems to be, to an ex process engineer at least, the heart of this book. Objectives, feedback, and planning are discussed in depth, and the use of regular retrospectives is suggested (in contrast to an end-of the-project "post-mortem). Tips are given to help you get started, and the importance of a "culture of change" is identified and discussed.
6) Chapter 5, "Agility and Technology" provides some interesting thoughts on how state-of-the-art technology can be a hindrance, and how state-of-the-practice technology can assist a project, whether agile or not.
7) Chapter 6, "Agility and the Company" provides valuable insight into how corporate cultures and structures can help and hinder agile development in the large. The perspectives on planning and control, and QA are interesting, to say the least. I won't offer any hints except to say that this chapter makes VERY interesting reading, especially to a person (like myself) with an extensive QA and testing background. The only thing I didn't see addressed in this chapter, which I saw in a recent article in Better Software magazine, was the difficulty of applying a corporate reward structure to Agile Teams.
8) In Chapter 7, Ms. Eckstein wraps up the book with a report on a large project she assisted (or more than that) starting up with agile processes. This chapter also makes very interesting reading, and offers some significant lessons that Ms. Eckstein and the company she was working with learned.
A couple of minor areas I'd have liked to see addressed or modified, though maybe this is due to her viewpoint from the European software development culture. Ms. Eckstein uses the terms "testing" and "quality control" interchangeably. That's generally not true in the US, "QC" is usually a suborganization within Quality Assurance, and testing is usually a separate organization. Also, her experience seems to be that QC/testing comes in at the end of a project. That's not the way we generally do things in more mature, enlightened companies (like Lockheed Martin Transportation & Security Solutions) in the US. But in summary, the book is well-done and a good read for any project manager who'd like to do development in an agile manner, on a large project.
Buy this book, and read through it carefully if you're considering using Agile processes on a large project. It's well worth the investment. Ms. Eckstein and Dorset House have put together another excellent offering for the software community.