Software and Agile Experimentation

The Agile Experimentation Method™ is the method Ironstone Advisory uses for software development.

It takes inspiration from the empirical cycle used in scientific research and adapts it for iterative software development. It differs from traditional methods such as the Waterfall SDLC or MIL-STD-2167A through its focus on rapid experimentation and continuous learning. This is not the Agile methodology, but it does draw on the Agile Manifesto.

CORE PRINCIPLES

• Iterative and incremental delivery

• Continuous feedback and adaptation

• Active stakeholder collaboration

• Hypothesis-driven experimentation

THE CYCLE

I. HYPOTHESIS FORMATION

Work with stakeholders to identify key problems and opportunities, hypotheses about possible solutions, expected outcomes and measurable success criteria.

II. EXPERIMENT PLANNING

• Design a minimum viable experiment to test the hypothesis.

• Identify resources, technologies and constraints.

• Create an experiment plan with specific tasks and timelines.

III. EXPERIMENT EXECUTION

• Build a working prototype or proof of concept: software, agent, dataset or benchmark.

• Measure results against defined success criteria.

• Capture learnings, feedback and new insights.

IV. RETROSPECTIVE AND ADAPTATION

• Analyze experimental outcomes and learnings.

• Decide whether to persevere, pivot or abandon based on evidence.

• Update the hypotheses, success criteria and backlog for the next iteration.

V. INCREMENT OR PIVOT

If the experiment succeeds, evolve the prototype into a product increment. If the hypothesis is invalidated, return to hypothesis formation with new insight. Then repeat the cycle.

KEY PRACTICES

• Cross-functional collaborative teams

• Continuous integration and deployment

• Automated testing and monitoring

• Rapid prototyping and experimentation

• Lean UX and design-thinking methods

• Evidence-based decision-making

The cycle promotes continuous discovery, empirical learning and course correction based on real-world feedback and outcomes rather than restrictive predefined specifications. This allows for greater agility, innovation and de-risking of assumptions.