Agile Alliance has stated in their manifesto, principles by which a process
would be considered agile. These principles provide useful guidelines for
evaluating a specific process as to its suitability to be considered agile. Like
previous manifestos there is some sense of political challenge to the
Information Systems Manifesto, James Martin, Prentice Hall, 1984 comes to
mind as a model for an Information Technology change agent. In Martin's book he uses the Random House Dictionary
definition. Manifesto: A public declaration of intentions, objectives,
opinions, or motives.
Information Systems Manifesto is designed to provide ... a
strategy and direction on how to change and manage the dramatically changing
environment of information systems and data processing. The revolution described
in information systems is already in progress. Yet many corporations ignore it
or fail to recognize the impact it will have on their organizations. The intent
of this book is to provide people with the information they need to direct and
implement these changes successfully."
Although many of the principles in the Agile Alliance manifesto sound familiar
and appear to be generally logical, they don't state a specific context in which
they are to be applied. Unlike Martin, no domain of application is stated,
leaving the principles open to criticism.
Below is an examination of the principles from
the point of view – in what domain are these principles generally applicable and
what specific guidelines are provided in that domain as well as what specific
rationale supports the principles?
Our highest priority is to
satisfy the customer through early and continuous delivery of valuable
The concept of customer
value for work performed is well developed in any business
domain. However definitions of value, early, and
satisfaction are not provided in the agile literature, so domain specific definitions need to be
developed before this principle can be of practical use in a specific
requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
Agile processes contribute to success in these situations. This might be
considered the operational definition of agility. Early and
repetitive feedback on product or project design is good practice in most
engineering disciplines today.
changing requirements may be an indication of changing business values,
unstable requirements, or a lack of understanding of the desired business
outcome. Without stable business success metrics, the creation of software
to address unstable requirements is unlikely to be good business strategy
at any level above a small group. Certainly for enterprise sized projects
changing requirements are an indicator of bigger problems at the strategy
close examination of why these requirements are changing is an
important risk assessment step in determining if agile process will be
successful in their presence.
Late detail binding and
separation of concerns can support changing requirements, however decisions
must still be made to identify the area that require flexibility to deal
with changing requirements.
Deliver working software
frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.
Agility helps here, but in
general, iterative and incremental methods exhibit this as a behavior,
including the cousin of waterfall, the Spiral methods – without the necessary
being re–labeled as
agile. The concept of rapid prototyping is standard practice in many
manufacturing and engineering processes. The granularity of the deliverables
is the issue here. The question is – what is the appropriate
absorption rate of the software iteration for a specific domain?
Business people and
developers must work together daily throughout the project.
This is common business
practice in successful organizations. The definition of the customer
is restrictive in many of the agile process methods, especially when
building products rather than projects. The granularity of the interaction
is again the issue. If the customer is co–located, direct daily interaction
is possible. If not then some other form of communication is necessary.
Documentation starts to play a more significant role in these cases.
Build projects around
motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
This is common business
practice in successful organizations – it’s the people that make a project
successful. From Jack Welsch down to the local coffee shop, all good business
managers understand this principle. Practicing this principle however is
much more difficult.
The most efficient and
effective method of conveying information to and within a development team
is face–to–face conversation.
Although this is the basis of Agile processes, this is neither unique
nor many times practical and in many cases may not even be desirable.
Written specifications are useful in many instances and in others instances
they imposed by contract, geography, regulatory, or safety requirements.
This principle is a
tautology, but provides not suggestions for alternatives.
Working software is the
primary measure of progress.
Although working software
is an outcome of development, there are other critical deliverables
and measures of progress as well that are not addressed by many of the
Agile processes. The focus on software alone misses many opportunities
for process improvement prior to and after the generation of code.
Agile processes promote
sustainable development. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Although a goal, the
agile process has little to say on how to achieve this in practice for a
specific environment. As well, the statement on sustainability is a
conjecture not yet supported by field evidence.
Continuous attention to
technical excellence and good design enhances agility.
This is the basis of many
good engineering practices. The metrics of technical excellence and good
design are not stated however, leaving them open to interpretation.
Simplicity – the art of
maximizing the amount of work not done – is essential.
Without a context, the term simplicity has no meaning. What is simple
in one domain may be appear complex when viewed from another.
This principle fails to
address non–functional and extra–functional requirements of product and
project based processes which are the sources of much of the complexity in
large scale systems.
The best architectures,
requirements, and designs emerge from self–organizing teams.
This is conjecture and
is not based on analytical measurements. This principle does not state the
domains in which it is applicable. The science of systems engineering
has much to say here, but no recognition to this previous work is provided.
At regular intervals, the
team reflects on how to become more effective, then tunes and adjusts its
This is good team
development practice independent of the software environment. No metrics are
provided by which to assess past behavior for adjust of future behavior