Process Improvement

Of the two different approaches to process improvement, the agile approach makes the most sense to me. In general, throughout the development process there will be many changes. Although requirements should be defined before development even starts, it's important to be aware that there will be changes to those requirements many times. This will prove to be especially true if the company keeps in frequent communication with its customers. There should be a constant stream of feedback at every major milestone in the project.

Despite even the best organizational efforts, a project's prototypes, requirements, expectations, etc will change. This is not a bad thing, a project should be flexible and changing. Although development will begin with a clear goal in mind it's important to not be so focused on that goal that you ignore any other input or variables. Perhaps in the midst of developing a feature you discover that there is an open source project that does much of the same. Potentially you could apply the sunk cost fallacy and think "well I've already worked so much on this feature. I should just finish it." Or you could be reasonable and agile:  consider the consequences (good and bad) of either continuing your development or adopting this open source library. 

Unfortunately due to strict deadlines, oftentimes there will be trade offs to be evaluated. It's important to look at all potential results of a decision. This requirement could be made better with x improvement, but we would have to switch development gears and potentially lose some time. It's easiest to evaluate things that can be measured such as time, cost, people available and decide the best course of action from there.