As developers, we're used to working with systems that we control. We write code, we write tests, we build servers and infrastructure, and everything works beautifully - and then we ship, and suddenly we're not in control any more. Our code is out there in the real world - real people, real problems, maybe even real money - and suddenly we're seeing all sorts of interesting data and behaviour that was never part of our plan. Agile development teams aren't afraid of this emergent behaviour - instead, we embrace it. We know that we don't really understand how good our solutions are until we're getting real feedback from real users. We know that with rapid iterations and frequent releases, we can react quickly to this feedback - and so we live in a world of MVPs, sprints, continuous deployment, A/B testing, and a myriad of other software development paradigms which help us keep these feedback cycles as tight as possible, because much of the time, our 'solutions' are actually experiments - whether we realise it or not. So how about we embrace this idea of experimentation, and steal a few ideas from some scientific fields that have been doing this a lot longer than we have? Since the 17th century, scientists have been investigating the world around us using a technique known as the scientific method - a technique for investigating observed behaviour, validating assumptions and communicating results. In this talk, we'll look at applying the scientific method to software development. We'll discuss how to design a good experiment. We'll look at some of history's most famous experiments, and how even 'failed' experiments have often led to important advances in knowledge and understanding. We'll look at how successful software teams use experimentation as part of their development process, and at how you can share the results of your own experiments so that we can all benefit from each other's research. And we'll even conduct a few experiments of our own. You know... for SCIENCE!