As Agile practices prove successful in small project
teams, there is increasing demand to roll them out to large programs or across
entire departments. Such large-scale
adoptions demand that the practices be rapidly implemented and consistently
executed, and that they work with the most stringent corporate governance
standards. What makes this difficult is
that complex projects can strain Agile practices. New practices and tools in build pipelining as
well as emerging application lifecycle management (ALM) 2.0 capabilities in
Agile project management tools will make it possible to scale Agile practices into
very large and complex development initiatives.
Scaling Continuous Integration
with a Build Pipeline
The benefits of build and test automation are well
established. Maintaining an application in
a deployable state shortens the time between the moment code is committed, and that
code is available for use in QA or even production. Subjecting a build to unit, functional, and
non-functional tests by automatically invoking them during the build cycle provides
very timely feedback to a developer of the success or failure of their code,
and therefore reduces the defects that escape the coding phase of software
development.
As a
linear
Advertisement
process, however, this build cycle may not scale. Large, complex projects may have hundreds of
people committing code to them. With a lot
of people coding, the number of automated tests will also increase. In an environment with this much activity, build
efficiency suffers: the project build cycle will take longer to execute. In a large code-base with a lot of tests, the
build is produced frequently, not continuously.
This increases the latency in feedback to developers, and undermines the
efficiency of Agile practices.
In
scaling continuous integration, the build should not be thought of as a single event,
but as a series of events sequenced in a build
pipeline. This allows for those build
activities that are "closest to the code" - the ones that give the strongest
indication of coding success - to be executed continuously. Build activities that are "closer to the
business" are still automated, but executed with less frequency. These can be staged into a series of
discreet, independent stages that form a build pipeline. Each stage of the pipeline then acts as a gatekeeper
to producing a release candidate suitable for deployment.
Consider
a simple example. One possible pipeline would have the build decomposed into
the following stages: compilation and unit tests, functional tests, and
non-functional tests. Successful compilation
and unit test execution are the events nearest to the code. Efficiently executing these provides timely
feedback to developers. The first stage
of the build pipeline might be a build script that compiles and executes unit
tests with each code commit. With a
successful compile and unit tests, developers have timely feedback and can
carry on their work. Meanwhile, a second
gatekeeper might deploy the latest unit tested build into an environment where
functional tests can be automatically run. This second gatekeeper might run
continuously, but might take a very long time to run because of the nature of
the functional tests. A third gatekeeper
might deploy the latest functionally-tested build into an environment where
non-functional tests can be executed. In
this stage, the application might be tested for tolerance to non-functional
tests such as security, scalability and regulatory compliance. This build might only occur once or twice a
day, but still be visible to developers through build monitoring. Clearing all of these gatekeepers yields a
satisfactory release candidate of the current state of the code.
By
structuring the build cycle this way, there is minimal latency in feedback of
the tests most likely to fail when code is changed. There is also maximum throughput of builds
deemed suitable for deployment to QA or production environments. Minimum latency and maximum throughput are
achieved while maintaining the core Agile value that the build-readiness be top-of-mind
for developers: developers can monitor each build process and be notified
(e.g., through system tray icon or RSS feed) of which, if any, of the
gatekeepers has failed.
Current practices
and tools make pipelining increasingly efficient. First, server virtualization technology makes
it easier to create robust build pipelines.
Managing environments is time-consuming. Destructive functional tests (i.e., tests that alter database values)
require that data be constantly reset into a baseline state. If code must be certified to work with
multiple combinations of application servers, operating systems, databases,
messaging stacks, etc., a number of environments must be configured and
maintained in a state of test-readiness.
There is also a practical limit to the number of environments which can
be constructed, thus limiting the availability of environments for testing. Virtualization makes it easier to manage
these problems. Master environments for
testing can be maintained in a clean state, imaged, and instantiated on-demand in
a server farm to support functional and non-functional testing. This means that functional and non-functional
testing can be more completely automated, and more efficiently executed, and
more cost-efficient.
Second, build
management tools continue to mature. CruiseControl,
one of the leading tools in build management, has recently improved its
dashboard capability such that it is now easier to manage and oversight multiple
builds in a pipeline from a console. CruiseControl
also supports widgets that allow customized reporting and analysis. This makes it possible to develop widgets that
integrate reporting on functional and non-functional tests through the build
dashboard. A currently available widget
- Panopticode - provides this today
for detailed code quality reporting. As
the demand increases for manage a complex array of environments, and as build
pipelining practices mature, look for future commercial offerings and
extensions to CruiseControl
to provide greater support and capability in defining, managing, and executing
discreet paths through a build pipeline.
Emergent Agile ALM
Agile
project management tools must be similarly mature if they are to meet the
challenges of large, complex projects. On
small projects, Agile requirements, called "User Stories," are written on index
cards that are pasted to a wall, giving a visual representations of what is
happening to a project. This visibility is
very powerful as it engenders a sense of shared understanding among people on a
project. Obviously, it is difficult to
scale a wall of index cards beyond a single team in a single location, so as
teams grow they typically rely on spreadsheet-based tracking solutions.
The
spreadsheet based solutions, while no doubt powerful, can be difficult to
scale. Spreadsheet-based trackers expire
quickly as the project data is out of date with each iteration. Further, being
spreadsheet-based, these trackers facilitate, if not outright inspire,
variation in the calculations and reporting structures. The short shelf-life of
the data plus the ease of changing spreadsheet macros makes version control of
spreadsheet trackers a challenge. The dynamism
of the tracker can make iteration tracking appear to be ad hoc, which
undermines discipline and consistency in how Agile project management is
practiced, particularly in teams new to Agile.
Finally, it is very cumbersome to coordinate spreadsheets across
multiple in-flight projects. To remedy
these limitations, commercial applications are available that integrate Agile
requirements definition, iteration management, adaptive release planning and
project status reporting.
The focus
of Agile project management practices and tools has been status reporting on progress
against User Stories, which are either done or not done. The underlying activity and artifacts created
are disjointed from Agile project management tools. This type of activity has, by and large, been
the purview of collaboration tools and configuration management platforms. But while these tools, such as SourceForge Enterprise, offer
activity tracking, they offer little in the way of project management
capability.
These
capabilities are converging. Next
generation Agile Project Management tools increasingly provide Application
Lifecycle Management 2.0 capability in an Agile context. Specifically, Agile project management functionality
is being combined with activity tracking and artifact linking across the solution
chain. Activity tracking in these tools
is not recording time to a project hierarchy that matches a General Ledger code. Instead, all activity - writing narratives,
code, tests and so forth - performed to satisfy an Agile User Story is
logged. This is supplemented by linking together
all the artifacts - requirements, code, tests, defect reports, user
documentation, and even builds - that form the solution. Convergence of project management with
activity/artifact tracking happens through workflows associated with each
requirement. By triggering a workflow,
the lifecycle of each requirement is tracked over time, bringing visibility to everyone
and everything in each solution chain.
The workflow also refines project status reporting, which can provide
visibility to the most granular of tasks.
How this next generation of capability is taking shape can be seen in Mingle.
The ALM
2.0 capability in Agile Project Management tools addresses two key hesitations to
adopting Agile in large programs. First,
the ability to configure the development workflow allows these tools to strike
a critical balance of consistency and flexibility. This means they offer enough
flexibility so as not to be the "one size fits all" solution that never does,
but not so much flexibility that a project devolves into a state of process
free-for-all. This, in turn, creates process
consistency across teams as well as more rapid Agile adoption. Second, the integration of project management
and solution chain tracking means these tools can satisfy enterprise and
regulatory mandates for compliance in change control. These issues often drive
people toward top-down-control-based approaches that stifle individual activity
through redundant verification of intent and action. Because these capabilities are fundamental to
this next generation of tools, they can inherently support these governance
mandates without hindering development. The
ability to be responsive is therefore aligned with governance needs of the
business environment.
Structuring Flexibility to Scale
Attempting
to scale "first generation" Agile practices to very large programs can cause
more harm than good. On the one hand, inefficiencies
that arise from implementing only the basics can lead people to believe that
Agile practices do not scale to the needs of large, complex projects. On the other, making too many adjustments to
respond to scale can lead people to conclude that Agile practices are
inconsistent. Recent innovations in
Agile practices and tools provide flexibility without sacrificing the rigor of
the fundamental Agile practices. This
structured flexibility engenders consistency and scalability, key characteristics
of successful projects.
About the Author
Ross
Pettit has 15 years' experience as a developer, project manager, and program
manager working on enterprise applications. A former COO, Managing Director,
and CTO, he also brings extensive experience managing distributed development
operations and global consulting companies. His industry background includes
investment and retail banking, insurance, manufacturing, distribution, media,
utilities, market research and government. He has most recently consulted to
global financial services and media companies on Agile transformation programs,
with an emphasis on metrics and measurement.
He is a frequent speaker and active blogger on topics of Agile
management, governance and innovation.
He is currently a Client Principal with ThoughtWorks.
Agile Journal 
As Agile practices prove successful in small project
teams, there is increasing demand to roll them out to large programs or across
entire departments. Such large-scale
adoptions demand that the practices be rapidly implemented and consistently
executed, and that they work with the most stringent corporate governance
standards. What makes this difficult is
that complex projects can strain Agile practices. New practices and tools in build pipelining as
well as emerging application lifecycle management (ALM) 2.0 capabilities in
Agile project management tools will make it possible to scale Agile practices into
very large and complex development initiatives.
