Chapter 2 challenges the reader to "identify your cost and cycle-time drivers, i.e. the activities that consume resources and limit the ability to deliver on time, and value proposition, i.e. what you are trying to achieve for the customer.”

It then introduces the book's case study, namely re-architecting HP FutureSmart Case Study.

The next two chapters are about how to put in place a new architecture that is aligned with business objectives in an agile way and the following one is about the kind of culture and management style that facilitates an agile approach, defined as "change for people's sake". It outlines the iterative model of agile management that proved so successful in this case study.

Chapter 6 is where we start to discover about the processes that enabled ten-fold productivity improvements - starting with continuous integration and its associated automated testing methods. In Chapter 7 we learn about how the agile approach, coupled with changing the expectations of management and marketing, led to a dramatic reduction in the resources devoted to planning and scheduling. This is expressed in the following benefit:

Every hour we spend planning a feature is an hour we don't spend delivering it (the real goal).

This was achieved by using ballparking and trend watching for prediction and by introducing "Just-In-Time Story Definition". The next chapter looks the planning process for large architectural efforts - with the remedy of "prototype to remove uncertainty" and proceed in "thin slices".

Chapter 9 homes in on the topic of project management for large-scale agile, looking at three roles: program managers, who are responsible for oversight and setting priorities, section managers who have budget responsibility and architects whose job it is to ensure that the processes adopted  promote improvements in productivity and code. Next comes a chapter outlining three examples of organizational approaches to large-scale agile, looking at the pros and cons of each.

Any organization that outsources overseas could probably learn something from Chapter 11, which has the title "Effective Agile Development Across U.S And Indian Cultures" and presents six lessons drawn from the experience of offshoring.

Chapter 12 looks at the infrastructure employed to improve productivity. It covers moving to a common development environment, having a complete and capable system simulator, architecting a common test framework for scalability, developing a tool for automated testing, and delivering metrics in an integrated manner. One factor that contributed to increased productivity was providing every developer with a high-resolution 30"monitor and high-end noise cancelling head phones. Now that is an enlightened move that is worth copying.

Chapter 13 includes a summary of the bottom line resulting from the large-scale agile improvements in terms of resources moved from overhead to innovation. The savings in resources were:

Code integration 10% -> 2%

Detailed planning 20% -> 5%

Porting 25% -> 15%

Current product support 25% -> 10%

Resources spent on running tests 15% -> 5%

This meant that the resources devoted to "value proposition" were able to increase from around 5% to 40% and in addition could be devoted to improved test tools (3%), new automated tests (10%), daily regression testing (10%).

The other outcome was that the cycle time for developer change to feedback for a complete testing cycle was from 2 months to 1 day.

In the next chapter looks in more detail at change management after the transformation and the impacts on other parts of HP.

Chapter 15 reflects on how the authors' perspective on scaling agile differed from others. This introspection seems to be a direct consequence of writing a book about the experience and having other agile practitioners comment.

The book rounds out with a chapter designed for those who have been inspired to embark on a similar experiment and outlines how to determine the first steps towards it.     

If you like reading about other people's experience, you'll enjoy this book. It is also useful as an introduction to agile for those who don't know much about it, particularly those working on large-scale projects. If you are about to embrace agile without any prior experience, it probably isn't the only book you should read. There are, however, pointers to the books the authors wish they had read to use as a basis for further reading.