Adaptive Software Development
Adaptive Software Development, or ASD for short, was developed by James A. Highsmith III, and published in (Highsmith 2000). Many of ASD’s principles stem from Highsmith’s earlier research on iterative development methods. The most notable ancestor of ASD, “RADical Software Development”, was co-authored by Highsmith and S. Bayer, and presented in (Bayer and Highsmith 1994).
ASD focuses mainly on the problems in developing complex, large systems. The method strongly encourages incremental, iterative development, with constant prototyping. Fundamentally, ASD is about “balancing on the edge of chaos” – its aim is to provide a framework with enough guidance to prevent projects from falling into chaos, but not too much, which could suppress emergence and creativity.
An Adaptive Software Development project is carried out in three-phase cycles. The phases of the cycles are Speculate, Collaborate, and Learn.
The phases are named in a way to emphasize the role of change in the process. “Speculation” is used instead of “Planning”, as a “plan” is generally seen as something where uncertainty is a weakness, and from which deviations indicate failure. Similarly, “Collaborate” highlights the importance of teamwork as the means of developing high-change systems. “Learn” stresses the need to acknowledge and react to mistakes, and the fact that requirements may well change during development.
Figure below illustrates the adaptive development cycles in more detail. The Project Initiation phase defines the cornerstones of the project, and is begun by defining the project mission. The mission basically sets a coarse frame for the end product, and all development is steered so that the mission will be accomplished. One of the most important things in defining the project mission is to figure out what information is needed in order to carry out the project. The important facets of the mission are defined in three items: a project vision charter, a project data sheet, and a product specification outline. The meaning of these documents is explained in detail in (Highsmith 2000). The Project Initiation phase fixes the overall schedule, as well as the schedules and objectives for the development cycles. The cycles typically last between four and eight weeks.
ASD is explicitly component-oriented rather than task-oriented. In practice, this means that the focus is more on results and their quality rather than the tasks or the process used for producing the result. The way ASD addresses this viewpoint is through adaptive development cycles that contain the Collaborate phase, where several components may be under concurrent development. Planning the cycles is a part of the iterative process, as the definitions of the components are continuously refined to reflect any new information, and to cater for changes in component requirements.
Basis for further cycles (the “Learning Loop” in Figure above) is gained from repeated quality reviews, which focus on demonstrating the functionality of the software developed during the cycle. An important factor in performing the reviews is the presence of the customer, as a group of experts (called customer focus-group). However, since the quality reviews are rather scarce (they take place only at the end of each cycle), customer presence in ASD is backed up by joint application development (JAD) sessions. A JAD session is essentially a workshop, where developers and customer representatives meet to discuss desired product features, and to enhance communication. ASD does not propose schedules for holding JAD sessions, but they are pointed out as particularly important in the beginning of a project.
The final stage in an Adaptive Software Development project is the Final Q/A and Release stage. ASD does not consider how the phase should be carried out, but stresses the importance of capturing the lessons learned. Project postmortems are seen as critically important in high-speed and high-change projects, where agile development takes place.
As a summary, the adaptive nature of development in ASD is characterized by the following properties:
Roles and responsibilities
The ASD process largely originates from organizational and management culture and, especially, the importance of collaborating teams and teamwork. All these issues are given a lot of thought in (Highsmith 2000). The approach does not, however, describe team structures in detail. Likewise, very few roles or responsibilities are listed. An “executive sponsor” is named as the person with overall responsibility for the product being developed. Participants in a joint application development session are the only other roles mentioned (a facilitator to plan and lead the session, a scribe to make minutes, the project manager, and customer and developer representatives).
ASD proposes very few practices for day-to-day software development work. Basically, (Highsmith 2002) expressly names three: iterative development, feature-based (component-based) planning, and customer focus group reviews. Indeed, perhaps the most significant problem with ASD is that its practices are difficult to identify, and leave many details open. ASD has hardly any practices that should be done; most issues covered in the book are rather like examples of what could be done.