[maxxxxx]

There are types of work where you may deliver nothing for months. I think the sprint idea mainly works for well understood tasks where there are no surprises. I often work on stuff where I can only report failure for weeks or months until it hopefully works.

[magnusss]

Can you please elaborate somewhat on the nature of these projects? I’d like to understand what it is about the work that makes it difficult to get interim results.

[maxxxxx]

For example I have worked on a way to launch a process in Windows with certain privileges from a service. It's a little unusual but important for the way our software works and right now the lack of this capability creates the need for a lot of clunky workarounds. Based on my reading of some Windows APIs I suspected we could make this work but it took 12 weeks to actually make it work. There was no guarantee of success either and there were no intermediate results.

[magnusss]

Great example, thank you. Sounds like you had a fun 12 weeks :-).

[maxxxxx]

I would call it a roller coaster :) with going back and forth from "why the hell did I sign up for this?" To "hey this may really work".

I always tell people that any good project has to have a time of deep depression where you deeply regret getting into it.

[krageon]

Any kind of research into a novel solution will basically be failure until it is suddenly success. If you can see that success coming from very far away you're not doing novel work.

[ianamartin]

This is really what I was trying to get at below. The sprint model or even the marathon model just doesn't work for certain types of projects.