Inspection and adaptation are two of the pillars of the Scrum framework but all agile methods recognize the wisdom of Deming’s Plan-Do-Study-Act cycle.
While the Manifesto does not explicitly reference the scientific method, it is implied in the value statement “Responding to change over following a plan” and in its final principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Agile teams embrace experimentation in many ways.
Some of these relate to the product. Minimum Viable Products and Minimum Business Increments can be designed and run to test hypotheses about what we feel is valuable to customers at a macro level. Split testing and similar short feedback techniques might validate whether specific features should be pursued or not.
Some relate to the team’s delivery process.
Both the Rational Unified Process and Disciplined Agile Delivery highlight the importance of proving solution architecture early and one effective means of doing this is through the design, construction and execution of experiments focused on quality attributes such as performance or flexibility.
Working agreements such as Definitions of Ready or Definitions of Done can be thought of as experiments to validate whether teams are able to efficiently complete work items and whether teams understand what complete means.
Ceremonies such as retrospectives help a team to identify delivery improvement ideas. Rather than assuming these ideas will help and implementing them on a broad scale, teams will run experiments to see whether these ideas actually show promise. For example, improving product quality through pair programming might seem like a good idea so a team might elect to try pairing on a subset of their upcoming work items and comparing the outcomes to those completed using their previous methods.
Spikes are another form of agile experimentation. Rather than losing significant effort in comprehensive analysis of a specific uncertainty, a short time boxed deep dive focused on learning which options might be feasible is often a better alternative.
So how could adopting this commitment to experimentation help those teams using a predictive life cycle?
Assumptions which have not been validated are a common source of project risks. While a team could wait for an assumption to be passively proven, wouldn’t it be more effective to frame a critical assumption as a hypothesis and then design and run an experiment to get data to make the team feel more confident about that assumption?
Incorporating ongoing experimentation into the risk management life cycle might provide a more effective method of de-risking all types of projects.
Easy in theory, difficult in practice 