A simple question can be a gate to something more fundamental.

For example: "Should we estimate with t-shirts sizes or fibonacci?". Looking beyond the surface, one might start talking about organisational constraints, AI, planning, incentives, and how decisions actually get made. Such a discussion might reveal that estimates aren't really about numbers, but about who we're trying to serve, and for whom.

Miro board from the video

To go beyond a problem's surface, you can try the following approach:

1. Write down the problem or question you're facing
2. Try to understand the underlying need
3. Brainstorm approaches to address that need (at least two)
4. Write down what you think about each approach
5. If the problem is difficult or complex, introduce more structure: define criteria, then evaluate each approach against those criteria

Example: How should we do estimates: fibonacci, t-shirt sizing?

Many teams discuss on the level of this question, but we first need to ask something else: What underlying need are we actually trying to address here? It could be something like:

• Predictability for the business?
• Engineers aligning on scope and approach?
• A requirement to follow a given process?
• Something else we're not seeing yet?

These discussions often feel like stepping into the unknown, which can be uncomfortable. Some people tend to rush through.

So let's say it's predictability, and we choose not to explore that need further. How can we make the work more predictable? Some approaches:

1. Point estimates: might still be too micro-level to be truly predictable?
2. Fixed project time (e.g., 6-week cycles like Shape Up): requires the ability to adjust scope accordingly
3. Continuous evaluation: requires incremental delivery and ongoing alignment with the business
4. No change, keep doing what we're doing: maybe suitable if there's too much other stuff going on right now?
5. Something else?

Capturing this thinking and decision-making process in writing or in a diagram can be helpful as well.

When you make a decision after this kind of exploration, you'll likely have a clearer understanding of both the problem you're trying to solve and the solution space. As a result, the choice you make is likely to be stronger.

Example of how overlooking the underlying problem can lead to wasted effort.

Recently, I was involved in an initiative to adopt contract tests, and the conversation went something like this:

Me: We're talking about adopting contract tests. What's the underlying need we're trying to solve?

X: To prevent integration errors after release, and reduce the number of incidents we see afterward.

Me: That sounds great. ...at the same time, I wonder, it seems we don't currently have a clear overview of all incidents happening in the team. Is that right?

X: Yep, we still need to work on that.

Me: Hmm. I'm curious, what did the last few incidents actually look like? What caused them?

Y: We had a severe one caused by a misconfiguration. And another big one was also caused by a misconfiguration.

Z: And there was another major one, that missing regression unit test, you remember?

Me: Yeah.. So it sounds like the major incidents we remember weren't caused by service integration issues, but by misconfigurations and missing tests. Would that be right?

X: Yep.

Me: So it seems that if the goal is to lower the number of incidents, adopting contract tests might not actually help at this point.

X: That seems to be the case, yes.

Rather than diving straight into contract tests, the team would probably be better off starting with tracking incidents and understanding their causes. And maybe focusing on misconfiguration issues instead.