Adaptive Software Development (ASD) embodies principles that teach continuous adaptation to the work at hand is the status quo. ASD was created to replace traditional Waterfall variants. In a general sense, ASD processes represent a repeating series of speculate, collaborate and learn cycles.

“Speculate” refers to the planning paradox—outcomes are unpredictable, therefore, endless suppositions on a product’s look and feel are not likely to lead to any business value. Some important dimensions are more than likely wrong. Hypothesize a rough idea of what you need and plan to adapt. The big idea behind speculate is when we plan a product to its smallest detail as in a requirements up front Waterfall variant, we produce the product we intend and not the product the customer needs. In the ASD mindset, planning is to speculation as intention is to need.

Paraphrasing Highsmith,¹ he said, “Collaboration… portrays a balance between managing the doing and creating and maintaining the collaborative environment.” Speculation says we can’t predict outcomes. If we can’t predict outcomes, we can’t plan. If we can’t plan, traditional project management theory suffers. Collaboration counterpoises speculation in that a project manager plans the work between the predictable parts of the environment and adapts to the uncertainties of various factors—stakeholders, requirements, software vendors, technology, etc.

“Learning” cycles challenge all stakeholders and project team members. Based on short iterations of design, build and testing, knowledge accumulates from the small mistakes we make due to false assumptions, poorly stated or ambiguous requirements or misunderstanding the stakeholders’ needs. Correcting those mistakes through shared learning cycles leads to greater positive experience and eventual mastery of the problem domain.²

An adaptive software development process was first described in 1974 in a paper written by Dr. Ernest A. Edmonds named A Process for the Development of Software for Non-Technical Users as an Adaptive System, General Systems, Vol. XIX, pp.215-218. Dr. Edmonds is Director of Creativity & Cognition Studios, University of Technology, in Sydney, Australia. He writes in an abstract of the paper on his website³ and says:

The aim of the paper is to describe the process of software development as it often occurs unintentionally, in a way that might make it easier to recognize what is happening…

…It is suggested that the solution proposed may also allow users to adapt their methods at the same rate as the development of the software, giving a smooth and well understood change in the system.

Edmond’s subsequent works further describe his approach to iterative adaptive processes. The idea apparently caught on. In the mid-1990s a number of adaptive processes sprang up throughout the IT industry. Prominent early methods include Rapid Application Development and Scrum (1991), Crystal (1992), Extreme Programming, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Model (DSDM) (1995). These are now collectively referred to as Agile Methodologies, after the Agile Manifesto published in 2001.

It’s hard to define exactly what an agile software process is. There are so many approaches to agile software development; there is no one size fits all, yet they all share common best practices. Scott Ambler, author of Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, Wiley; 1st edition (March 21, 2002), puts it this way:

Disciplined agile software development is: An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholder.

To learn more about Agile development methodologies and how they may fit into your flexible SDLC, order The Ultimate Guide to the SDLC today.