Readernaut

"... there many be an unlimited number of stages in a program" should read "there may be an unlimited number of stages in a program"

The appendix includes guidance for introducing iterative techniques to your own development group. The main tips are to pick an important project with talented people, get them to buy in, and then don't change too much at one time (iterate).

They recommend measuring progress as a count of completed scenarios, regardless of size.

That seems to discard a lot of info about effort, but I can see how the simplification would balance out over time.

There is not a lot of specific advice in the measurement section about how to measure cost or expected benefit. Though to be fair, those are probably topics for a book all their own.

Net present value = initial investment + sum_over_time(cash_flow_for_year_t / (1+r)^t)

Don't forget to include the maintenance costs in the cash flow estimates.

"Perception is key." Regardng the challenge of measuring without influencing the outcome. Transparency in goals and approach helps avoid the problem.

Iterative development is all about trending in the right direction. You won't hit the target with the first iteration, but by striving to get closer with each iteration (and monitoring the results of that effort) you can steer the project to the conclusion you want.

Chapter 7 talks about "accelerating cultural change" by playing offense, not defense. This section includes some sweeping claims of major improvements by adopting their proposals, but offers no supporting studies (even as footnotes).

Although counter-intuitive, they propose that transitioning to a new process or tool on a high-profile project is better than easing into it. Their rationale is that the people assigned to work on high-profile projects are typically the better performers already, and if you get their buy-in, they will make the change work because of their dedication. The trick is getting the buy-in in the first place, of course.