Navigate to
Adaptive Software Development: Thrive At The Edge Of Chaos
- 12 mins read
-
By Marjan Venema
- Updated on January 31, 2024
Overview of Adaptive Software Development
You’re familiar with agile software development methodologies, especially the two big-guns, extreme programming and scrum.
However, every now and then, something you’re unfamiliar with crosses your radar. ASD (Adaptive Software Development) might be one of those. As one of the lesser known of the agile methodologies, it’s understandable if you don’t know much about it.
However, that doesn’t imply you shouldn’t know more about it.
As one of the earliest agile methodologies in town, ASD brought ideas and concepts to the table that are certainly worth knowing about. Its insistence on closer collaboration with the clients and its willingness to embrace the intrinsic uncertainty in software projects are interesting traits that have echoed in latter methodologies.
By the end of the article, you’ll have a more solid understanding of ASD, including how it works and what are its similarities and differences with other agile methodologies—particularly feature-driven development and extreme programming.
Brief Overview
Adaptive Software Development (ASD) is a development methodology created by Jim Highsmith and Sam Bayer, a duo of project managers. ASD advocates that the proper way to achieve success when it comes to complex software projects is to continuously learn throughout the project, while not sticking to rigid plans.
Adaptive software development (ASD) phases, adapted from Pressman
In ASD, projects happen in an iterative cycle composed of three overlapping phases: speculation, collaboration, and learning. The “speculation” phase is what is usually called “planning” in other methodologies, agile or not. It explicitly acknowledges the paradox of making plans in a rapid-evolving, complex, scenario.
The collaboration phase shows the importance of closer and constant collaboration, not only within the development team, but also between developers and the end-users of the software.
Finally, the learning phase indicates everyone involved in the software development process will be continuously learning throughout the project.
ASD, as an approach, is oriented toward high-speed: it uses techniques such as time-boxed iterative cycles, risk-driven planning and concurrency to achieve quick delivery of value to the customer, while also embracing the uncertainty and near-chaos that are intrinsic to complex, high-risk projects.
Brief History
The Adaptive Software Development methodology was created in the early 1990s by two project managers: Sam Bayer and Jim Highsmith—who would later on be one of the signers of the 2001 Manifesto For Agile Software Development, or simply the Agile Manifesto.
ASD was created as a refinement of an earlier methodology, Rapid Application Development, or RAD. RAD itself appeared in the early 90s, bringing shorter iterations and speed to organizations that were failing with waterfall-like approaches. However, RAD quickly became associated with hacking, due to its lack of focus on software engineering best practices. Highsmith started to apply best practices to RAD, creating RADical Software Development.
However, when working with clients, he realized that both approaches weren’t enough. They needed an approach that fostered collaboration—not only inside the organization, but also with the client—, embraced the uncertainty of software development and fostered continuous learning. To meet those needs, Adaptive Software Development was created.
The approach was successfully used to deliver many software projects, across many industries and in different countries. In 2000, Highsmith published a book called “Adaptive Software Development: A Collaborative Approach to Managing Complex Systems”, in which he presents the ASD methodology in detail, besides covering the philosophy and theory behind it.
How does it work?
Having covered the fundamentals of ASD, let’s now see how it works in practice.
In ASD, as in most agile methodologies, work occurs in cycles or iterations. During such cycles, developers not only build new components but also make necessary modifications to pre-existing ones.
A key distinction between adaptive software development and other methodologies is that, in ASD, cycles are component-based, rather than task-based. It is common, for instance, for teams using other methodologies to break down user stories into more granular tasks, which are then assigned to developers to implement. In ASD, the focus is always the desired result. It defines components as a group of features, planned, implemented and delivered together.
Components, in the ASD sense, don’t refer only to visual components—such as buttons, form fields, or other GUI elements. It also includes all related “things” that are implemented together.
For instance, an online payment service could have an “invoice management” component, which would include not only the graphical elements necessary to carry out those tasks, but also the underlying APIs and storage mechanisms.
More specifically, there are three types of components in ASD: primary components, technology components, and support components. Primary components refer to the business functionalities themselves. Technology components, on the other hand, consist of pieces of technology or infrastructure that need to be in place for the primary components to be implemented. Technology components include not only hardware and network infrastructure, but also software such as operating systems, databases, frameworks, and more. What will often happen is that such components will already be ready to use. If they’re not, they need to be assigned to cycles for installation.
Support components include everything else not contemplated by the other two types. For instance, external-facing documentation, training materials, and more.
As in other methodologies, cycles in ASD are time-boxed, not only at the level of each individual development cycle, but also at the project level. Finally, ASD cycles are risk-driven and change-tolerant.
Being risk-driven can be understood as a willingness to fail fast., by placing higher-risk items in the earlier cycles. If you identify a risk in your project, you should try to reduce the likelihood of the failure. However, if reducing the probability isn’t possible, ASD says you should accelerate the happening of the failure. The rationale is simple: if a given decision is doomed to fail, it’s better and cheaper to find out earlier rather than later.
Being change-tolerant means that, instead of assuming most activities will happen as planned, you start with the premise that everything will change, and often. In ASD, teams create change-tolerant environments so change can be better managed. One of the ways in which this is accomplished is through the adoption of shorter time-frames. Also, ASD promotes a culture in which developers are constantly asking themselves questions about change, and also watching and evaluating what competitor services and products are doing.
Instead of trying to avoid change, ASD embraces that for the benefit of the client.
Key Meetings, Cycles, Delivery Cadences
The Adaptive Life Cycle
The adaptive life cycle can be seen as an evolution of the evolutionary life cycle—also called the spiral life cycle—that started emerging during the mid-1980s.
The shortcoming of the evolutionary life cycle is that many of its adopters haven’t abandoned their old mindsets that revolved around predictability. Even though some methodologies appeared—such as RAD—that leverage evolutionary life cycles in less predictable and deterministic ways, many practitioners still insisted on overly-detailed planning and specifications.
The adaptive life cycle addresses those shortcomings, by reflecting the intrinsic uncertainty of developing complex software systems. This is reflected, for instance, in the change of the phase names, but it goes beyond that. The adaptive life cycle advocates a change in management style as well.
Speculate
The “speculate” phase in ASD addresses the inherent paradox which is planning in complex scenarios. Since you can’t predict your outcomes, you’re way more likely to be wrong than right during the planning phases.
ASD acknowledges that by getting rid of the word “planning”—which is a loaded term, carrying a lot of baggage—and replaces it with “speculating.” When speculating, teams do the following:
-
they define their mission statement to the best of their ability;
-
then, they express a general idea of their end goals, which happens through the creation and sharing of mission artifacts;
-
Finally, they adopt mechanisms to help them adapt and change as they learn throughout the lifetime of the project.
-
The project vision charter. A simple visual summary for the project, which includes business outcomes and the main market differentiators.
-
The project data sheet. A short document summarizing essential information for the project the team and customers can use as a point of focus.
-
And the product specification outline. A high-level inventory of the product specifications, whose main goal is to define the expected components—group of features—for the product.
In practice, the speculation phase is divided into two steps: the project initiation step and the adaptive planning step.
The project initiation step is the earliest phase in which the organization develops project management information, a mission statement for the project and initial requirements.
The adaptive planning step is the phase in which software components are assigned for being built or assembled. During this phase, the team executes the following steps:
-
They decide the time-box for the project
-
Then, they decide the necessary number of development cycles, and how much time each cycle will take (4 to 8 eights for projects time-boxed to less than 10 months, and 6 to 10 weeks for projects longer than 9 months.)
-
They specify a theme and objective for the cycle
-
They assign components for each cycle
-
Optionally, a task list is created for the project
The last step is optional because, ideally, adaptive management should forgo the need to control and micromanage, preferring to define the “what” and not care about the specifics of the “how”. But since a transition to an adaptive style might be hard and even scary, the creation of a project task list might be used to smooth such a transition.
Collaborate
The collaborate phase is the phase in which developers actually perform the development work. This phase is divided into cycles, and each one of them delivers value to the customer.
We’ll cover the cycles themselves in more detail later. Now, let’s focus on the characteristics of great teams.
What High-Performance Teams Look Like
A crucial and often overlooked characteristic of teams that perform well in complex projects is the high technical proficiency of each member. It doesn’t matter if teams collaborate well and have great communication if the technical skills each participant brings to the team are not up to the challenge.
Additionally, teams should be small, with fewer than 10 members. That’s vital because great collaboration requires intense interactions that get harder as teams get larger.
ASD advocates that a team should have all of the skills necessary to perform the work. This is common in other agile methodologies as well—e.g. the “whole team” concept from extreme programming. However, ASD stresses that the necessary blend of skills must include not only the technical chops but also interpersonal, and business skills as well.
The Core Values of Teams In ASD
In adaptive software development, teams operate according to the 4 core values: mutual trust, mutual respect, mutual participation, and mutual commitment.
Mutual Trust
Mutual trust must be achieved in the team through honesty—saying the truth; safety—the creation of a comfortable, welcoming environment for the expression of ideas; and dependability—knowing you can rely on your teammates.
Civility is a goal in great teams, but not necessarily harmony. Conflict is inevitable when there’s diversity, and when handled correctly it boosts creativity.
Mutual Respect
In teams using adaptive software development, everyone must be respected and valued for the contributions they bring to the project, regardless of the areas in which they specialize.
Harmful behaviors and habits that are common in technical scenarios, must be abandoned if you are to achieve mutual respect. One of such behaviors is immediately dismissing someone as incompetent due to an opinion of theirs you happen to disagree with, and then refusing to accept their contributions from that point onwards.
Mutual Participation
Open, collaborative teams work best when more people participate. The value of mutual participation acknowledges that people have different levels of experience and knowledge, and that they have expertise in different areas.
The value doesn’t advocate for equal participation, but for mutual participation. It accepts that each person on the team might contribute and express themselves according to their preferences and skills, but all participation is valued the same.
Bear in mind that the values build on each other. For instance, it’s impossible to achieve a high degree of mutual participation if the team doesn’t already have mutual trust in place. Trust is needed for team members to feel safe and comfortable expressing their ideas, without fear of judgment or ridicule.
Mutual Commitment
Members of the team are equally committed to the project’s goal and they’re all responsible for ensuring the project’s success.
Even though successful software projects will have one or even more leaders, that doesn’t mean the other team members are relieved from having responsibility or commitment to the end result. Quite the contrary: in adaptive software development, everyone owns the result, and abdicating your individual responsibility can and often does lead to disaster.
Learn
The learn stage in adaptive software development is essentially what other methodologies would call a review or retrospective. During this phase, the product developed is analyzed from a technical and also customer perspective. Additionally, the performance of the team is also reviewed, in search of opportunities for improvement.
Key Roles and Responsibilities
ADS defines itself as a “framework of concepts, practices, and guidelines.” As such, it’s not overly prescriptive.
However, it does advocate a few key roles and responsibilities.
Executive Sponsor
The executive sponsor is a single point of contact with the organization’s management. This person plays a role that’s somewhat similar to that of a Product Owner in scrum. Their main responsibilities are to define business objectives and approve resources.
The Core Team
There is one core team for each major set of features. Each team must have people who are committed to the project exclusively. Key people from the client’s organization should also participate full time, when that’s possible.
In case that’s impossible, such key members can collaborate only a few hours per-day. This means the core team will need to adapt how they work to accommodate that those key client people are not available at their beck and call.
Project Manager
Good leadership is essential for the success of the project. In ASD, project management is a dedicated role for each project, which is needed due to the incredibly intense nature of the role.
Similarities and Differences
Adaptive Software Development vs Rapid Application Development (RAD)
Since ASD emerged from RAD, it’s obvious both approaches will share many similarities.
Both approaches are focused on speed, shorter iterations, and delivering working software to the customer as quickly as possible. In both approaches, feedback loops are important; RAD makes use of prototypes to gauge user feedback and then use that learning into improving the real application.
Both RAD and ASD make use of techniques such as JAD (joint application development) sessions to foster collaboration between groups inside the organization.
Adaptive Software Development vs Feature Driven Development (FDD)
Feature-Driven Development (FDD) shares many similarities with ASD, and the two are sometimes mixed up.
Like ASD, FDD doesn’t focus on individual tasks. Unlike ASD, though, FDD focuses on features. Adaptive software development, as you’ve seen, is component-based.
Another difference between the approaches relates to how prescriptive they are regarding engineering practices. Feature-driven development relies on a set of software engineering practices, including continuous build, domain object modeling, and individual code ownership.
Adaptive software development, on the other hand, is completely agnostic when it comes to engineering practices, not relying nor specifying any kind of technique.
Adaptive Software Development vs Extreme Programming
Finally, let’s review how ASD compares with some of the most well-known agile methodologies out there: extreme programming (XP).
As it turns out, there are many similarities between the two. Like ASD, XP emphasizes collaboration with the client. XP accomplishes that in quite a radical manner, by having the customer as a member of the team itself, collaborating in the creation of user stories and even in writing acceptance tests.
The two approaches also agree that change is positive for the customer, and the uncertainty should be embraced and relished rather than feared. Also, both approaches have feedback and continuous learning built into their life cycles.
Now, for the differences. In XP, during each planning session, after the stories are picked for the current iteration, developers break them down into tasks, estimate the tasks, and sign up to implement them. ASD, on the other hand, is component-based instead of tasks based. During the speculate phase, components are assigned to cycles for implementation.
Common Pitfalls
Since ASD is an intensively collaborative methodology, this section presents some important collaboration pitfalls teams must be on the lookout for.
Collaboration Can Lead To Indistinctive Solutions
Through poorly done collaboration, teams can arrive at solutions that are indistinctive due to catering to too many different opinions.
Collaboration Can Slow Teams Down
Projects can be slowed down due to excessive number of meetings, discussions, and unnecessary involvement. Effective and efficient collaboration happens when team members trust one another to make decisions on their behalf so they don’t need to be present for every discussion.
Successful Collaboration Relies On A Willingness To Commit
Finally, successful collaboration relies on a willingness to commit to projects. Such willingness can’t be imposed. Instead, team members must volunteer to commit to the project.
-
Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by Jim Highsmith
-
What Is Agile Methodology? – Overview Of Agile Software Development And Agile Models
-
Iterative And Incremental Development – Agile Methodology
-
Agile Software Development: What It Is & What You Get Out Of It
Speculate Your Way to Successful Software Projects
One of the defining properties of all methodologies under the agile umbrella is that they strive to help teams embrace change and uncertainty. Also, they advocate for an iterative and adaptive working style, instead of working on rigid, sequential phases, à la waterfall model.
These properties are very evident in one relatively less-known agile methodology we discussed today: Adaptive Software Development, or simply ADS.
ADS, as a methodology, comes with a clear vision on the paradox of planning: since, when it comes to complex projects, you can’t know for sure where you’re going to get, your best hope is to “speculate” about the general direction and learn along the way.
So, when you’re still working on shedding old habits of trying to predict an uncertain future, ASD can be instrumental in becoming more agile and getting you to speculate your way to successful software projects.
About Author:
Signup for updates!
Speed up your Agile planning and execution!
Signup for a FREE Trial of Nimble Agile
