Test-Driven Development (TDD) and Behavior-Driven Development (BDD) are popular agile development techniques. However, they don’t measure application usage or provide guidance on gaining feedback from customers. Experiment-Driven Development (EDD) is a scientific, fact-based approach to software development using agile principles.
Understanding Experiment-Driven Development
While TDD and BDD help developers enhance code quality and ensure that it behaves according to spec, EDD helps identify the features that should be developed. In other words, what will become the spec.
EDD is driven by split A/B testing, where a baseline (control) sample is compared to several single-variable samples to determine which of the two choices improves response rates.
This form of feedback collection avoids the need to conduct user surveys, which are often time-consuming for both parties and can be prone to bias.
Implementing Experiment-Driven Development
To implement EDD, it is a matter of following these four steps:
- Start with a hypothesis. Instead of beginning with a user story, the project team starts by defining a hypothesis related to customers, problems, solutions, value, or growth. For example, a growth hypothesis may be “A virtual shoe fitting station in every store will increase shoe sales by 30%.”
- Identify the experiment. In the second step, take the highest-priority hypothesis and define the smallest experiment that will prove or disprove it. The shoe store may decide to install a virtual fitting station in five stores to begin with and measure the impact on sales.
- Run the experiment. This may include creating a minimum viable product (MVP) and then measuring progress based on validated learning from the end-user. Here, many businesses choose to run experiments based on the Build/Measure/Learn (MVPe) loop.
- Debrief. For example, what are the observations? How were the validated learnings used? Would more time spent on planning have helped? Based on the results, the team may choose to pivot to a new hypothesis. Alternatively, they may choose to persevere with the current hypothesis or discard it entirely and move to the next one.
Experiment-Driven Development Benefits
When a business incorporates EDD to complement an existing approach such as TDD or BDD, it can realize several benefits.
- Structure. EDD allows project teams to ask and answer questions in a structured, measurable process. Since ideas are validated by hypotheses, teams also avoid the testing of ideas simply to validate individual egos or hunches.
- Versatility. Although its scientific foundations may suggest otherwise, Experiment-Driven Development can be used across any business in any industry. It is not specifically designed for use by R&D teams.
- Objectivity and efficiency. All agile methodologies dictate that value to the end-user is the primary goal. However, the hypothesis-driven approach of EDD forces teams to define value through validated learning and not assumption alone. Efficiency is also increased by building an MVP instead of focusing on superfluous features that provide little benefit to the end-user.
- Experiment-Driven Development is a hypothesis-driven approach to software development that is based on fact.
- Experiment-Driven Development incorporates A/B testing, where a baseline sample is compared to a single-variable sample to determine which sample delivers a better outcome. This allows the business to formulate, test, and evaluate hypotheses.
- Experiment-Driven Development complements approaches such as TDD and BDD, but it does not replace them. EDD can be used in any industry or department as an efficient and (most importantly) objective means of agile software development.
Main Free Guides: