Infrastructure Refactoring


Strategize for Infrastructure Refactoring

Many Agile efforts get underway as new product development. This implies that there is no infrastructure in place so it is essentially an effort of establishing the infrastructure. However, what happens when a product already exists and therefore so does the infrastructure and then the methodology changes from a phase approach to an Agile approach?

This is where a re-engineering of the infrastructure may need to occur. Possible infrastructure changes to suit agile may include changing the use of an existing tool, introducing a new tool, changing how environments are used, changing existing process that impacts tools and environments, and even changing how infrastructure service provides engage with the project team. With this in mind, strategies should we considered to adapt our infrastructure for the agile methodology. The product owner should be the primary driver of this work but may assign a more technical representative from the project team to focus on the strategies. Once the strategies are in place, the execution of the strategy will be owned by the infrastructure team with the project team as the customer. More details on this to follow. Strategies to consider include:

Initiate an Iteration 0

The first strategy is to consider using an iteration 0 cycle to examine the changes needed and set a strategy on how to move forward. If the potential number of infrastructure changes that are involved (e.g., requirements, CM, testing, development, architecture, database, release management, and other engineering spaces) are significant, it is worth initiating an Iteration 0. Within this 1 or 2 week cycle, the goal is to better understand the number of changes and place them into a backlog, assess the impact of the changes, identify the dependencies of the changes to other areas, and then determine the work that needs to be done to get the changes to occur. The dependency identification will help in the prioritization process of what to tackle first, second, and so on. This is also the time to consider breaking the work into small sizes. This helps to establish an expectation of how much can be accomplished in each refactoring task.


Think in Iterations

Since refactoring implies a small series of changes, it’s beneficial to think of changes in relation to iterations. Another strategy is to use an Agile approach of short iterations (e.g., 1 week). Identify and assess a small enough chunk of work that can be managed within this timeframe. Near the end of the iteration, the project team user acceptance tests (UATs)

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.