18.1 Agile Development

Agile software development centers on four values identified in the Agile Alliance's Manifesto:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Agile development is not a development model as such, but the values are used in a number of development models and frameworks, of which the most commonly known are perhaps the eXtreme Programming (XP) model, Crystal Methodologies, and SCRUM. The keywords in agile development are, in short, change and communication. This makes configuration management one of the more important areas of activity if agile development is to succeed. Iterative development models are strongly related to the agile development philosophy, though not all of the values are found in the more commonly used iterative models.

Configuration Management in Agile Development

The words "configuration management" are hard to find in the literature about agile development. Configuration management is, however, an undercurrent in many of the twelve principles defined for agile development. Those that touch on configuration management are listed and discussed below:

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale .

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Empowered Teams

The best emerges from self-organizing teams giving continuous attention to technical excellence. Agile development will not work with only inexperienced people. Only when you know the principles of what you're going to do and have some experience can you loosen formality and get better results.

Technical excellence in software development encompasses configuration management. It should be a natural part of forming self-organizing teams to share their experience, including configuration management, and agree on processes and practices to followat least at the start of the process, since processes are also subject to change in agile development. The general principles of configuration management (identification, storage, change control, and status reporting) should be observed and tailored to the product type and other determining factors, observing the principle of working smarter , not harder.

Process Handling

Agile development does not mean that no processes are defined or followed. On the contrary, processes are agreed upon and accepted among participantsmanagement, developers, and customers (or businesspeople)on equal terms. At regular intervals, the team reflects on how to become more effective, then adjusts its behavior accordingly . This means that processes are revised by agreement and new processes are immediately communicated to those involved. The detailed planning horizon in agile development is naturally not long. The focus is on continuous replanning according to needs, with only short- term detailed planning.

This is also valid for configuration management: only short-term, detailed configuration management planning should be performed. However, it's both necessary and possible to plan and define configuration management processes in more and more detail as the project progresses. The way to perform configuration management for the relevant types of objects produced should be planned as early as possiblehow to identify and store objects and how to control the changes to come.

In agile development, changes to the product are the norm, and so are changes to the processes. You'll rarely find company-wide processes in such an environment, but the teams should be encouraged to share their experiences and inspire each otherand maybe also inspire company-wide processes, if possible.

Environment and Support

Part of keeping good people motivated is to give them the work environment and support they need. This includes providing facilities to perform necessary configuration management: people, tools, hardware, and access to appropriate company processes. This is not to say that configuration management should be imposed from management but that it should be carefully organized, including providing sufficient people to fulfill configuration management roles. In agile development, the responsibility for configuration management will be shared in the teams, and it's a good idea to have responsibility for the more administrative and tedious tasks , such as a frequent build of the system, circulate among team members .

Professional configuration management requires sufficient support and a good working environment. It's not easy, for example, to work fast with good configuration management if it's impossible or difficult to control the physical storage facilities (e.g., inability to separate development, test, and production environments). Keeping large portions of the system separate in specific development workspaces is important to the success of agile development.

Requirements Management

Agile development welcomes changing requirements, even late in development. Requirement management is therefore of utmost importance for creating a stable and valuable product. Requirements come in many shapes and forms, not least in agile development, where the emphasis is on understanding the requirements, rather than having them elaborately documented. However, it's necessary for the teams to agree on a way or ways of getting and keeping requirements identified.

It's a good idea to be aware of the granularity of configuration items related to the requirements. Are changes going to be documented in terms of story cards, use cases, detailed requirements, overall business requirements, or another category? Don't make the granularity too fine too early, but adjust the granularity from coarser to finer as need and knowledge grow. In any case, don't just use a few high-level business requirements as the basis. Tracing requirements to software code and test specifications is essential. This enables fast identification of the implications of changes to requirements during the product's life cycle.

Working Together

Business people and developers must work together. This means that business people and developers are constantly making decisions together. An important decision to make often in agile development is prioritization of requirements, but decisions could also be in terms of changes to requirements or to interpretations of requirements. Decisions determine the direction of a product and are part of active change control.

Business people and developers should agree on a way of documenting decisions they make relative to configuration itemsto requirements and software code and the traces between theseas this information is valuable for sustainable, fast development. If decisions are not captured, even the best teams run the risk of getting into an unstable situation, where decisions are made and remade.

Frequent Delivery of Working Software

Working software is the primary measure of progress and should be delivered frequently. To do this, the group must be able to build working versions of the system as easily as possible. This is such an important issue, it's discussed separately in the following paragraphs.

Communication and Documentation

Lack of communication within a project has been identified as a root cause for problems. Communication underlies the values for agile development. Communication is between people and should embrace not only developers but the business people involved. Agile development values working software over documentation. This doesn't mean there is no documentation but that documentation is kept to a minimum. Configuration management should focus on using source code as the means of communicating and capturing information. Coding standards, which the teams should form and agree on, should support this.

Coding standards and supporting templates may well include facilities for managing identification (including all necessary metadatanot least tracing information), event registration, and change request handling. Also, test specifications should be self-documenting in terms of identification, including trace information.

Status Reporting

Status reporting is perhaps not too important in an agile environment, especially not as formal reports , because frequent builds and deliveries of working products document the progress. It should, however, be possible to easily extract information for making decisions, preferably online. This is primarily trace information for source code and test specifications and customer-related documentation.