Early implementations of Agile focused on brand new or newer product-lines. More recently, Agile is gaining acceptance in the legacy product space where the project teams are moving away from their company's traditional (aka, waterfall) methodology and moving toward an Agile approach. In these cases, the project team that begins to use Agile methods are typically inheriting an existing infrastructure that was constructed for a phased (aka, waterfall) approach.
At first glance, this may not appear to be a major issue, but very soon the team learns that the infrastructure is not well suited for Agile and changes must be made to it. For example, the test infrastructure may be hierarchical in nature due to its rigid entry criteria and, therefore, slowing down the process of migrating code from development to test. Another example is the build process is both slow and occurs only on a weekly basis producing numerous broken builds. The project team realizes they need either continuous builds or at least nightly builds to minimize the merging effort and reduce the rate of broken builds. Ultimately, the infrastructure should be reflection of the methodology being used.
As there is a focus to change areas to better align the infrastructure and associated processes to Agile, the project team must continue their development work to deliver functionality and business value per Agile principles. How can this team solve the problem whereby they must continue to deliver value, but must also make changes to their infrastructure to reduce problems and gain velocity? One suggestion is to utilize a newly termed approach called “infrastructure refactoring”.
As many folks know, within Agile there is the practice called refactoring. As Martin Fowler describes it, "Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a refactoring) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring."
Similarly, when confronted with a stogy infrastructure for an existing product line which has not been aligned for Agile, infrastructure refactoring can provide similar advantages. Infrastructure refactoring initiates a "restructuring of the existing infrastructure". It really should occur in a series of small changes to preserve the overall integrity of the infrastructure and the existing release processes for the product line. When an infrastructure of an existing application is changed, the change must ensure that the product can continue its development without any significant downtime in any of the infrastructure pieces in use, therefore each refactoring should be small. The infrastructure must be kept