[n4r9]

I enjoyed this. At my own workplace it's a challenge to fit my team's work into the wider sprint-based methodology where every project must be refined, estimated, and broken down into items with <2 days effort. That makes a certain amount of sense if, say, you're building a standard web portal. It makes less sense if, say, you're adapting modern hierarchical routing algorithms to take vehicle dimension restrictions into account. It's difficult to express just how nebulous this kind of work can be. Managers like to say "Maybe you don't know how long it will take now, but you can research and prototype for a couple of days and have a better idea". The problem is that research work generally takes the following form:

* Come up with 5 possible approaches (2 days)

* Create benchmark framework & suite (1 day)

* Try out approach A, but realise that it cannot work for subtle technical reasons (2 days)

* Try out approach B (2 days)

* Fail to make approach B performant enough (3 day)

...

You just keep trying directions, refining, following hunches, coming up with new things to try etc... until you (seemingly randomly) land on something that works. This is fundamentally un-estimatable. And yet if you're not doing this sort of work, you will rarely come up with truly novel feats of engineering.

[p_v_doom]

Almost everywhere management- whether wearing the skin of agile on top, is still bound to good old school Taylorism. And there is always this complete lack of understanding of the types of work there are and that you cannot cramp work related to complex, novel things in the same way you do something standardized. Alas, business dont care, cause they wont their estimates and roadmaps and plans, and we all pretend it works ...

[sundarurfriend]

> The problem is that research work generally takes the following form:

> * Come up with 5 possible approaches (2 days)

Even that gives you something to talk about, that looks "solution-oriented" in the way managers like; in deep work the first steps can actually be:

* Break down the existing approach into its fundamental assumptions and components (3 days)

* Try to build a few approaches challenging some assumptions in a useful way, and fail (2 days)

* Get a clearer picture of the cloud of possibilities that are more likely to work, and start assembling the pieces from that cloud (3 days)

and so on. This is the kind of stuff that's really hard to communicate, and often sounds like you're doing nothing at all in the initial stages, even though that time pays for itself many times more once(/if) you get to take it to completion instead of doing patchwork upon patchwork on a design based on outdated assumptions.

[woooooo]

FWIW, the ritual of codifying your experimentation like this does still serve a dubious purpose -- it gives your boss a way to talk about it with their boss. This doesn't solve the problem faster, it slows things down in fact, but we live in a society and your boss needs a way to talk about your work.

[n4r9]

I'm fine with providing status updates and a rough idea of next steps. Less so fully breaking down projects into small items, or building a year(s)-long roadmap based on a quarterly release schedule with committed items etc...

[HPsquared]

If you're doing original work, the plan might change at every step.