Agile is not new. Many years ago, project leaders began working closely with the user community and engaged them throughout the entire project process. This ensured that the users were involved in determining what they wanted and how it would be presented. Through this natural course of human involvement, the requirements evolved naturally to meet the needs of the customers, ensuring greater satisfaction with the results. By engaging the user, the development team ensured that they delivered to meet the needs of the user and also gained incremental user 'ownership' of the product. The underlying principle was to place the needs of the customer first. Sometimes, this is referred to as Extreme Programming, or XP. This concept places customer satisfaction first by providing the functions and features the customer wants, rather than what the developer wants to deliver. Typically, this provides a rapid response to dynamic customer demands and encompasses Continuous Integration (CI), which involves frequent changes to the code, and subsequently frequent code delivery. Another important function to consider is code refactoring. This involves integrating small changes to the look and feel of the project continuously, over time. Refactoring is not a bug or defect and should not be treated as such. It is merely an aspect of continuous improvement and evolution, and is ideally suited for an Agile environment. In 2001, Agile was officially born, though as I have already mentioned, it had actually been in use by many technology departments long before then; it just had not been formalized or named. The fact that the Quality Assurance (QA) function is typically compartmentalized away from the development function also aggravates quality issues. Too often, there is an invisible 'fence' between the development and quality teams which inhibits teamwork and often promotes an antagonistic relationship between the two groups. Isolation of the development and quality teams results in a fragmented effort and sub-standard results. Development rushes to meet a deadline, and quality often has little or no understanding of the user requirements. It is not uncommon for a Quality Assurance team to completely redesign an application after it has been developed and delivered to them for testing. This is where Quality by Design can be quite effective by requiring that the development teams are responsible for quality and the quality teams are responsible for understanding the user requirements by being fully engaged in the project from the outset rather than at the end.