License to Hack

whether it will address shortcomings in your current development approach is a fruitless quest for the nonexistent silver bullet.

If you do adopt a different lifecycle or development methodology, make sure your team members understand how the components fit together, the rationale behind each element, and the types of projects for which the methodology is appropriate. For example, incremental delivery approaches are often ill-suited for embedded systems but work well for rapidly changing Internet projects. Do you want to fly in an airplane whose avionics were written by an Extreme Programming team or by a CMM Level 5 shop? I'll take Level 5 every time.

Set clear expectations that your projects will follow a structured, yet flexible, approach that will enable timely delivery of high quality, customer-driven functionality. Your product doesn't disappear after its release date and developers often change jobs, so write enough documentation to let future maintainers efficiently adapt the system to meet new business needs.

There's a broad spectrum of discipline between the dogmatic rigidity that some fear from software process improvement and the high entropy of code-and-fix programming. Give your team the best available processes and methods to engineer excellent software, but don't give them a license to hack.