This document discusses and analyzes the principles outlined in the Agile Alliance manifesto. It notes that while the principles seem logical, unlike other manifestos they do not clearly define the domain or context in which they are meant to be applied. As a result, the principles risk being too general and unclear to implement effectively. The document then examines each principle individually, noting that more context and guidance is needed to understand how to apply them in specific domains or situations. Overall, it finds the principles have value but would benefit from more specialized guidance on their practical implementation.

1. The 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 establishment.
An Information Systems Manifesto, James Martin, Prentice Hall, 1984 comes to mind
as a model for an Informaton Technology change agent. In Martin's book he uses the
Random House Dictionary definition. Manifesto: A public declaration of intentions,
objectives, opinions, or motives.
From James Martin's preface:
"An 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, unlike James Martin’s they don't state a specific
context in which they are to be applied. Unlike Martin as well, no domain of
application is stated, leaving the principles open to criticism of being too general,
therefore losing their effectiveness.
Below is an examination of the principles with an attempt to answer the question –
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?
None of this criticism takes away from the value of the agile principles. What is
missing is the specialization of these principles in a context. Similar criticisms can be
found in Project Management bodies of knowledge, which are normative in nature
and therefore difficult to apply in specific contexts and domains. What is needed
here, like the project management principles are the heuristics of how to generate
value for the community of practice. As agile methods mature, these heuristics as
well as the identification of which participants involved in the principles will mature
as well.

2. Agile Alliance Principles Principles Examined
Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.
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
circumstance.
Welcome changing
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.
But 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.
A 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 requires 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 are imposed by
contract, geography, regulatory, or safety requirements.
This principle is a tautology, but provides no suggestions for
alternatives or how to blend alternatives into an agile process.
Working software is the
primary measure of
Although working software is an outcome of development,
there are other critical deliverables and measures of progress