[nullspace]

I like this distinction, and the bit about converting difficult problems into hard-work.

There's one thing that occurred to me in the context of agile + difficult problems. When I think about my sprints, the vast amount of my time is spend dominated on that one "difficult" problem, which on the surface does not feel difficult. The spirit of agile development is to _try_ to transform difficult problems into hard-work (in the way suggested in the article), but I feel like most people don't try very hard to do that.

We could improve the way we structure our work by allowing ourselves to be more honest about acknowledging this, as well as actually putting in the mental work to figure out if parts of the difficult problem can be converted to "hard work".

[AnimalMuppet]

I don't think that's the spirit of agile development at all. Agile is about closed loops with fast feedback. It's about communicating quickly and reacting to new information. I don't see it as having much to do with "hard vs. difficult" at all.

[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.

[john_minsk]

I see your point and thought the same when reading the article. Decomposition.