“I am the wisest man alive, for I know one thing, and that is that I know nothing.”
Empiricism is a theory with a simple premise. It says: knowledge comes primarily or only from experience. The idea is almost as old as mankind. It has become the foundation of modern science and helps us understand the world. To learn how the world ticks. In science, we conduct experiments to prove or dismantle our hypothesis. In Scrum and other agile approaches, we use a similar approach. We build something to confirm our assumptions about what provides values to customers. Not once in a while, but by the end of each sprint. It forces us to cut down the scope. And by doing, so we mitigate the risk of the uncertainties inherent to most endeavors. To avoid wasted efforts.
If you believe in the theory of empiricism — would you spend months into planning before even start doing?
I bet you won’t. You would challenge the assumption that you can know upfront what customers need. You would refuse to plan out details of each feature before building the thing. Before knowing anyone wants it. Instead, you would build a minimal version of your product and bring it to the test. Ideally, you would show it to real customers and see if they like it.
Do they like it? Cool. If not, you at least didn’t invest too much effort.
In some cases, you don’t want to show early versions of a product to real customers. Maybe you are building the first iPhone while the world still uses dumb phones. An idea of pure novelty. Something that you want to keep a secret until it’s ready to sell it. After all, you don’t want your competitors to steal your idea and make building the product a race. In that case, you would show your early-stage products to people in the company. At least, that’s what Apple does.
Empiricism doesn’t mean stop doing what we are good at. It means acknowledging that there is always a certain amount of uncertainty with all we do. And deal with it.
If we buy into the idea of empiricism, we still do the best we can. On a smaller scope. We do all the requirements engineering. We talk to customers and conduct market studies. Build prototypes to confirm technical feasibility. Then we proceed to build something valuable. Of course, we do it according to the quality standards of our craft. Like a developer writing tests for new functionality. Or like a carpenter smoothing the raw edges of a piece of wood.
After all, we still want to build products our customers will love.
We also still plan our work. In fact, we do it more often. Our planning cycles are shorter compared to other approaches. In the range of weeks to months, with a preference on shorter time scales.