 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 (a.k.a., 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 (a.k.a., 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, having 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 entitled 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 working after each small refactoring, reducing the
chances that an infrastructure can get broken during the restructuring and ergo
injuring the ability to support the existing streams of development for the
product.
The goal of
infrastructure refactoring is to take the existing infrastructure that may be
more complex and supports a phased approach and instead streamline and simplify
it so that in supports a more incremental and agile approach.
Infrastructure Challenge
First, let's
define what infrastructure means in the context of this article. Infrastructure refers to the technical
structures such as environments, tools, and the processes that are used to
support the product. Examples of
infrastructure related components include the servers, network, and build tools
used within the product development context.
Infrastructure for a product typically gets defined and established in
the first release of the new product. In
the past, most project teams have used more traditional methodology approaches
that follow a phased approach.
What happens if
that product line wants to move away from a phased methodology to a move
iterative methodology like Agile? Can
the exact same infrastructure be used?
To a great extend yes, but what becomes apparent is that many of the
processes built into the infrastructure are built to support a more phased or
waterfall approach. A refactoring change
approach to infrastructure implies small continuous changes in order to reduce
the chances of something going wrong, versus attempting to make all
infrastructure changes at once with the potential of numerous problems
occurring as a result.
What areas of
change in the infrastructure must be considered when moving from a phased
approach to an Agile approach? In
following a project lifecycle, the infrastructure may require changes to the
requirements, configuration management (CM), testing, development, architecture,
database, release management, and other engineering spaces. In tackling this challenge, an approach that
focuses on small continuous changes will be advantageous to ensure that the
existing product maintenance and support continues while adjustments are made
to the new development model.
Infrastructure refactoring applies the Agile approach of continuous
change and integration to improve an existing infrastructure while maintaining
the integrity of the current support and maintenance line that must occur.
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 up the work into small sizes. This helps 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 is beneficial to think of changes in
relation to iterations. Therefore
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. Toward the end of the iteration, the project
team user acceptance tests (UATs) the change per a standard Agile
iteration. At the end of the iteration,
the project team and product owner decides if the infrastructure change is
acceptable and is ready to go live into the working infrastructure and start
being used by the project team. If not
the change can be bundled with the deliverables of next iteration(s) and then
released together.
Work the IPAIR Loop
The next strategy
in approaching the changes is to consider the steps that will help you thru an
iteration focused on establishing or changing infrastructure. Because it is less likely that there will be
a fully dedicated infrastructure team assigned due to the multi-tasking nature
of infrastructure work, we want to keep the steps fairly simple and
consistent. Also infrastructure
professionals may not be into Agile as much as the project team, so a simpler
variant of the traditional iteration is suggested. In this case, consider an IPAIR approach or
something similar:
-
Identify changes and place in infrastructure
backlog
- Prioritize changes
- Assess impact of changes
- Iteratively make the changes
- Re-assess impact of change seeking approve
and release of changes
- ...then
begin the loop again (e.g., rinse, repeat...)
The steps within
the iteration should be brief and simply enough to follow. The changes that are identified should be
small enough that they can be made within the 1 week iteration. If you encounter a situation where you need
more than one week, be flexible enough to expand the iteration timeframe. Also, you may find that if it is a larger
change, that there may be a way to break up the change into smaller chunks of
work to fit a short iteration.
Parallel Streams
The last strategy
focuses on a model that includes two different groups who need to work together
to adapt the infrastructure to the Agile method being used. The first group is the project team who is
using Agile to deliver working software for the end-user (the ultimate customer
who perceives the business value). The
second group is the infrastructure team who improves the infrastructure. Interestingly, the project team becomes the
customer for the infrastructure team, just as the end-users are the customers
for the project team. Just like the
standard practice where the customer should be part of the project team for
continuous feedback, the same holds true that a member of the project team
should be on the infrastructure team.
This is important to understand because the project team is the group
that must assess the value of the changes so that the infrastructure team knows
which changes are perceived to be of most value and which to work on. The customer stream in Diagram #1 illustrates
these relationships.
Diagram #1: Customer Stream
Putting the Strategies into Action
Let us consider a scenario where we have an existing
infrastructure in place for a product.
After the product has been in production for two years and three
releases, the product manager realizes that the project team is having problems
keeping up with the customer needs due to following a phased lifecycle approach
that delivers once a year. The Product
Manager decides to implement an Agile method using Scrum for the project
management practices and XP for the engineering practices. A customer advisory board (CAB) is set up
that is made up of key end-users who are willing to meet weekly. Also established are two customer liaisons
from within the company who join the project team to continuously interact with
both the team and the CAB to ensure that customer value is always considered
and reassessed.
The team decides to run with two week iterations. After two iterations, the team becomes very
aware that their current infrastructure, which was fine for a more phased and
hierarchical approach, does not support the Agile methodology very well. Diagram #2 (below) illustrates this scenario
starting at the two week iteration.
Diagram #2:
Project and Infrastructure Steam Relationship
The team agrees that changes must be made. They stop progress for an iteration and
instead introduce an iteration 0 which simply focuses on infrastructure change
strategy and identifying the changes.
They identify several infrastructure personnel to form an infrastructure
team. The project and infrastructure
teams decide that iteration 0 will be 1 week and focus only on identifying
infrastructure improvements.
Note:
the task of forming an infrastructure team can be very challenging if the organization
is not used to Agile and the iterative approach it follows. The services provided by infrastructure
support functions typically align with a more phased or task driven approach. Another
challenge is getting members of the infrastructure team to be fully dedicated
since infrastructure work tends to be multi-tasking in nature.
During iteration 0, the project team discusses the various
areas of infrastructure that are constraining productivity. They review the infrastructure (e.g., environments, tools, and working processes
such as requirements, CM, testing,
development, architecture, and database) and identify areas of
improvement. Then they prioritize the
improvement areas to best determine the value to project team (a.k.a., the
customers of the infrastructure team). One area that has slowed them down is build
management. Working with the
infrastructure team, the project team takes the higher priority improvement
areas and divides them up into small changes that represent no more than a one
week iteration. In this case, the build management improvements are broken
into: implementing a nightly build process (from the weekly build); setting up
private work streams for the developers so changes can be built and checked
into a private branch; evaluating a
continuous build tool; and implementing the tool and supporting continuous
build processes.
The duration for each task will vary depending on the
number of people available in that week.
They then assess the impact of
the higher priority changes which includes determining the size of the change
and the dependencies to other areas.
Note:
the relationship your company has between the project team and the
infrastructure team will have an impact on how well they work together thru
this process and their ability to adapt to the best practice for their working
environment. Also per Agile principles, the more dedicated the infrastructure
resources, the better the ability to utilize the iterative approach.
Once iteration 0 completes and there is a clear path for
infrastructure improvement work, the project team can re-initiate their
iterations of functionality development (a.k.a., the project stream) while the
infrastructure team begins work on the infrastructure improvements (a.k.a., the
infrastructure stream) also in iterations.
Effectively both streams are happening in parallel.
As the infrastructure team makes changes (including
testing by a member of the project team), they re-assess the impact of
deploying the changes, revisit the project team (a.k.a., the customer for the
infrastructure functionality changes) seeking acceptance of the changes. If so, the infrastructure changes are
deployed to the working environment at the end of the current iteration. If not, they work the IPAIR loop until the
end of the next iteration and re-assess if the bundle of changes are
ready. This will progress until such
time that the infrastructure is now well suited for Agile.
Summary
When you find
yourself in a position where you inherit an existing infrastructure and find
that it is not well suited for Agile processes, consider the Infrastructure
Refactoring approach. Introducing
strategies like an iteration 0, thinking in iterations, a simple improvement
loop, and running the infrastructure work in parallel with the project work may
help you get to an infrastructure that is much more closely aligned with the
project team's needs. The infrastructure
refactoring approach helps you focus on a series of small changes in order to preserve the overall integrity of
the infrastructure and existing release processes. This reduces the risk of breaking the
infrastructure therefore allowing those working in the current development
stream, the maintenance stream, and the bug fix streams to continue to be
productive, deploy changes to production, and ultimately deliver continuous
value.
References
About the Author
Mario
Moreira is a
Columnist for CMCrossroads Journal, a VP of Architecture & Methodology,
an Author of CM publications, and has
worked in the SCM field since 1986 and in the Agile field since 1998. He
has experience with numerous SCM technologies and processes and has implemented
SCM on over 100 applications/products, which include establishing global SCM
infrastructures. He has an MA in Mass
Communication with an emphasis on communication technologies. Mario also brings years of Project
Management, Software Quality Assurance, Requirement Management, facilitation,
and team building skills and experience. Mario has released a new SCM
book entitled, “Software Configuration Management Implementation Roadmap”. It can be found at www.wiley.com, www.wileyeurope.com, and www.amazon.com (search for Mario
Moreira). It includes step-by-step
guidance for implementing SCM at the organization, application, and project
level with labor-saving templates on CD. You
may reach Mr. Moreira by email at
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Forums 
