Empiricism — The Art of Doing Less to Achieve More
„What did I spend so much effort for?“, he pondered in despair.
Last months he spent most of his days working on this one thing. The work defined these months. A vision is what got him started. He had an idea that could make the life of many people easier. And he spent hour after hour to plan out this project, develop it, and prepare its launch. Almost six months had passed since then. Six months. „Wasted“, he thought.
Now, he was looking at the page with page views and registrations. He felt like a fool. All the work for nothing. He reloaded the page, again and again. After several times reloading the page, he convinced himself to let go. To let go and wait. He decided to give it some time.
Tell me, how often in life did you have to change directions?
Like, when you planned to go to Italy this year and then a pandemic unfolded. In business, it happens even more often. The meeting you prepared yourself for? Cancelled. The initiative you wanted to drive? Changed priorities. The deadline on the critical path? Missed. Life doesn’t always work out as planned. Changed decisions, missed opportunities, sunk cost. Even failure in life is inevitable. Ask Edison, how often he tried before he brought light into our evenings and nights.
Failure feels terrible. No one likes to fail. Even worse it is, if we could have prevented the failure from happening. But if we fail, wouldn’t it be nice to fail fast and learn from it?
That is the idea of empiricism in process control.
“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.
Do you remember the guy in the introduction?
That guy thought he was smart. He did his homework. To avoid failure, he checked if there is a similar product like what he had in mind. He asked his friends. Then he spent months over a month in his room. Built the thing. But when he finally finished his work, he found no customers. At first, he thought that he just needs to wait. After all, success does not come overnight. So he waited. He waited and promoted his work. Social Media, paid advertises. You name it. He pulled all registers. But after some weeks he figured out, that his potential customers had moved on. They found a different solution to the problem he wanted to solve.
Someone was faster.
Not every failure has to be that big. Say, you built a product that customers do love. But you also built that one feature and spent a lot of effort into it. Because you thought that customers would need it. Yet, they don’t use it. It’s not possible to avoid all efforts. But often it’s possible to achieve more with less effort by minimizing the scope and figure out if you get by with it. By getting feedback. If you ever heard the title of a book called „Scrum — The art of doing twice the work in half the time“ — that’s the idea behind it.
I said that failure is inevitable. That’s true. But the good thing about failure is that we can learn from it.
It’s not like we never know what people want or need upfront. Sometimes they tell us. Sometimes they don’t know themselves until you show it to them. If we work in an empirical way, we can learn from our failures. Our guesses about what customers need will get better over time. Still, sometimes we will fail. Our empiric work mode saves us from spending too much effort before finding out. If the timescale of our planning cycle is short, we have to cut down in scope, and this reduces the risk.
What could an empirical approach look like?
If you had to come up with an empirical approach, you would probably come up with a solution that looks like this:
- Plan your work
- Do the work
- Inspect your work and get feedback if possible
- Repeat until everyone is happy
In that approach, you would only plan for short timescales of weeks up to a month. After each of these iterations, you would inspect your results and your process. To see if there are lessons to learn. If you embrace the idea of empiricism, you consider each day an iteration in the iteration. In consequence, you consider each day an opportunity to inspect where you are. To decide where to head next.
Doesn’t that look a bit like Scrum to you?
If you want to gain a deeper understanding on how to unleash the potential of empiric process control in Scrum, take a look at the article “Everyone uses Scrum but haven’t uncovered its full potential” by Willem-Jan Ageling.