That's one of my main misgivings about a hard-line agile approach. It is good for shops focused on engineering simple problems or doing routine technical work. It breaks down completely in more research-driven domains.
The hard problems are the ones where you bang your head against the wall with no tangible progress, simply exploring the problem domain until you can get some traction, find a way to solve it, but often your first few attempts lead to a sub-optimal solution you'd hate to commit to.
Agile says go with it, fix it later. This is why we get stuck with crappy standards we'd all want to go back in time to fix.
Some things require a more artistic approach where you grind away at the thing until it's actually solid.
If Haskell is pure mathematics then there's no way you can shoehorn that into an agile box.