Integrated Concurrent Engineering vs. Agile Software Development

Agile inspired software development is certainly all the rage.  One could argue that those processes have even crossed the chasm, with mainstream companies adopting various forms of Scrum, XP, DSDM, OpenUP and the like.  I certainly fall in the camp of people that started using Agile techniques as soon as I started to understand them (starting as early as the first publications on the c2.com wiki).

Meanwhile, over about the same time (starting in 1994 at JPL, according to Wall in “Reinventing the Design Process: Teams and Models.”), Integrated Concurrent Engineering (ICE) techniques were being tried and adopted in space systems development.  Also, some early work on concurrent engineering (CE) was published in 1996 by Prasad in Concurrent Engineering Fundamentals, Volume I: Integrated Product and Process Organization. (Note, this was 3 years earlier than Extreme Programming Explained by Beck.)  Prasad described eight fundamental principles of concurrent engineering: "“Early Problem Discovery, Early Decision Making, Work Structuring, Teamwork Affinity, Knowledge Leveraging, Common Understanding, Ownership, and Constancy of Purpose”.   ICE includes provisions and support for having a co-located customer and co-located and cross-functional teams; further, ICE is a tool for lean engineering. (A history of ICE is available starting on page 68 of http://esd.mit.edu/people/dissertations/avnet.pdf).

There has been much study (peer-reviewed and published) on the benefits (faster time to completion, lower risk of missing interfaces) and potential drawbacks of ICE (using CE when plain-old sequential engineering would due). There are almost no studies of the same type done in the Agile development world, despite emerging over about the same time period.  Why?