Agility only makes sense in the light of uncertainty. If you know exactly what the customer wants or what the market needs, you don’t have to be agile and can save yourself a lot of detours and aberrations. Only who really knows? And even if we think we know it here and now, when the product is ready it can be very different. Agility makes a lot of sense in today’s world for which VUCA (for Volatility, Uncertainty, Complexity, and Ambiguity) is more and more true. “Responding to change over following a plan,” the Agile Manifesto says. But how do you actually respond to change and how do you recognize that you have made a wrong turn?
That’s why agility has a lot to do with empirical research. In an agile approach, one constantly makes hypotheses and one tries to confirm them as well as possible by measurements and feedback loops. In addition to this empirical process at the product level, agility is also empirical at the process level. “At regular intervals, the team reflects on how it can become more effective and adjusts its behavior accordingly.” is one principle behind the agile manifesto. In Scrum, for example, each sprint is a hypothesis of collaboration, which is confirmed or refuted in the retrospective at the end.
The term empirical is derived from the Greek word εμπειρία (empeiría), which means experience or knowledge through experience. This refers to the methodical and systematic collection of data with the purpose of verifying or refuting theoretical assumptions about the world. Agility begins with honestly acknowledging the uncertainty of the venture and its environment. The logical consequence of this awareness of uncertainty is to work with hypotheses. Every prioritization, every sprint planning is a hypothesis of the assumed customer value. And good hypotheses have to prove themselves. That’s why agile teams capture all the data about themselves and their productivity as well as about the product and its users.
An empirical-scientific system must be able to fail based on experience.
In principle, most assumptions about products and customers can never be completely verified in the sense of general validity. In this respect, all our hypotheses are preliminary and just not yet refuted. The better is the enemy of the good. The product team must focus on finding this better solution faster than the competition. And this better solution can only be found if one works constantly on the falsification and not so much on the confirmation of one’s own previous hypotheses. Therefore, it is a good practice when agile teams intensively use A/B testing.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?