The topic of this article is experimentation, which is the 11th foundation of the agile factory.
The agile approach of gradual product development by small steps, consisting of increments and product changes, is accompanied at each step by verifications.
Verification is in many cases stakeholder and/or client evaluation of what has been developed, according to design-for-x perspectives or possible alternative solutions.
In many other cases, it is instead a matter of evaluating the result of experiments performed on what has been developed.
In the case of physical products when possible experiments are conducted with digital models, otherwise they are conducted on product elements or their forerunners such as pretotypes.
This continuous experimentation allows for test-driven development for hardware products as well.
Experimentation means not only the continuous testing of each design solution but also the testing of products that have not yet been developed.
In fact, when very innovative products are developed, it is appropriate to do an exploration project first.
This type of project is intended to test the possible market response to the product being considered for development, without developing the product itself.
To not build the product you develop its digital or physical forerunners.
If there is one characteristic that I find repeated again and again in Agile product development, it is experimentation.
It is a scientific approach when experimentation is to confirm formalized theories, similar to the approach of researchers…
At the same time, this is an empirical approach, when only estimates or intuitions are available, based on collected data and meetings with relevant clients.
Experimentation and failures
In my professional life, I have been privileged to be an experimenter for several years, designing the individual tests together with the testing machines to validate in the laboratory and/or in the field the products created by the designers.
It was a very rich experience for me because, as a computational engineer first and a design engineer later, the experimentation was a great bath of practice.
It taught me in particular that digital models require continuous validation by conducting experiments whenever possible to verify their results.
I learned that the perspective of the experimenter is different from that of the designer, who is looking for confirmation, while the experimenter is required to have no bias.
For these reasons, it is better for the experimenter to be a person other than the developer.
In particular, it is not only important to verify the expected performance and functionality of the product, but it is necessary to experiment until finding the limits of what has been developed.
This goes beyond computational models and has repeatedly put me in front of unexpected results, with product performance that cannot be justified by calculation.
Experimentation, complexity and learning
Experimentation lets us encounter the complexities of product development in the sense that we test our beliefs and is the field where failures most commonly occur.
Development teams, during sprint planning only plan topics or stories that are clear and for that ready.
In my experience, in most cases, the next development step or sprint has a predictable result.
The subsequent verification, during the sprint review, is a form of experiment and an element of complexity because it has an unpredictable result.
What is developed may not satisfy stakeholders and/or the customer.
When in the next steps we proceed with experimental verification of what was designed, the surprises can be much greater and, more frequently than before, are negative.
The failure of an experiment, which is the lack of confirmation of what was hypothesized, is one of the major forms of learning.
Experimentation in the agile process is the activity with the most surprises and is indicative of the complexity of product development.
