• Chief Information Officer
• Application Support Officer
• SALES ENGINEER- NATIONAL UPS...
• Project Manager Operational Systems
• Business Program Manager - Large...

Putting agility in context

Glen Alleman, Information Age

10/08/2002 17:13:33

Putting agility in context

The Agile Alliance has stated in its 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 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.

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 recognise the impact it will have on their organisations. 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 specialisation 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 are involved in the principles will mature as well.

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 areas 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 time scale.

Agility helps here, but in general, iterative and incremental methods exhibit this as a behaviour, including the cousin of waterfall, the Spiral methods - without the necessary being relabelled 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 organisations. 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 organisations - 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. Practising 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 other instances they are imposed by contract, geography, regulatory, or safety requirements.

This principle is a tautology, but provides no 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 maximising 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 that are the sources of much of the complexity in large-scale systems.

The best architectures, requirements, and designs emerge from self-organising 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 behaviour accordingly.

This is good team development practice independent of the software environment. No metrics are provided by which to assess past behaviour for adjustment of future behaviour however.

Glen Alleman is the CTO of Niwot Ridge Consulting in Colorado, specialising in enterprise application integration, system architecture, business process improvement and project management applied to a wide range of industries.