Eckstein went on to warn the reader that these principles aren't to be followed blindly. Obviously processes and tools should help rather than hinder the individuals and their interactions; documentation isn't a party favor for the current project team, it is an artifact for future resources when maintaining, servicing, improving, or sun setting the application. In today’s litigious environment, contracts are a necessity and the reality. And if the team doesn't have a plan to build the software (or one that is used or remotely correct)…well, I think any team member has been in that position before. Not pretty and not conducive to mental or physical health of team members.

Agile Software Development in the Large: Diving Into the Deep does provide substance, but it also promotes silos in software application development. As an important FYI, Eckstein’s definitions of acceptance, systems, and integration tests do not match those provided in the Certified Software Test Engineer (CSTE) Guide to the Common Body of Knowledge. Nor do they make any sense. But the real issue I have is that the book continuously ignores the above requirements of Agile processing (e.g., Individuals and interactions over process and tools).

Overall, this book works with one premise: communication is the key to using Agile development processes for the creation, revision, management activities, etc., associated with successful end-products. Using this topic, Eckstein explores communication and its importance in all chapters. This is refreshing, since communication is crucial to any IT effort’s success. Eckstein does a reasonable job explaining the barriers to using Agile development in large organizations: cultural resistance to change, process overhead, the lack of automated testing tools outside the Unit level space, bottlenecks created by ownership and turf issues, resource constraints, and even the ever-changing need of the customer. I am not sure, however, that any of the content is “new” or groundbreaking in its presentation.

This book needs to be read by testers for a "reality check" on the realized gains of the promotion of testing as both an art and a science as well as how much of our journey still remains. This journey is the continued effort to educate our project teams, our management and our organizations that testing isn't confined to the end of the project or even the end of the creation of a component.