[nullspace]

It _can_. The idea of having prototypes that can be used immediately but very small in scope, not thinking about what you're going to be working on next week right now, making sure you're setting up systems that can give you fast feedback etc, are immensely helpful for difficult problems.

Just taking the examples that are mentioned here:

> Designing an architecture for a new, ambiguously scoped system. The MVP is, can you take the top 2 most ambiguous risky part of a potential solution and script it out. Then present the operating characteristics. Anti-pattern: create a story to design an architecture.

> “Improve system performance”. Profile various aspects where you have a hunch that things are bad. Investigate theory a, b, c to improve performance. Are they trivial fixes or need a large refactor. Build up buffers for the uncertainty but react when things become more certain. Anti-pattern: "timeboxed performance improvements"

> Coordinate a rollout of a backwards incompatible change across N dependent systems. Sometimes you can't help but do a very large rollout, so alright. But one essence of agile development is to keep your rollouts as small as possible.

Just to be clear, I'm not saying these things are not difficult problems, but agile (with lower case a) development _can_ really help, if we want it to.

[marcosdumay]

The idea of having prototypes that can be used immediately assumes you have hard work, not difficult problems. It doesn't try to transform anything into any other thing, it just fails to work on one of those cases.

As you quoted, it's a strategy for dealing with ambiguity risks, AKA solving the wrong problem. It assumes you have a lot of small problems to solve, and separates their risks so you can solve one at a time. It doesn't deal with big unseparable risks at all.