Agile software development methods

From Amachu
Jump to: navigation, search

The field of software development is not shy of introducing new methodologies. Indeed, in the last 25 years, a large number of different approaches to software development have been introduced, of which only few have survived to be used today.

While no agreement on what the concept of “agile” actually refers to exists, it has generated a lot of interest among practitioners and lately also in the academia. The introduction of the extreme programming method has been widely acknowledged as the starting point for the various agile software development approaches. There are also a number of other methods either invented or rediscovered since then that appear to belong to the same family of methodologies. Such methods or methodologies are, e.g., Crystal Methods, Feature-Driven Development and Adaptive Software Development.

Despite the high interest in the subject, no clear agreement has been achieved on how to distinguish agile software development from more traditional approaches. The boundaries – if such exist – have thus not been clearly established.

Agile overview, definitions and characterizations

Agile – denoting "the quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion" – software development methods are attempting to offer once again an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment.

Overview and definitions

The “Agile Movement” in software industry saw the light of day with the Agile Software Development Manifesto published by a group of software practitioners and consultants in 2001. The focal values honored by the agilists are presented in the following:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These central values that the agile community adheres to are:

First, the agile movement emphasizes the relationship and communality of software developers and the human role reflected in the contracts, as opposed to institutionalized processes and development tools. In the existing agile practices, this manifests itself in close team relationships, close working environment arrangements, and other procedures boosting team spirit.

Second, the vital objective of the software team is to continuously turn out tested working software. New releases are produced at frequent intervals, in some approaches even hourly or daily, but more usually bi-monthly or monthly. The developers are urged to keep the code simple, straightforward, and technically as advanced as possible, thus lessening the documentation burden to an appropriate level.

Third, the relationship and cooperation between the developers and the clients is given the preference over strict contracts, although the importance of well drafted contracts does grow at the same pace as the size of the software project. The negotiation process itself should be seen as a means of achieving and maintaining a viable relationship. From a business point of view, agile development is focused on delivering business value immediately as the project starts, thus reducing the risks of non-fulfillment regarding the contract.

Fourth, the development group, comprising both software developers and customer representatives, should be well-informed, competent and authorized to consider possible adjustment needs emerging during the development process life-cycle. This means that the participants are prepared to make changes and that also the existing contracts are formed with tools that support and allow these enhancements to be made.

According to Highsmith and Cockburn, "what is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability. This yields a new combination of values and principles that define an agile world view."

Cockburn defines the core of agile software development methods as the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules. The agile process is both light and sufficient. Lightness is a means of remaining maneuverable. Sufficiency is a matter of staying in the game. He proposes the following "sweet spots" the presence of which in software development work enhances the prospects for a successful project outcome:

  • Two to eight people in one room
    • Communication and community
  • Onsite usage experts
    • Short and continuous feedback cycles
  • Short increments
    • One to three months, allows quick testing and repairing
  • Fully automated regression tests
    • Unit and functional tests stabilize code and allow continuous improvement
  • Experienced developers
    • Experience speeds up the development time from 2 to 10 times compared to slower team members.


Miller gives the following characteristics to agile software processes from the fast delivery point of view, which allow shortening the life-cycle of projects:

  1. Modularity on development process level
  2. Iterative with short cycles enabling fast verifications and corrections
  3. Time-bound with iteration cycles from one to six weeks
  4. Parsimony in development process removes all unnecessary activities
  5. Adaptive with possible emergent new risks
  6. Incremental process approach that allows functioning application building in small steps
  7. Convergent (and incremental) approach minimizes the risks
  8. People-oriented, i.e. agile processes favor people over processes and technology
  9. Collaborative and communicative working style

Favaro discusses the emergence of strategies for confronting a vague process showing changing requirements. He proposes the iterative development paradigm as the common denominator of agile processes. Requirements may be introduced, modified or removed in successive iterations. Once more, this approach featuring changing requirements and delayed implementation calls for new contractual conventions. These are, e.g., transition from point-view contracts (nailing down the requirements up front) towards process-view contracts, and also the consideration of the anticipation of legal aspects in relationship evolvement.

These theoretical legal aspects,however, are still in their beginning, not to mention the concrete capitalization of these new contractual phenomena. Also the framework contracts efficiently used together with relevant project or work order agreements reflect the ongoing development in software business, which inherently supports this kind of agile software development.

Highsmith and Cockburn report that the changing environment in software business also affects the software development processes. According to the authors, to satisfy the customers at the time of delivery has taken precedence over satisfying the customer at the moment of the project initiation. This calls for procedures not so much dealing with how to stop change early in a project, but how to better handle inevitable changes throughout its life cycle. It is further claimed that agile methods are designed to:

  • produce the first delivery in weeks, to achieve an early win and rapid feedback
  • invent simple solutions, so there is less to change and making those changes is easier
  • improve design quality continually, making the next iteration less costly to implement, and
  • test constantly, for earlier, less expensive, defect detection.

The basic principles of agile methods comprise an unforgiving honesty of working code, effectiveness of people working together with goodwill, and focus on teamwork. A set of commonsense approaches emerging from agile software development processes have been suggested by Ambler as follows:

  • people matter
  • less documentation is possible
  • communication is a critical issue
  • modeling tools are not as useful as usually thought
  • big up-front design is not required

Boehm analyses the agile and process-oriented methodologies or plan-driven as he calls them. The OSS is still fairly new in business environment and a number of interesting research questions remain to be analyzed and answered. Thus the OSS approach can be seen as one variant of the multifaceted agile methods.

Personal tools