Is Software Process Improvement the problem?

"Faster, Better, Cheaper" (FBC) was a development philosophy adopted by the NASA administration in the mid to late 1990s. The conclusion from the FBC experience was "Faster, Better, Cheaper? Pick any two". (link)

"How do you merge agile, lightweight processes with standard industrial processes without either killing agility or undermining the years you’ve spent defining and refining your systems and software engineering process assets?" (Boehm & Turner, 2005) Is this even a reasonable question to ask let alone attempt to answer? Should the question be recast; where do agile lightweight processes work best and where do standard industrial processes that you've spent years defining and refining work best? Alternatively, are software engineering process assets in contradiction to agile, lightweight engineering processes?

The authors frequently refer to 'scale', they also refer to barriers. What assumptions does the 'scale' argument make? What barriers are they talking about? Finally, is SPI (software process improvement) the problem rather than a solution? If instead risk is the real problem should our response be to manage it away with contain and counter strategies or can risk be treated differently? In drawing the distinction between systems and software engineering (whatever Boehm and Turner really mean by the terms), are they suggesting that integration is in fact impossible, that the two perspectives may interact but superficially, as a sort of respectful disengagement?

REFERENCES
Boehm, B. & Turner, R. (2005) Management Challenges to Implementing Agile Processes in Traditional Development Organizations. IEEE Software, 22, 30-39.
Menzies, T., El-Rawas, O., Hih, J. & Boehm, B. (2009) Can We Build Software Faster and Better and Cheaper? PROMISE '09 Proceedings of the 5th International Conference on Predictor Models in Software Engineering.