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 at any level above a small group. Certainly for enterprise sized projects changing requirements are an indicator of bigger problems at the strategy level.

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 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 behavior accordingly.

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 however.