We're ending up in a swamp, perfectly on schedule

I've seen it in every Finnish technology company I've ever worked for. It's a ritual we have all learned: the upfront planning of tickets, where the future is locked in. We estimate tasks with t-shirts, story points, or days. The goal is one thing – predictability. The ability to tell management: "This whole thing will be ready in 3 months."

In Finland, this is considered a success. Methods like Scrum and SAFe have taught us that predictability is a sign of professionalism. A manager who gets their team to deliver the agreed-upon things in the agreed-upon time is a king.

But I ask you: what is the benefit of perfectly predicting that in 3 months, we will deliver something completely useless?

This is the greatest tragedy of the Finnish tech industry. We measure a team's success by its ability to stay on schedule and by the production velocity of its "code." We don't measure how much impact the team's work had on customer value and the resulting business.

Scrum theater and its cost

This obsession with schedules creates a destructive cycle:

Work must be defined before it's done: To provide an accurate schedule, we have to lock in a detailed plan, even when we don't properly understand the problem.

Learning stops: The team's job becomes executing a predetermined plan, not considering whether what they are doing makes sense. The question "Are we solving the right problem?" is replaced with "Are we staying on schedule?".

Agility dies: When the plan is set in stone, we can't react to new information. Even if we realize within a week that we're heading in the wrong direction, we continue on, because otherwise, the schedule will fail.

This isn't agility. It's hiding the waterfall model behind fancy terms.

Move from predicting to learning

What if our goal wasn't to predict a delivery time, but to reduce uncertainty as quickly and cheaply as possible?

Instead of planning a 3 months project, we should be asking: "What is the smallest possible experiment we can run to test our most critical assumption?"

This is at the core of modern, evidence-based product development. Product thinkers like Itamar Gilad have created models, such as GIST, for this very purpose. The goal is not to deliver a feature, but to take a small step (Step) that generates learning and increases confidence (Confidence) in an idea.

How this works in practice

• Validate the problem first: Before we write a single line of code, let's interview, for example, five potential customers. Do they understand the problem we're trying to solve? Is it important to them? This might take two days, not two weeks.

• Validate the solution cheaply: Build a prototype or a simple smoke test, like a landing page, and see how many people are willing to leave their email address. This tells you more about real interest than ten meetings.

By doing this, we won't get a 3 months schedule, but we might learn in a single week that our original idea was bad. We just saved 11 weeks of useless work. That is a real success.

So let's stop the theater of prediction and start leading learning. What big, 3 month plan could you replace with a one-week experiment?