From my 15 years of experience in high reliability embedded software, I find the assertion "The primary reason that designers move to agile methods, is to improve quality" hard to believe and very confusing.
Agile methods promote 'working software' over documentation.
Secondly, agile methods have shorter release cycles.
While this allows teams to better adapt to changing requirements, it does not improve quality.
By focusing on working software and shorter release cycles, one usually sacrifices quality (eg: less investment in long term architecture and less thought spent fully defining system requirements). While this may work well for fast pace projects with uncertain requirements, it can be fatal for complex software projects.
I don't have anything against agile methods, but to say that the primary reason teams move to them is to increase quality just doesn't make sense to me.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...