Shaping
an Agile process that delivers value is not a selection of prescriptive
actions. It is a conscious effort to fit
and mature best practices in an environment.
Three core questions guide this process:
What will provide sufficient
completion integrity for the work we do?
What will create meaningful
transparency of the work being done?
What are the underlying
organizational constraints that will impede changes in the way work is
done?
Focusing
on these questions allows an IT organization to master new ways of working
while minimizing business disruption.
Engineering Best Practices:
Integrity of Completion
One
characteristic of Agile development is that it doesn't mortgage the future by
deferring activities such as build, integration, and test to later stages of a
project. In Agile, these are performed
as closely as possible to the moment when code is created. Codifying success criteria in tests before
executable code is written, immediately subjecting committed code to build and
execution of automated tests, and pairing developers on work provides a higher
degree of certainty that work committed is work completed. As a result, when something is asserted to be
complete in an Agile project, it is less a matter of opinion and more a matter
of fact.
While
there are a
Advertisement
defined set of Agile practices that engender this, there is not a
prescribed set of activities to fulfill them.
A project's circumstances and characteristics will determine the extent
to which each practice should be adopted.
If they are too aggressively applied, they may add little value. If they are not aggressively applied, Agile
practices may yield no demonstrable benefits.
Consider
the extent to which continuous integration is adopted. Some technologies like C++ and COBOL may not
be able to support it. Simply because
they don't support continuous integration, however, does not mean that these
technologies do not benefit from the adoption of Agile build practices. There is certainly benefit in reducing the
latency between code commit and build, so in these circumstances maximizing
build efficiency -- even if simply a daily event -- will add value. Tools such as CruiseControl can support
atypical Agile technologies and different build cycles.
The
extent to which the build is implemented as a gatekeeper of code quality also
varies depending on the nature of the team.
In a large, geographically distributed team of varying skill levels, it
is extremely valuable for tests and code quality analyses (using technologies
such as PMD and Checkstyle) to be implemented as gatekeeper events each time
code is committed. By comparison,
gatekeepers might be a waste of time in small, co-located teams, where a simple
portal into build information is usually sufficient.
It may
not always be desirable to target high unit test coverage. Consider a time-constrained project in a
highly dynamic business domain where requirements change often and
dramatically. In this case, quality may
be a low priority relative to time and features. High unit test coverage might be a waste of
effort as a lot of code will simply be disposed. It might be more effective to write unit
tests at the most granular level of the requirements, such as for elemental
calculations, and increase unit test coverage only after the domain itself is
better understood. There are also
technology limitations: legacy languages do not lend themselves to unit
testing. The somewhat cumbersome
mechanisms by which this can be achieved (e.g., .NET wrappers to MQ over CICS
to invoke COBOL processes) suggest there is a limited amount of coverage that
can be achieved. Still, creating
testable architectures and achieving some degree of unit test coverage is
preferable to electing to do neither.
Clearly,
there is not a universally applicable definition of specific engineering
activities that enable agility. Each are
practiced to varying degrees. The extent to which they are practiced determines
the degree of confidence in task completion.
Project Management Best Practices:
Transparency
In
conjunction with completion integrity, it is also important to know, as
specifically as possible, what people are doing. Adopting Agile engineering practices without
project management practices will improve fundamental delivery quality more
than it will achieve IT responsiveness.
To have greater responsiveness requires visibility into what's going
on.
Agile
achieves transparency through the way in which requirements are expressed,
teams are organized, collaboration is achieved, and progress is tracked. The core Agile practices that support this - story-based
requirements, co-location, iterative delivery, and so forth - are themselves
not turnkey to a situation, but again must be adjusted to achieve the
appropriate fit for the circumstance.
Consider
a geographically distributed team of several hundred people. It isn't uncommon for a project like this to
be decomposed into separate teams working in silos, instead of everybody
working from the same pool of requirements.
These silos will affect how requirements are expressed: high-level
business requirements may need to be fulfilled through multiple teams working
on subsets, each communicating through messaging. This does not obviate the value of
introducing some degree of story-based requirements: even where there are
silos, such "pseudo-stories" can allow each team to work on
independent (or at least decoupled), testable requirements that can be clearly
tied to business value.
Separately,
consider the extent to which project management needs to be formalized. A co-located team may benefit from the
visibility of a project "story card wall" that visibly shows
requirements in different stages: completed, in backlog, in-flight and
on-deck. However, a geographically
distributed team makes a physical card wall impractical. In this case, project tracking and reporting
(using tools such as Mingle)
give everybody visibility into project status.
The same factors affect the degree of business collaboration as well:
while it is desirable to have the business co-located with the development
team, geographic separation will make this an impossibility. This does not eliminate the benefit of having
business knowledge co-located, so co-locating a proxy for the business -- such
as an analyst immersed in the business problem -- can yield much the same
benefit.
The
practice of release planning will vary dramatically depending on the
environment. A highly dynamic domain
might relegate release planning to little more than an exercise of
"wishful thinking." Publishing
a release plan under such circumstances can mislead all project stakeholders
and undermine a team. In this case, the
XP approach of planning by "yesterday's weather" may be the safest
way to manage expectations. By
comparison, release planning in a more stable domain vastly improves project
portfolio management. Not performing
release planning under these circumstances can make a team appear that it is
not master of its domain.
One
additional situational consideration is the degree of panic in a
situation. A project in need of
crisis-management due to frequent production failures or defects will benefit
from the Scrum approach of a daily stand-up executed in intermediate-length (e.g.
one month) time boxes. By comparison, a
customer that cannot consume frequent releases will likely benefit from
consistency achieved by a series of longer iterations and release cycles more
common to Agile.
All told,
then, transparency is not achieved in a prescriptive set of activities, but by
the application of those practices that maximize transparency given the
situation.
Overcoming Challenges Versus Managing
Constraints
This
should not create the impression that Agile practices are a matter of picking
and choosing. There is a demonstrably
synergistic benefit: when these practices are fully implemented, they yield
simultaneously a high degree of both quality and responsiveness. While the different families of Agile
practices - Crystal,
XP, Scrum, and so forth - offer different perspectives on how to achieve
agility, they should not be assumed to be turnkey solutions. For example, the "yesterday's
weather" approach to forecasting in XP might be extremely valuable in
highly dynamic domains, but the emphasis on 100% unit test coverage might may
be substantially wasted effort in the same circumstance. Similarly, adopting Scrum management without
Agile engineering practices may result in project management and technical
execution not being fully aligned.
Regardless the approach, a granular understanding -- and fitting -- is
in order.
It must
also be recognized that Agile practices can be severely compromised by
accepting every constraint in an environment.
Agile practices are commonly introduced in response to an
organizational challenge, such as quality, consistency, or responsiveness. Accepting the challenge but living within
constraints will yield sub-optimal results.
For example, Agile release planning assumes there is "collective
code ownership:" the entire codebase is "owned" by the
team. Accepting a situation where
development is done in silos can lead to "swim lanes" if managed
poorly. Especially when code in these
silos is highly coupled, this can lead to dependencies that relegate Agile
release planning into a Waterfall model.
Similarly, if quality assurance is a shared service bound by fulfillment
from a single geographic location, it is very likely that the QA team will be
overrun, unable to respond to the rate of change coming from an Agile
development team. This will completely
obviate improvements to development responsiveness.
The
process of taking on Agile, then, is as much fitting Agile to an environment as
it is adjusting the environment to be more responsive. This might involve
re-architecting an application and aggressively pairing developers to slowly
widen the silos, with the intent of eliminating code specializations over
time. It might require a complete
restructure of a QA department, investing in domain knowledge and technical
capability both so that delivery teams are business focused, not IT practice
focused. Whatever the solution, there
must be a focus on the challenge, not the constraint. Constraints can stifle and completely
undermine attempts at greater agility.
People Over Process
While
Agile practices are fit into an environment, and an environment is changed to
engender greater agility, process does not translate into execution. Change in the way work is done will only
succeed if the people doing the work master the change. When mapping out an Agile process, bear in
mind that individual commitment is facilitated through participation more than
it is through top-down edict. Defining
the constructs of process is helpful; engaging the practitioners in that
definition is essential. 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.
Articles 
Shaping
an Agile process that delivers value is not a selection of prescriptive
actions. It is a conscious effort to fit
and mature best practices in an environment.
Three core questions guide this process:
